NAME 名称

podman-farm-build - Build images on farm nodes, then bundle them into a manifest list
podman-farm-build - 在农场节点上构建镜像，然后将它们捆绑到清单列表中

SYNOPSIS 概要

podman farm build [options] [context]
podman farm build [选项] [上下文]

DESCRIPTION 描述

podman farm build Builds an image on all nodes in a farm and bundles them up into a manifest list. It executes the podman build command on the nodes in the farm with the given Containerfile. Once the images are built on all the farm nodes, the images will be pushed to the registry given via the --tag flag. Once all the images have been pushed, a manifest list will be created locally and pushed to the registry as well.
podman farm build 在农场中的所有节点上构建镜像，并将它们捆绑到清单列表中。它在农场中的节点上执行给定 Containerfile 的 podman build 命令。一旦在所有农场节点上构建了镜像，这些镜像将通过 --tag 标志推送到给定的注册表。一旦所有镜像都被推送，将在本地创建清单列表，并将其推送到注册表。

The manifest list will contain an image per native architecture type that is present in the farm.
清单列表将包含农场中存在的每种本机架构类型的图像。

The primary function of this command is to create multi-architecture builds that will be faster than doing it via emulation using podman build --arch --platform.
此命令的主要功能是创建多架构构建，比通过模拟使用 podman build --arch --platform 更快。

If no farm is specified, the build will be sent out to all the nodes that podman system connection knows of.
如果未指定农场，则构建将发送到 podman system connection 知道的所有节点。

Note: Since the images built are directly pushed to a registry, the user must pass in a full image name using the --tag option in the format registry/repository/imageName[:tag]`.
注意：由于构建的镜像直接推送到注册表，用户必须使用--tag 选项传递完整的镜像名称，格式为 registry/repository/imageName[:tag]。

OPTIONS 选项

--add-host=host:ip

Add a custom host-to-IP mapping (host:ip)
添加自定义主机到 IP 映射（host:ip）

Add a line to /etc/hosts. The format is hostname:ip. The --add-host option can be set multiple times. Conflicts with the --no-hosts option.
在 /etc/hosts 中添加一行。格式为主机名:ip。--add-host 选项可以设置多次。与 --no-hosts 选项冲突。

--annotation=annotation=value
--annotation=注释=值 ¶

Add an image annotation (e.g. annotation=value) to the image metadata. Can be used multiple times.
将图像注释（例如注释=值）添加到图像元数据。可以多次使用。

Note: this information is not present in Docker image formats, so it is discarded when writing images in Docker formats.
注意：此信息不包含在 Docker 图像格式中，因此在以 Docker 格式编写图像时会被丢弃。

--authfile=path

Path of the authentication file. Default is ${XDG_RUNTIME_DIR}/containers/auth.json on Linux, and $HOME/.config/containers/auth.json on Windows/macOS. The file is created by podman login. If the authorization state is not found there, $HOME/.docker/config.json is checked, which is set using docker login.
认证文件的路径。在 Linux 上默认为 ${XDG_RUNTIME_DIR}/containers/auth.json ，在 Windows/macOS 上默认为 $HOME/.config/containers/auth.json 。该文件由 podman login 创建。如果授权状态未在那里找到，则会检查 $HOME/.docker/config.json ，该值是使用 docker login 设置的。

Note: There is also the option to override the default path of the authentication file by setting the REGISTRY_AUTH_FILE environment variable. This can be done with export REGISTRY_AUTH_FILE=path.
注意：还有一种选择，可以通过设置 REGISTRY_AUTH_FILE 环境变量来覆盖认证文件的默认路径。可以通过 export REGISTRY_AUTH_FILE=path 来实现。

--build-arg=arg=value

Specifies a build argument and its value, which is interpolated in instructions read from the Containerfiles in the same way that environment variables are, but which are not added to environment variable list in the resulting image’s configuration.
指定构建参数及其值，这些值会被插入到从相同的 Containerfiles 中读取的指令中，就像环境变量一样插值，但不会被添加到生成镜像配置中的环境变量列表中。

--build-arg-file=path

Specifies a file containing lines of build arguments of the form arg=value. The suggested file name is argfile.conf.
指定一个包含构建参数行的文件，格式为 arg=value 。建议的文件名为 argfile.conf 。

Comment lines beginning with # are ignored, along with blank lines. All others must be of the arg=value format passed to --build-arg.
以 # 开头的注释行将被忽略，以及空白行。所有其他行必须是传递给 --build-arg 的 arg=value 格式。

If several arguments are provided via the --build-arg-file and --build-arg options, the build arguments are merged across all of the provided files and command line arguments.
如果通过 --build-arg-file 和 --build-arg 选项提供了多个参数，则构建参数将在提供的所有文件和命令行参数之间合并。

Any file provided in a --build-arg-file option is read before the arguments supplied via the --build-arg option.
通过 --build-arg-file 选项提供的任何文件都会在通过 --build-arg 选项提供的参数之前读取。

When a given argument name is specified several times, the last instance is the one that is passed to the resulting builds. This means --build-arg values always override those in a --build-arg-file.
当指定了相同的参数名称多次时，最后一个实例将传递给生成的构建。这意味着 --build-arg 值始终会覆盖 --build-arg-file 中的值。

--build-context=name=value

Specify an additional build context using its short name and its location. Additional build contexts can be referenced in the same manner as we access different stages in COPY instruction.
使用其简称和位置指定额外的构建上下文。可以像访问 COPY 指令中的不同阶段一样引用其他构建上下文。

Valid values are: 有效值为:

• Local directory – e.g. --build-context project2=../path/to/project2/src (This option is not available with the remote Podman client. On Podman machine setup (i.e macOS and Windows) path must exists on the machine VM)
  本地目录 – 例如 --build-context project2=../path/to/project2/src（此选项在远程 Podman 客户端不可用。在 Podman 机器设置（即 macOS 和 Windows）中，路径必须存在于机器 VM 上）

• HTTP URL to a tarball – e.g. --build-context src=https://example.org/releases/src.tar
  HTTP URL 到一个 tarball – 例如 --build-context src=https://example.org/releases/src.tar

• Container image – specified with a container-image:// prefix, e.g. --build-context alpine=container-image://alpine:3.15, (also accepts docker://, docker-image://)
  容器镜像 – 使用 container-image:// 前缀指定，例如 --build-context alpine=container-image://alpine:3.15，（也接受 docker://，docker-image://）

On the Containerfile side, reference the build context on all commands that accept the “from” parameter. Here’s how that might look:
在 Containerfile 方面，在所有接受“from”参数的命令中引用构建上下文。以下是可能的样子：

FROM [name]
COPY --from=[name] ...
RUN --mount=from=[name] …

The value of [name] is matched with the following priority order:
[name] 的值按以下优先顺序匹配：

• Named build context defined with --build-context [name]=..
  使用 --build-context [name]=.. 定义的命名构建上下文

• Stage defined with AS [name] inside Containerfile
  在 Containerfile 中使用 AS [name] 定义的阶段

• Image [name], either local or in a remote registry
  镜像 [name]，可以是本地的或者在远程仓库中的

--cache-from=image

Repository to utilize as a potential cache source. When specified, Buildah tries to look for cache images in the specified repository and attempts to pull cache images instead of actually executing the build steps locally. Buildah only attempts to pull previously cached images if they are considered as valid cache hits.
用作潜在缓存源的存储库。当指定时，Buildah 尝试在指定的存储库中查找缓存镜像，并尝试拉取缓存镜像，而不是在本地执行构建步骤。仅当之前缓存的镜像被视为有效的缓存命中时，Buildah 才会尝试拉取先前缓存的镜像。

Use the --cache-to option to populate a remote repository with cache content.
使用 --cache-to 选项将远程存储库填充为缓存内容。

Example 示例

# populate a cache and also consult it
buildah build -t test --layers --cache-to registry/myrepo/cache --cache-from registry/myrepo/cache .

Note: --cache-from option is ignored unless --layers is specified.
注意: 除非指定 --layers ，否则选项 --cache-from 将被忽略。

--cache-to=image

Set this flag to specify a remote repository that is used to store cache images. Buildah attempts to push newly built cache image to the remote repository.
设置此标志以指定用于存储缓存镜像的远程存储库。Buildah 尝试将新构建的缓存镜像推送到远程存储库。

Note: Use the --cache-from option in order to use cache content in a remote repository.
注意：使用 --cache-from 选项以便在远程存储库中使用缓存内容。

Example 示例

# populate a cache and also consult it
buildah build -t test --layers --cache-to registry/myrepo/cache --cache-from registry/myrepo/cache .

Note: --cache-to option is ignored unless --layers is specified.
注意: 除非指定 --layers ，否则选项 --cache-to 将被忽略。

--cache-ttl

Limit the use of cached images to only consider images with created timestamps less than duration ago. For example if --cache-ttl=1h is specified, Buildah considers intermediate cache images which are created under the duration of one hour, and intermediate cache images outside this duration is ignored.
限制仅考虑创建时间早于持续时间的图像的缓存使用。例如，如果指定 --cache-ttl=1h ，Buildah 会考虑在一个小时内创建的中间缓存图像，而超出此持续时间的中间缓存图像将被忽略。

Note: Setting --cache-ttl=0 manually is equivalent to using --no-cache in the implementation since this means that the user dones not want to use cache at all.
注意：手动设置 --cache-ttl=0 等效于在实现中使用 --no-cache ，因为这意味着用户根本不想使用缓存。

--cap-add=CAP_xxx

When executing RUN instructions, run the command specified in the instruction with the specified capability added to its capability set. Certain capabilities are granted by default; this option can be used to add more.
在执行 RUN 指令时，使用指令中指定的命令，并将指定的能力添加到其能力集中。某些能力是默认授予的；此选项可用于添加更多。

--cap-drop=CAP_xxx

When executing RUN instructions, run the command specified in the instruction with the specified capability removed from its capability set. The CAP_CHOWN, CAP_DAC_OVERRIDE, CAP_FOWNER, CAP_FSETID, CAP_KILL, CAP_NET_BIND_SERVICE, CAP_SETFCAP, CAP_SETGID, CAP_SETPCAP, and CAP_SETUID capabilities are granted by default; this option can be used to remove them.
在执行 RUN 指令时，使用指令中指定的命令，并从其能力集中移除指定的能力。默认情况下授予 CAP_CHOWN、CAP_DAC_OVERRIDE、CAP_FOWNER、CAP_FSETID、CAP_KILL、CAP_NET_BIND_SERVICE、CAP_SETFCAP、CAP_SETGID、CAP_SETPCAP 和 CAP_SETUID 能力；此选项可用于移除它们。

If a capability is specified to both the --cap-add and --cap-drop options, it is dropped, regardless of the order in which the options were given.
如果一个能力同时被指定为 --cap-add 和 --cap-drop 选项，它将被移除，无论选项的给定顺序如何。

--cert-dir=path

Use certificates at path (*.crt, *.cert, *.key) to connect to the registry. (Default: /etc/containers/certs.d) For details, see containers-certs.d(5). (This option is not available with the remote Podman client, including Mac and Windows (excluding WSL2) machines)
使用证书路径（*.crt, *.cert, *.key）连接到注册表。 （默认值：/etc/containers/certs.d）有关详细信息，请参阅 containers-certs.d(5)。 （此选项不适用于远程 Podman 客户端，包括 Mac 和 Windows（不包括 WSL2）机器）

--cgroup-parent=path

Path to cgroups under which the cgroup for the container is created. If the path is not absolute, the path is considered to be relative to the cgroups path of the init process. Cgroups are created if they do not already exist.
用于创建容器的 cgroup 所在的 cgroups 路径。 如果路径不是绝对路径，则将其视为相对于 init 进程的 cgroups 路径。 如果尚不存在，则会创建 cgroups。

--cgroupns=how --cgroupns=如何

Sets the configuration for cgroup namespaces when handling RUN instructions. The configured value can be “” (the empty string) or “private” to indicate that a new cgroup namespace is created, or it can be “host” to indicate that the cgroup namespace in which buildah itself is being run is reused.
设置处理 RUN 指令时的 cgroup 命名空间配置。配置的值可以是“”（空字符串）或“private”表示创建新的 cgroup 命名空间，也可以是“host”表示重用 buildah 所在的 cgroup 命名空间。

--cleanup

Remove built images from farm nodes on success (Default: false).
在成功时从农场节点中删除构建的镜像（默认值：false）。

--cpp-flag=flags

Set additional flags to pass to the C Preprocessor cpp(1). Containerfiles ending with a “.in” suffix is preprocessed via cpp(1). This option can be used to pass additional flags to cpp.Note: You can also set default CPPFLAGS by setting the BUILDAH_CPPFLAGS environment variable (e.g., export BUILDAH_CPPFLAGS=”-DDEBUG”).
设置要传递给 C 预处理器 cpp(1) 的附加标志。以“.in”后缀结尾的 Containerfiles 将通过 cpp(1) 预处理。此选项可用于传递附加标志给 cpp。注意：您还可以通过设置 BUILDAH_CPPFLAGS 环境变量来设置默认的 CPPFLAGS（例如，export BUILDAH_CPPFLAGS=”-DDEBUG”）。

--cpu-period=limit

Set the CPU period for the Completely Fair Scheduler (CFS), which is a duration in microseconds. Once the container’s CPU quota is used up, it will not be scheduled to run until the current period ends. Defaults to 100000 microseconds.
设置完全公平调度器（CFS）的 CPU 周期，单位为微秒。一旦容器的 CPU 配额用完，它将不会被调度运行，直到当前周期结束。默认为 100000 微秒。

On some systems, changing the resource limits may not be allowed for non-root users. For more details, see https://github.com/containers/podman/blob/main/troubleshooting.md#26-running-containers-with-resource-limits-fails-with-a-permissions-error
在某些系统上，非 root 用户可能无法更改资源限制。有关更多详细信息，请参阅 https://github.com/containers/podman/blob/main/troubleshooting.md#26-running-containers-with-resource-limits-fails-with-a-permissions-error

This option is not supported on cgroups V1 rootless systems.
此选项不支持 cgroups V1 无根系统。

--cpu-quota=limit

Limit the CPU Completely Fair Scheduler (CFS) quota.
限制 CPU 完全公平调度器（CFS）的配额。

Limit the container’s CPU usage. By default, containers run with the full CPU resource. The limit is a number in microseconds. If a number is provided, the container is allowed to use that much CPU time until the CPU period ends (controllable via --cpu-period).
限制容器的 CPU 使用率。默认情况下，容器以完整的 CPU 资源运行。限制是以微秒为单位的数字。如果提供了一个数字，容器可以使用那么多的 CPU 时间，直到 CPU 周期结束（可通过 --cpu-period 控制）。

On some systems, changing the resource limits may not be allowed for non-root users. For more details, see https://github.com/containers/podman/blob/main/troubleshooting.md#26-running-containers-with-resource-limits-fails-with-a-permissions-error
在某些系统上，非 root 用户可能无法更改资源限制。有关更多详细信息，请参阅 https://github.com/containers/podman/blob/main/troubleshooting.md#26-running-containers-with-resource-limits-fails-with-a-permissions-error

This option is not supported on cgroups V1 rootless systems.
此选项不支持 cgroups V1 无根系统。

--cpu-shares, -c=shares
--cpu-shares, -c=份额 ¶

CPU shares (relative weight).
CPU 份额（相对权重）。

By default, all containers get the same proportion of CPU cycles. This proportion can be modified by changing the container’s CPU share weighting relative to the combined weight of all the running containers. Default weight is 1024.
默认情况下，所有容器获得相同比例的 CPU 周期。可以通过修改容器的 CPU 份额权重相对于所有运行容器的组合权重来修改此比例。默认权重为 1024。

The proportion only applies when CPU-intensive processes are running. When tasks in one container are idle, other containers can use the left-over CPU time. The actual amount of CPU time varies depending on the number of containers running on the system.
仅当运行 CPU 密集型进程时，比例才适用。当一个容器中的任务处于空闲状态时，其他容器可以使用剩余的 CPU 时间。实际的 CPU 时间量取决于系统上运行的容器数量。

For example, consider three containers, one has a cpu-share of 1024 and two others have a cpu-share setting of 512. When processes in all three containers attempt to use 100% of CPU, the first container receives 50% of the total CPU time. If a fourth container is added with a cpu-share of 1024, the first container only gets 33% of the CPU. The remaining containers receive 16.5%, 16.5% and 33% of the CPU.
例如，考虑三个容器，一个的 cpu-share 为 1024，另外两个的 cpu-share 设置为 512。当所有三个容器中的进程尝试使用 CPU 的 100% 时，第一个容器将获得总 CPU 时间的 50%。如果添加一个 cpu-share 为 1024 的第四个容器，则第一个容器只能获得 CPU 的 33%。其余容器分别获得 CPU 的 16.5%，16.5% 和 33%。

On a multi-core system, the shares of CPU time are distributed over all CPU cores. Even if a container is limited to less than 100% of CPU time, it can use 100% of each individual CPU core.
在多核系统上，CPU 时间的份额分布在所有 CPU 核心上。即使容器被限制在少于 100% 的 CPU 时间，它仍然可以使用每个单独的 CPU 核心的 100%。

For example, consider a system with more than three cores. If the container C0 is started with --cpu-shares=512 running one process, and another container C1 with --cpu-shares=1024 running two processes, this can result in the following division of CPU shares:
例如，考虑一个具有三个以上核心的系统。如果容器 C0 使用 --cpu-shares=512 启动并运行一个进程，另一个容器 C1 使用 --cpu-shares=1024 启动并运行两个进程，这可能导致 CPU 分配如下：

PID	container	CPU	CPU share CPU 分配
100	C0	0	100% of CPU0 CPU0 的 100%
101	C1	1	100% of CPU1 CPU1 的 100%
102	C1	2	100% of CPU2 CPU2 的 100%

On some systems, changing the resource limits may not be allowed for non-root users. For more details, see https://github.com/containers/podman/blob/main/troubleshooting.md#26-running-containers-with-resource-limits-fails-with-a-permissions-error
在某些系统上，非 root 用户可能无法更改资源限制。有关更多详细信息，请参阅 https://github.com/containers/podman/blob/main/troubleshooting.md#26-running-containers-with-resource-limits-fails-with-a-permissions-error

This option is not supported on cgroups V1 rootless systems.
此选项不支持 cgroups V1 无根系统。

--cpuset-cpus=number

CPUs in which to allow execution. Can be specified as a comma-separated list (e.g. 0,1), as a range (e.g. 0-3), or any combination thereof (e.g. 0-3,7,11-15).
允许执行的 CPU。可以指定为逗号分隔的列表（例如 0,1），作为范围（例如 0-3），或两者的任意组合（例如 0-3,7,11-15）。

On some systems, changing the resource limits may not be allowed for non-root users. For more details, see https://github.com/containers/podman/blob/main/troubleshooting.md#26-running-containers-with-resource-limits-fails-with-a-permissions-error
在某些系统上，非 root 用户可能无法更改资源限制。有关更多详细信息，请参阅 https://github.com/containers/podman/blob/main/troubleshooting.md#26-running-containers-with-resource-limits-fails-with-a-permissions-error

This option is not supported on cgroups V1 rootless systems.
此选项不支持 cgroups V1 无根系统。

--cpuset-mems=nodes

Memory nodes (MEMs) in which to allow execution (0-3, 0,1). Only effective on NUMA systems.
允许执行的内存节点（MEMs）（0-3, 0,1）。仅在 NUMA 系统上有效。

If there are four memory nodes on the system (0-3), use --cpuset-mems=0,1 then processes in the container only uses memory from the first two memory nodes.
如果系统上有四个内存节点（0-3），则使用--cpuset-mems=0,1，然后容器中的进程仅使用来自前两个内存节点的内存。

On some systems, changing the resource limits may not be allowed for non-root users. For more details, see https://github.com/containers/podman/blob/main/troubleshooting.md#26-running-containers-with-resource-limits-fails-with-a-permissions-error
在某些系统上，非 root 用户可能无法更改资源限制。有关更多详细信息，请参阅 https://github.com/containers/podman/blob/main/troubleshooting.md#26-running-containers-with-resource-limits-fails-with-a-permissions-error

This option is not supported on cgroups V1 rootless systems.
此选项不支持 cgroups V1 无根系统。

--creds=[username[:password]]
--creds=[用户名[:密码]] ¶

The [username[:password]] to use to authenticate with the registry, if required. If one or both values are not supplied, a command line prompt appears and the value can be entered. The password is entered without echo.
如果需要，用于与注册表进行身份验证的[用户名[:密码]]。如果一个或两个值未提供，将出现命令行提示，并可以输入该值。密码输入时不会显示。

Note that the specified credentials are only used to authenticate against target registries. They are not used for mirrors or when the registry gets rewritten (see containers-registries.conf(5)); to authenticate against those consider using a containers-auth.json(5) file.
请注意，指定的凭据仅用于对目标注册表进行身份验证。它们不用于镜像或注册表被重写时（请参阅 containers-registries.conf(5) ）；要对其进行身份验证，请考虑使用 containers-auth.json(5) 文件。

--decryption-key=key[:passphrase]

The [key[:passphrase]] to be used for decryption of images. Key can point to keys and/or certificates. Decryption is tried with all keys. If the key is protected by a passphrase, it is required to be passed in the argument and omitted otherwise.
用于解密图像的密钥[:密码]。密钥可以指向密钥和/或证书。尝试使用所有密钥进行解密。如果密钥受密码保护，则需要在参数中传递密码，否则应省略。

--device=host-device[:container-device][:permissions]
--device=主机设备[:容器设备][:权限] ¶

Add a host device to the container. Optional permissions parameter can be used to specify device permissions by combining r for read, w for write, and m for mknod(2).
将主机设备添加到容器中。可选的权限参数可用于通过组合 r 代表读取，w 代表写入，m 代表 mknod(2) 来指定设备权限。

Example: --device=/dev/sdc:/dev/xvdc:rwm.
示例: --device=/dev/sdc:/dev/xvdc:rwm.

Note: if host-device is a symbolic link then it is resolved first. The container only stores the major and minor numbers of the host device.
注意: 如果主机设备是一个符号链接，则首先解析它。容器仅存储主机设备的主次编号。

Podman may load kernel modules required for using the specified device. The devices that Podman loads modules for when necessary are: /dev/fuse.
Podman 可能会加载使用指定设备所需的内核模块。Podman 在必要时加载模块的设备有: /dev/fuse。

In rootless mode, the new device is bind mounted in the container from the host rather than Podman creating it within the container space. Because the bind mount retains its SELinux label on SELinux systems, the container can get permission denied when accessing the mounted device. Modify SELinux settings to allow containers to use all device labels via the following command:
在无根模式下，新设备是从主机中绑定挂载到容器中，而不是 Podman 在容器空间内创建它。由于绑定挂载在 SELinux 系统上保留其 SELinux 标签，当容器访问挂载的设备时可能会出现权限被拒绝的情况。通过以下命令修改 SELinux 设置以允许容器使用所有设备标签：

$ sudo setsebool -P container_use_devices=true

Note: if the user only has access rights via a group, accessing the device from inside a rootless container fails. The crun(1) runtime offers a workaround for this by adding the option --annotation run.oci.keep_original_groups=1.
注意：如果用户只有通过组访问权限，则无法从无根容器内访问设备。crun(1) 运行时提供了一个解决方法，通过添加选项 --annotation run.oci.keep_original_groups=1。

--disable-compression, -D

Don’t compress filesystem layers when building the image unless it is required by the location where the image is being written. This is the default setting, because image layers are compressed automatically when they are pushed to registries, and images being written to local storage only need to be decompressed again to be stored. Compression can be forced in all cases by specifying --disable-compression=false.
在构建镜像时，除非在写入镜像的位置需要，否则不要压缩文件系统层。这是默认设置，因为当图像推送到注册表时，图像层会自动压缩，并且写入本地存储的图像只需要再次解压缩即可存储。可以通过指定 --disable-compression=false 强制在所有情况下进行压缩。

--dns=ipaddr

Set custom DNS servers.
设置自定义 DNS 服务器。

This option can be used to override the DNS configuration passed to the container. Typically this is necessary when the host DNS configuration is invalid for the container (e.g., 127.0.0.1). When this is the case the --dns flag is necessary for every run.
此选项可用于覆盖传递给容器的 DNS 配置。通常在主机 DNS 配置对容器无效时（例如，127.0.0.1）需要使用此选项。在这种情况下，每次运行都需要使用 --dns 标志。

The special value none can be specified to disable creation of /etc/resolv.conf in the container by Podman. The /etc/resolv.conf file in the image is used without changes.
可以指定特殊值 none 来禁用 Podman 在容器中创建 /etc/resolv.conf。镜像中的 /etc/resolv.conf 文件将不会更改地使用。

This option cannot be combined with --network that is set to none.
此选项不能与设置为 none 的 --network 结合使用。

Note: this option takes effect only during RUN instructions in the build. It does not affect /etc/resolv.conf in the final image.
注意：此选项仅在构建中的运行指令期间生效。它不会影响最终镜像中的 /etc/resolv.conf。

--dns-option=option

Set custom DNS options to be used during the build.
设置在构建过程中使用的自定义 DNS 选项。

--dns-search=domain --dns-search=域名 ¶

Set custom DNS search domains to be used during the build.
设置在构建过程中使用的自定义 DNS 搜索域。

--env=env[=value]

Add a value (e.g. env=value) to the built image. Can be used multiple times. If neither = nor a value are specified, but env is set in the current environment, the value from the current environment is added to the image. To remove an environment variable from the built image, use the --unsetenv option.
将一个值（例如 env=value）添加到构建的镜像中。可以多次使用。如果未指定 = 或值，但当前环境中设置了 env，则将当前环境中的值添加到镜像中。要从构建的镜像中删除环境变量，请使用 --unsetenv 选项。

--farm --农场 ¶

This option specifies the name of the farm to be used in the build process.
此选项指定在构建过程中要使用的农场的名称。

This option specifies the name of the farm to be used in the build process.
此选项指定在构建过程中要使用的农场的名称。

--file, -f=Containerfile

Specifies a Containerfile which contains instructions for building the image, either a local file or an http or https URL. If more than one Containerfile is specified, FROM instructions are only be accepted from the last specified file.
指定一个 Containerfile，其中包含构建镜像的指令，可以是本地文件或 http 或 https URL。如果指定了多个 Containerfile，则仅从最后指定的文件中接受 FROM 指令。

If a build context is not specified, and at least one Containerfile is a local file, the directory in which it resides is used as the build context.
如果未指定构建上下文，并且至少有一个 Containerfile 是本地文件，则使用其所在的目录作为构建上下文。

Specifying the option -f - causes the Containerfile contents to be read from stdin.
指定选项 -f - 会导致从标准输入读取 Containerfile 内容。

--force-rm

Always remove intermediate containers after a build, even if the build fails (default true).
构建后始终删除中间容器，即使构建失败（默认为 true）。

--format

Control the format for the built image’s manifest and configuration data. Recognized formats include oci (OCI image-spec v1.0, the default) and docker (version 2, using schema format 2 for the manifest).
控制构建图像的清单和配置数据的格式。可识别的格式包括 oci（OCI 图像规范 v1.0，默认值）和 docker（版本 2，使用清单的模式格式 2）。

Note: You can also override the default format by setting the BUILDAH_FORMAT environment variable. export BUILDAH_FORMAT=docker
注意：您还可以通过设置 BUILDAH_FORMAT 环境变量来覆盖默认格式。 export BUILDAH_FORMAT=docker

--from

Overrides the first FROM instruction within the Containerfile. If there are multiple FROM instructions in a Containerfile, only the first is changed.
覆盖 Containerfile 中的第一个 FROM 指令。如果在 Containerfile 中有多个 FROM 指令，则只更改第一个。

With the remote podman client, not all container transports work as expected. For example, oci-archive:/x.tar references /x.tar on the remote machine instead of on the client. When using podman remote clients it is best to restrict use to containers-storage, and docker:// transports.
使用远程 podman 客户端时，并非所有容器传输都能按预期工作。例如，oci-archive:/x.tar 引用的是远程机器上的 /x.tar 而不是客户端上的。在使用 podman 远程客户端时，最好限制使用 containers-storage 和 docker:// 传输。

--group-add=group | keep-groups

Assign additional groups to the primary user running within the container process.
为运行在容器进程内的主要用户分配额外的组。

• keep-groups is a special flag that tells Podman to keep the supplementary group access.
  keep-groups 是一个特殊标志，告诉 Podman 保持附加组访问权限。

Allows container to use the user’s supplementary group access. If file systems or devices are only accessible by the rootless user’s group, this flag tells the OCI runtime to pass the group access into the container. Currently only available with the crun OCI runtime. Note: keep-groups is exclusive, other groups cannot be specified with this flag. (Not available for remote commands, including Mac and Windows (excluding WSL2) machines)
允许容器使用用户的附加组访问权限。如果文件系统或设备仅可由无根用户组访问，则此标志告诉 OCI 运行时将组访问权限传递到容器中。目前仅适用于 crun OCI 运行时。注意： keep-groups 是独占的，其他组不能与此标志一起指定。（不适用于远程命令，包括 Mac 和 Windows（不包括 WSL2）机器）

--help, -h --help，-h ¶

Print usage statement 打印使用说明

--hooks-dir=path

Each *.json file in the path configures a hook for buildah build containers. For more details on the syntax of the JSON files and the semantics of hook injection. Buildah currently support both the 1.0.0 and 0.1.0 hook schemas, although the 0.1.0 schema is deprecated.
路径中的每个 *.json 文件都配置了用于构建 buildah 构建容器的钩子。有关 JSON 文件语法和钩子注入语义的更多详细信息。Buildah 目前支持 1.0.0 和 0.1.0 两种钩子模式，尽管 0.1.0 模式已被弃用。

This option may be set multiple times; paths from later options have higher precedence.
此选项可以设置多次；后续选项中的路径具有更高的优先级。

For the annotation conditions, buildah uses any annotations set in the generated OCI configuration.
对于注释条件，buildah 使用在生成的 OCI 配置中设置的任何注释。

For the bind-mount conditions, only mounts explicitly requested by the caller via --volume are considered. Bind mounts that buildah inserts by default (e.g. /dev/shm) are not considered.
对于绑定挂载条件，只考虑调用者通过 --volume 明确请求的挂载。buildah 默认插入的绑定挂载（例如 /dev/shm）不予考虑。

If --hooks-dir is unset for root callers, Buildah currently defaults to /usr/share/containers/oci/hooks.d and /etc/containers/oci/hooks.d in order of increasing precedence. Using these defaults is deprecated. Migrate to explicitly setting --hooks-dir.
如果 --hooks-dir 未设置给根调用者，Buildah 目前默认为 /usr/share/containers/oci/hooks.d 和 /etc/containers/oci/hooks.d，按优先级递增的顺序。使用这些默认值已被弃用。请迁移到显式设置 --hooks-dir。

--http-proxy

By default proxy environment variables are passed into the container if set for the Podman process. This can be disabled by setting the value to false. The environment variables passed in include http_proxy, https_proxy, ftp_proxy, no_proxy, and also the upper case versions of those. This option is only needed when the host system must use a proxy but the container does not use any proxy. Proxy environment variables specified for the container in any other way overrides the values that have been passed through from the host. (Other ways to specify the proxy for the container include passing the values with the --env flag, or hard coding the proxy environment at container build time.) When used with the remote client it uses the proxy environment variables that are set on the server process.
默认情况下，如果为 Podman 进程设置了代理环境变量，则这些变量将传递到容器中。可以通过将值设置为 false 来禁用此功能。传递的环境变量包括 http_proxy、https_proxy、ftp_proxy、no_proxy，以及这些变量的大写版本。只有在主机系统必须使用代理但容器不使用任何代理时才需要此选项。以其他方式为容器指定的代理环境变量将覆盖从主机传递的值。（为容器指定代理的其他方式包括使用 --env 标志传递值，或在容器构建时硬编码代理环境。）与远程客户端一起使用时，它使用在服务器进程上设置的代理环境变量。

Defaults to true. 默认为真。

--identity-label

Adds default identity label io.buildah.version if set. (default true).
如果设置，添加默认身份标签 io.buildah.version 。（默认为真）。

--ignorefile

Path to an alternative .containerignore file.
替代的 .containerignore 文件路径。

--iidfile=ImageIDfile

Write the built image’s ID to the file. When --platform is specified more than once, attempting to use this option triggers an error.
将构建的镜像 ID 写入文件。当指定 --platform 多次时，尝试使用此选项会触发错误。

--ipc=how

Sets the configuration for IPC namespaces when handling RUN instructions. The configured value can be “” (the empty string) or “container” to indicate that a new IPC namespace is created, or it can be “host” to indicate that the IPC namespace in which podman itself is being run is reused, or it can be the path to an IPC namespace which is already in use by another process.
在处理 RUN 指令时设置 IPC 命名空间的配置。配置的值可以是“”（空字符串）或“container”表示创建新的 IPC 命名空间，也可以是“host”表示重用 podman 自身正在运行的 IPC 命名空间，或者可以是已被另一个进程使用的 IPC 命名空间的路径。

--isolation=type

Controls what type of isolation is used for running processes as part of RUN instructions. Recognized types include oci (OCI-compatible runtime, the default), rootless (OCI-compatible runtime invoked using a modified configuration and its --rootless option enabled, with --no-new-keyring --no-pivot added to its create invocation, with network and UTS namespaces disabled, and IPC, PID, and user namespaces enabled; the default for unprivileged users), and chroot (an internal wrapper that leans more toward chroot(1) than container technology).
控制作为 RUN 指令的一部分运行进程时使用的隔离类型。可识别的类型包括 oci（OCI 兼容运行时，默认值）、rootless（使用修改后的配置和其--rootless 选项启用的 OCI 兼容运行时，其 create 调用中添加了--no-new-keyring --no-pivot，网络和 UTS 命名空间被禁用，IPC、PID 和用户命名空间被启用；非特权用户的默认值）和 chroot（更倾向于 chroot(1)而不是容器技术的内部包装器）。

Note: You can also override the default isolation type by setting the BUILDAH_ISOLATION environment variable. export BUILDAH_ISOLATION=oci
注意：您还可以通过设置 BUILDAH_ISOLATION 环境变量来覆盖默认的隔离类型。 export BUILDAH_ISOLATION=oci

--jobs=number

Run up to N concurrent stages in parallel. If the number of jobs is greater than 1, stdin is read from /dev/null. If 0 is specified, then there is no limit in the number of jobs that run in parallel.
在并行运行最多 N 个阶段。如果作业数量大于 1，则从 /dev/null 读取标准输入。如果指定为 0，则并行运行的作业数量没有限制。

--label=label

Add an image label (e.g. label=value) to the image metadata. Can be used multiple times.
将图像标签（例如 label=value）添加到图像元数据中。可以多次使用。

Users can set a special LABEL io.containers.capabilities=CAP1,CAP2,CAP3 in a Containerfile that specifies the list of Linux capabilities required for the container to run properly. This label specified in a container image tells Podman to run the container with just these capabilities. Podman launches the container with just the specified capabilities, as long as this list of capabilities is a subset of the default list.
用户可以在 Containerfile 中设置特殊的 LABEL io.containers.capabilities=CAP1,CAP2,CAP3，指定容器运行所需的 Linux 能力列表。在容器镜像中指定的此标签告诉 Podman 仅使用这些能力运行容器。只要这些能力列表是默认列表的子集，Podman 就会使用指定的能力启动容器。

If the specified capabilities are not in the default set, Podman prints an error message and runs the container with the default capabilities.
如果指定的能力不在默认集中，Podman 将打印错误消息，并使用默认能力运行容器。

--layer-label=label[=value]

Add an intermediate image label (e.g. label=value) to the intermediate image metadata. It can be used multiple times.
向中间镜像元数据添加一个中间镜像标签（例如 label=value）。可以多次使用。

If label is named, but neither = nor a value is provided, then the label is set to an empty value.
如果标签已命名，但未提供 = 或 value ，则该标签将设置为空值。

--layers

Cache intermediate images during the build process (Default is true).
在构建过程中缓存中间图像（默认值为 true ）。

Note: You can also override the default value of layers by setting the BUILDAH_LAYERS environment variable. export BUILDAH_LAYERS=true
注意：您也可以通过设置 BUILDAH_LAYERS 环境变量来覆盖层的默认值。 export BUILDAH_LAYERS=true

--local, -l --本地, -l ¶

Build image on local machine as well as on farm nodes.
在本地机器上构建镜像以及在农场节点上构建。

--logfile=filename --logfile=文件名 ¶

Log output which is sent to standard output and standard error to the specified file instead of to standard output and standard error. This option is not supported on the remote client, including Mac and Windows (excluding WSL2) machines.
将发送到标准输出和标准错误的日志输出发送到指定文件，而不是发送到标准输出和标准错误。此选项不受远程客户端支持，包括 Mac 和 Windows（不包括 WSL2）机器。

--memory, -m=number[unit]
--memory, -m=数字[单位] ¶

Memory limit. A unit can be b (bytes), k (kibibytes), m (mebibytes), or g (gibibytes).
内存限制。单位可以是 b（字节）、k（基比字节）、m（兆比字节）或 g（吉比字节）。

Allows the memory available to a container to be constrained. If the host supports swap memory, then the -m memory setting can be larger than physical RAM. If a limit of 0 is specified (not using -m), the container’s memory is not limited. The actual limit may be rounded up to a multiple of the operating system’s page size (the value is very large, that’s millions of trillions).
允许限制容器可用的内存。如果主机支持交换内存，那么 -m 内存设置可以大于物理 RAM。如果指定了 0 的限制（不使用 -m），则容器的内存不受限制。实际限制可能会舍入到操作系统页面大小的倍数（该值非常大，是百万亿的数量级）。

This option is not supported on cgroups V1 rootless systems.
此选项不支持 cgroups V1 无根系统。

--memory-swap=number[unit]

A limit value equal to memory plus swap. A unit can be b (bytes), k (kibibytes), m (mebibytes), or g (gibibytes).
一个等于内存加交换空间的限制值。单位可以是 b（字节）、k（kibibytes）、m（mebibytes）或 g（gibibytes）。

Must be used with the -m (--memory) flag. The argument value must be larger than that of -m (--memory) By default, it is set to double the value of --memory.
必须与 -m (--memory) 标志一起使用。参数值必须大于 -m (--memory) 的值。默认情况下，它设置为 --memory 值的两倍。

Set number to -1 to enable unlimited swap.
将数字设置为 -1 以启用无限交换。

This option is not supported on cgroups V1 rootless systems.
此选项不支持 cgroups V1 无根系统。

--network=mode, --net

Sets the configuration for network namespaces when handling RUN instructions.
设置处理 RUN 指令时的网络命名空间配置。

Valid mode values are: 有效的模式值为：

• none: no networking. 无：无网络连接。

• host: use the Podman host network stack. Note: the host mode gives the container full access to local system services such as D-bus and is therefore considered insecure.
  主机：使用 Podman 主机网络堆栈。注意：主机模式使容器完全访问本地系统服务，如 D-bus，因此被视为不安全。

• ns:path: path to a network namespace to join.
  ns:路径：要加入的网络命名空间的路径。

• private: create a new namespace for the container (default)
  private: 为容器创建一个新的命名空间（默认）

• <network name|ID>: Join the network with the given name or ID, e.g. use --network mynet to join the network with the name mynet. Only supported for rootful users.
  : 加入具有给定名称或 ID 的网络，例如，使用 --network mynet 加入名称为 mynet 的网络。仅支持 rootful 用户。

• slirp4netns[:OPTIONS,…]: use slirp4netns(1) to create a user network stack. This is the default for rootless containers. It is possible to specify these additional options, they can also be set with network_cmd_options in containers.conf:
  slirp4netns[:OPTIONS,…]: 使用 slirp4netns(1) 创建用户网络堆栈。这是无根容器的默认设置。可以指定这些附加选项，它们也可以在 containers.conf 中使用 network_cmd_options 进行设置：

  • allow_host_loopback=true|false: Allow slirp4netns to reach the host loopback IP (default is 10.0.2.2 or the second IP from slirp4netns cidr subnet when changed, see the cidr option below). The default is false.
    allow_host_loopback=true|false: 允许 slirp4netns 访问主机环回 IP（默认为 10.0.2.2 或 slirp4netns cidr 子网中的第二个 IP，当更改时，请参阅下面的 cidr 选项）。默认值为 false。

  • mtu=MTU: Specify the MTU to use for this network. (Default is 65520).
    mtu=MTU: 指定此网络使用的 MTU。（默认值为 65520 ）。

  • cidr=CIDR: Specify ip range to use for this network. (Default is 10.0.2.0/24).
    cidr=CIDR: 指定用于此网络的 IP 范围。（默认值为 10.0.2.0/24 ）。

  • enable_ipv6=true|false: Enable IPv6. Default is true. (Required for outbound_addr6).
    enable_ipv6=true|false: 启用 IPv6。默认为 true。（ outbound_addr6 所需）。

  • outbound_addr=INTERFACE: Specify the outbound interface slirp binds to (ipv4 traffic only).
    outbound_addr=INTERFACE: 指定 slirp 绑定到的出站接口（仅限 IPv4 流量）。

  • outbound_addr=IPv4: Specify the outbound ipv4 address slirp binds to.
    outbound_addr=IPv4: 指定 slirp 绑定到的出站 IPv4 地址。

  • outbound_addr6=INTERFACE: Specify the outbound interface slirp binds to (ipv6 traffic only).
    outbound_addr6=INTERFACE: 指定 slirp 绑定到的出站接口（仅限 IPv6 交通）。

  • outbound_addr6=IPv6: Specify the outbound ipv6 address slirp binds to.
    outbound_addr6=IPv6: 指定 slirp 绑定到的出站 IPv6 地址。

• pasta[:OPTIONS,…]: use pasta(1) to create a user-mode networking stack.
  pasta[:OPTIONS,…]: 使用 pasta(1) 创建用户模式网络堆栈。
  This is only supported in rootless mode.
  这仅在无根模式下支持。
  By default, IPv4 and IPv6 addresses and routes, as well as the pod interface name, are copied from the host. If port forwarding isn’t configured, ports are forwarded dynamically as services are bound on either side (init namespace or container namespace). Port forwarding preserves the original source IP address. Options described in pasta(1) can be specified as comma-separated arguments.
  默认情况下，IPv4 和 IPv6 地址和路由以及 Pod 接口名称都从主机复制。如果未配置端口转发，则端口将在两侧绑定服务时动态转发（init 命名空间或容器命名空间）。端口转发会保留原始源 IP 地址。可以将 pasta(1)中描述的选项指定为逗号分隔的参数。
  In terms of pasta(1) options, --config-net is given by default, in order to configure networking when the container is started, and --no-map-gw is also assumed by default, to avoid direct access from container to host using the gateway address. The latter can be overridden by passing --map-gw in the pasta-specific options (despite not being an actual pasta(1) option).
  在 pasta(1)选项方面，默认情况下会提供--config-net，以便在启动容器时配置网络，并且默认情况下也会假定--no-map-gw，以避免容器直接使用网关地址访问主机。后者可以通过在 pasta 特定选项中传递--map-gw 来覆盖（尽管这不是实际的 pasta(1)选项）。
  Also, -t none and -u none are passed to disable automatic port forwarding based on bound ports. Similarly, -T none and -U none are given to disable the same functionality from container to host.
  此外，-t none 和 -u none 被传递以禁用基于绑定端口的自动端口转发。类似地，-T none 和 -U none 被给予以禁用容器到主机的相同功能。
  Some examples: 一些例子：

  • pasta:--map-gw: Allow the container to directly reach the host using the gateway address.
    pasta:--map-gw: 允许容器直接使用网关地址访问主机。

  • pasta:--mtu,1500: Specify a 1500 bytes MTU for the tap interface in the container.
    pasta:--mtu,1500: 为容器中的 tap 接口指定一个 1500 字节的 MTU。

  • pasta:--ipv4-only,-a,10.0.2.0,-n,24,-g,10.0.2.2,--dns-forward,10.0.2.3,-m,1500,--no-ndp,--no-dhcpv6,--no-dhcp, equivalent to default slirp4netns(1) options: disable IPv6, assign 10.0.2.0/24 to the tap0 interface in the container, with gateway 10.0.2.3, enable DNS forwarder reachable at 10.0.2.3, set MTU to 1500 bytes, disable NDP, DHCPv6 and DHCP support.
    pasta:--ipv4-only,-a,10.0.2.0,-n,24,-g,10.0.2.2,--dns-forward,10.0.2.3,-m,1500,--no-ndp,--no-dhcpv6,--no-dhcp, 等同于默认的 slirp4netns(1) 选项：禁用 IPv6，在容器中为 tap0 接口分配 10.0.2.0/24 ，使用网关 10.0.2.3 ，启用可在 10.0.2.3 访问的 DNS 转发器，将 MTU 设置为 1500 字节，禁用 NDP、DHCPv6 和 DHCP 支持。

  • pasta:-I,tap0,--ipv4-only,-a,10.0.2.0,-n,24,-g,10.0.2.2,--dns-forward,10.0.2.3,--no-ndp,--no-dhcpv6,--no-dhcp, equivalent to default slirp4netns(1) options with Podman overrides: same as above, but leave the MTU to 65520 bytes
    pasta:-I,tap0,--ipv4-only,-a,10.0.2.0,-n,24,-g,10.0.2.2,--dns-forward,10.0.2.3,--no-ndp,--no-dhcpv6,--no-dhcp, 等同于默认的 slirp4netns(1) 选项，但具有 Podman 覆盖：与上述相同，但将 MTU 保留为 65520 字节。

  • pasta:-t,auto,-u,auto,-T,auto,-U,auto: enable automatic port forwarding based on observed bound ports from both host and container sides
    pasta:-t,auto,-u,auto,-T,auto,-U,auto: 根据主机和容器双方观察到的绑定端口启用自动端口转发

  • pasta:-T,5201: enable forwarding of TCP port 5201 from container to host, using the loopback interface instead of the tap interface for improved performance
    pasta:-T,5201: 启用将容器中的 TCP 端口 5201 转发到主机，使用环回接口而不是 tap 接口以提高性能

--no-cache --no-cache

Do not use existing cached images for the container build. Build from the start with a new set of cached layers.
不要在容器构建中使用现有的缓存图像。使用一组新的缓存层从头开始构建。

--no-hostname

Do not create the /etc/hostname file in the container for RUN instructions.
不要为 RUN 指令在容器中创建 /etc/hostname 文件。

By default, Buildah manages the /etc/hostname file, adding the container’s own hostname. When the --no-hostname option is set, the image’s /etc/hostname will be preserved unmodified if it exists.
默认情况下，Buildah 管理 /etc/hostname 文件，添加容器自己的主机名。当设置 --no-hostname 选项时，如果存在，将保留镜像的 /etc/hostname 文件，不做修改。

--no-hosts

Do not create /etc/hosts for the container. By default, Podman manages /etc/hosts, adding the container’s own IP address and any hosts from --add-host. --no-hosts disables this, and the image’s /etc/hosts is preserved unmodified.
不为容器创建 /etc/hosts。默认情况下，Podman 管理 /etc/hosts，添加容器自己的 IP 地址和任何来自 --add-host 的主机。--no-hosts 禁用此功能，镜像的 /etc/hosts 将保持不变。

This option conflicts with --add-host.
此选项与 --add-host 冲突。

--omit-history

Omit build history information in the built image. (default false).
在构建的镜像中省略构建历史信息。（默认为 false）。

This option is useful for the cases where end users explicitly want to set --omit-history to omit the optional History from built images or when working with images built using build tools that do not include History information in their images.
此选项对于最终用户明确希望将 --omit-history 设置为省略内置映像中的可选项 History 或者在使用不包含 History 信息的构建工具构建的映像时非常有用。

--os-feature=feature --os-feature=功能 ¶

Set the name of a required operating system feature for the image which is built. By default, if the image is not based on scratch, the base image’s required OS feature list is kept, if the base image specified any. This option is typically only meaningful when the image’s OS is Windows.
设置构建的镜像所需的操作系统功能的名称。默认情况下，如果镜像不是基于 scratch 构建的，则保留基础镜像的所需 OS 功能列表（如果基础镜像指定了任何）。此选项通常仅在镜像的操作系统为 Windows 时才有意义。

If feature has a trailing -, then the feature is removed from the set of required features which is listed in the image.
如果功能后面有一个尾随的 - ，则该功能将从列在镜像中的所需功能集中移除。

--os-version=version --os-version=版本 ¶

Set the exact required operating system version for the image which is built. By default, if the image is not based on scratch, the base image’s required OS version is kept, if the base image specified one. This option is typically only meaningful when the image’s OS is Windows, and is typically set in Windows base images, so using this option is usually unnecessary.
设置构建的镜像所需的确切操作系统版本。默认情况下，如果镜像不是基于 scratch 构建的，则保留基础镜像所需的操作系统版本（如果基础镜像指定了版本）。此选项通常仅在镜像的操作系统为 Windows 时才有意义，并且通常在 Windows 基础镜像中设置，因此通常不需要使用此选项。

--pid=pid

Sets the configuration for PID namespaces when handling RUN instructions. The configured value can be “” (the empty string) or “container” to indicate that a new PID namespace is created, or it can be “host” to indicate that the PID namespace in which podman itself is being run is reused, or it can be the path to a PID namespace which is already in use by another process.
在处理 RUN 指令时设置 PID 命名空间的配置。配置的值可以是“”（空字符串）或“container”表示创建新的 PID 命名空间，也可以是“host”表示重用 podman 自身正在运行的 PID 命名空间，或者可以是已被另一个进程使用的 PID 命名空间的路径。

--platforms=p1,p2,p3… --平台=p1,p2,p3… ¶

Build only on farm nodes that match the given platforms.
仅在与给定平台匹配的农场节点上构建。

--pull=policy

Pull image policy. The default is always.
拉取镜像策略。默认值为 always。

• always, true: Always pull the image and throw an error if the pull fails.
  always, true: 总是拉取镜像，并在拉取失败时抛出错误。

• missing: Only pull the image when it does not exist in the local containers storage. Throw an error if no image is found and the pull fails.
  仅在本地容器存储中不存在图像时才拉取图像。如果未找到图像并且拉取失败，则抛出错误。

• never, false: Never pull the image but use the one from the local containers storage. Throw an error when no image is found.
  从不，false：从本地容器存储中使用图像，而不是拉取图像。当找不到图像时抛出错误。

• newer: Pull if the image on the registry is newer than the one in the local containers storage. An image is considered to be newer when the digests are different. Comparing the time stamps is prone to errors. Pull errors are suppressed if a local image was found.
  较新：如果注册表上的图像比本地容器存储中的图像更新，则拉取。当摘要不同时，图像被视为更新。比较时间戳容易出错。如果找到本地图像，则拉取错误会被抑制。

--quiet, -q

Suppress output messages which indicate which instruction is being processed, and of progress when pulling images from a registry, and when writing the output image.
抑制输出消息，指示正在处理哪个指令，以及从注册表拉取图像和写入输出图像时的进度。

--retry=attempts

Number of times to retry pulling or pushing images between the registry and local storage in case of failure. Default is 3.
在发生失败时，重试在注册表和本地存储之间拉取或推送镜像的次数。默认值为 3。

--retry-delay=duration --retry-delay=持续时间 ¶

Duration of delay between retry attempts when pulling or pushing images between the registry and local storage in case of failure. The default is to start at two seconds and then exponentially back off. The delay is used when this value is set, and no exponential back off occurs.
在发生失败时，拉取或推送镜像在注册表和本地存储之间重试尝试之间的延迟持续时间。默认值是从两秒开始，然后指数级地减少。当设置了此值且没有指数级减少时，将使用延迟。

--rm

Remove intermediate containers after a successful build (default true).
在成功构建后删除中间容器（默认为 true）。

--runtime=path

The path to an alternate OCI-compatible runtime, which is used to run commands specified by the RUN instruction.
用于运行由 RUN 指令指定的命令的替代 OCI 兼容运行时的路径。

Note: You can also override the default runtime by setting the BUILDAH_RUNTIME environment variable. export BUILDAH_RUNTIME=/usr/local/bin/runc
注意: 您还可以通过设置 BUILDAH_RUNTIME 环境变量来覆盖默认运行时。 export BUILDAH_RUNTIME=/usr/local/bin/runc

--runtime-flag=flag

Adds global flags for the container runtime. To list the supported flags, please consult the manpages of the selected container runtime.
为容器运行时添加全局标志。要列出支持的标志，请查阅所选容器运行时的 man 手册。

Note: Do not pass the leading -- to the flag. To pass the runc flag --log-format json to buildah build, the option given is --runtime-flag log-format=json.
注意：不要将前导的 -- 传递给标志。要将 runc 标志 --log-format json 传递给 buildah build，给定的选项是 --runtime-flag log-format=json。

--sbom=preset --sbom=preset

Generate SBOMs (Software Bills Of Materials) for the output image by scanning the working container and build contexts using the named combination of scanner image, scanner commands, and merge strategy. Must be specified with one or more of --sbom-image-output, --sbom-image-purl-output, --sbom-output, and --sbom-purl-output. Recognized presets, and the set of options which they equate to:
通过扫描工作容器和构建上下文生成输出镜像的软件清单（SBOMs），使用命名的扫描器镜像、扫描器命令和合并策略的组合。必须与 --sbom-image-output、--sbom-image-purl-output、--sbom-output 和 --sbom-purl-output 中的一个或多个一起指定。已识别的预设值，以及它们等同于的选项集：

• “syft”, “syft-cyclonedx”: --sbom-scanner-image=ghcr.io/anchore/syft --sbom-scanner-command=”/syft scan -q dir:{ROOTFS} --output cyclonedx-json={OUTPUT}” --sbom-scanner-command=”/syft scan -q dir:{CONTEXT} --output cyclonedx-json={OUTPUT}” --sbom-merge-strategy=merge-cyclonedx-by-component-name-and-version

• “syft-spdx”: --sbom-scanner-image=ghcr.io/anchore/syft --sbom-scanner-command=”/syft scan -q dir:{ROOTFS} --output spdx-json={OUTPUT}” --sbom-scanner-command=”/syft scan -q dir:{CONTEXT} --output spdx-json={OUTPUT}” --sbom-merge-strategy=merge-spdx-by-package-name-and-versioninfo

• “trivy”, “trivy-cyclonedx”: --sbom-scanner-image=ghcr.io/aquasecurity/trivy --sbom-scanner-command=”trivy filesystem -q {ROOTFS} --format cyclonedx --output {OUTPUT}” --sbom-scanner-command=”trivy filesystem -q {CONTEXT} --format cyclonedx --output {OUTPUT}” --sbom-merge-strategy=merge-cyclonedx-by-component-name-and-version
  "trivy", "trivy-cyclonedx": --sbom-scanner-image=ghcr.io/aquasecurity/trivy --sbom-scanner-command="trivy filesystem -q {ROOTFS} --format cyclonedx --output {OUTPUT}" --sbom-scanner-command="trivy filesystem -q {CONTEXT} --format cyclonedx --output {OUTPUT}" --sbom-merge-strategy=merge-cyclonedx-by-component-name-and-version

• “trivy-spdx”: --sbom-scanner-image=ghcr.io/aquasecurity/trivy --sbom-scanner-command=”trivy filesystem -q {ROOTFS} --format spdx-json --output {OUTPUT}” --sbom-scanner-command=”trivy filesystem -q {CONTEXT} --format spdx-json --output {OUTPUT}” --sbom-merge-strategy=merge-spdx-by-package-name-and-versioninfo
  "trivy-spdx": --sbom-scanner-image=ghcr.io/aquasecurity/trivy --sbom-scanner-command="trivy filesystem -q {ROOTFS} --format spdx-json --output {OUTPUT}" --sbom-scanner-command="trivy filesystem -q {CONTEXT} --format spdx-json --output {OUTPUT}" --sbom-merge-strategy=merge-spdx-by-package-name-and-versioninfo

--sbom-image-output=path
--sbom-image-output=path

When generating SBOMs, store the generated SBOM in the specified path in the output image. There is no default.
在生成 SBOM 时，将生成的 SBOM 存储在输出镜像中指定的路径中。没有默认值。

--sbom-image-purl-output=path

When generating SBOMs, scan them for PURL (package URL) information, and save a list of found PURLs to the specified path in the output image. There is no default.
在生成 SBOM 时，扫描它们以获取 PURL（软件包 URL）信息，并将找到的 PURL 列表保存到输出镜像中指定的路径中。没有默认值。

--sbom-merge-strategy=method
--sbom-merge-strategy=方法 ¶

If more than one --sbom-scanner-command value is being used, use the specified method to merge the output from later commands with output from earlier commands. Recognized values include:
如果正在使用多个 --sbom-scanner-command 值，则使用指定的方法将后续命令的输出与先前命令的输出合并。可识别的值包括：

• cat Concatenate the files.
  cat 连接文件。

• merge-cyclonedx-by-component-name-and-version Merge the “component” fields of JSON documents, ignoring values from documents when the combination of their “name” and “version” values is already present. Documents are processed in the order in which they are generated, which is the order in which the commands that generate them were specified.
  按组件名称和版本合并 JSON 文档的“组件”字段，当它们的“名称”和“版本”值的组合已经存在时，忽略文档中的值。文档按生成顺序处理，这是生成它们的命令指定的顺序。

• merge-spdx-by-package-name-and-versioninfo Merge the “package” fields of JSON documents, ignoring values from documents when the combination of their “name” and “versionInfo” values is already present. Documents are processed in the order in which they are generated, which is the order in which the commands that generate them were specified.
  按软件包名称和版本信息合并 JSON 文档的“软件包”字段，当它们的“名称”和“版本信息”值的组合已经存在时，忽略文档中的值。文档按生成顺序处理，这是生成它们的命令指定的顺序。

--sbom-output=file --sbom-output=file

When generating SBOMs, store the generated SBOM in the named file on the local filesystem. There is no default.
在生成 SBOM 时，将生成的 SBOM 存储在本地文件系统中的指定文件中。没有默认值。

--sbom-purl-output=file

When generating SBOMs, scan them for PURL (package URL) information, and save a list of found PURLs to the named file in the local filesystem. There is no default.
在生成 SBOM 时，扫描它们以获取 PURL（软件包 URL）信息，并将找到的 PURL 列表保存到本地文件系统中的指定文件中。没有默认值。

--sbom-scanner-command=image

Generate SBOMs by running the specified command from the scanner image. If multiple commands are specified, they are run in the order in which they are specified. These text substitutions are performed:
运行扫描器镜像中指定的命令生成 SBOM。如果指定了多个命令，则按照指定的顺序依次运行。执行这些文本替换：

• {ROOTFS} The root of the built image’s filesystem, bind mounted.
  {ROOTFS} 构建镜像文件系统的根目录，绑定挂载。

• {CONTEXT} The build context and additional build contexts, bind mounted.
  {CONTEXT} 构建上下文和额外的构建上下文，绑定挂载。

• {OUTPUT} The name of a temporary output file, to be read and merged with others or copied elsewhere.
  {OUTPUT} 一个临时输出文件的名称，用于读取和合并其他文件或复制到其他位置。

--sbom-scanner-image=image

Generate SBOMs using the specified scanner image.
使用指定的扫描器镜像生成 SBOMs。

--secret=id=id,src=path

Pass secret information used in the Containerfile for building images in a safe way that are not stored in the final image, or be seen in other stages. The secret is mounted in the container at the default location of /run/secrets/id.
以安全的方式传递在 Containerfile 中用于构建镜像的秘密信息，这些信息不会存储在最终镜像中，也不会在其他阶段中看到。秘密被挂载在容器中的默认位置 /run/secrets/id 。

To later use the secret, use the --mount option in a RUN instruction within a Containerfile:
为了以后使用该密钥，请在 Containerfile 内的 RUN 指令中使用--mount 选项：

RUN --mount=type=secret,id=mysecret cat /run/secrets/mysecret

--security-opt=option --security-opt=option

Security Options 安全选项

• apparmor=unconfined : Turn off apparmor confinement for the container
  apparmor=unconfined ：为容器关闭 apparmor 限制

• apparmor=alternate-profile : Set the apparmor confinement profile for the container
  apparmor=alternate-profile ：为容器设置 apparmor 限制配置文件

• label=user:USER : Set the label user for the container processes
  label=user:USER ：为容器进程设置标签用户

• label=role:ROLE : Set the label role for the container processes
  label=role:ROLE ：为容器进程设置标签角色

• label=type:TYPE : Set the label process type for the container processes
  label=type:TYPE ：为容器进程设置标签进程类型

• label=level:LEVEL : Set the label level for the container processes
  label=level:LEVEL ：为容器进程设置标签级别

• label=filetype:TYPE : Set the label file type for the container files
  label=filetype:TYPE ：设置容器文件的标签文件类型

• label=disable : Turn off label separation for the container
  label=disable ：关闭容器的标签分离

• no-new-privileges : Not supported  no-new-privileges ：不支持

• seccomp=unconfined : Turn off seccomp confinement for the container
  seccomp=unconfined ：为容器关闭 seccomp 限制

• seccomp=profile.json : JSON file to be used as the seccomp filter for the container.
  seccomp=profile.json ：用作容器 seccomp 过滤器的 JSON 文件

--shm-size=number[unit]
--shm-size=number[unit]

Size of /dev/shm. A unit can be b (bytes), k (kibibytes), m (mebibytes), or g (gibibytes). If the unit is omitted, the system uses bytes. If the size is omitted, the default is 64m. When size is 0, there is no limit on the amount of memory used for IPC by the container. This option conflicts with --ipc=host.
/dev/shm 的大小。单位可以是 b（字节）、k（kibibytes）、m（mebibytes）或 g（gibibytes）。如果省略单位，则系统使用字节。如果省略大小，则默认为 64m。当大小为 0 时，容器使用的 IPC 内存量没有限制。此选项与 --ipc=host 冲突。

--skip-unused-stages --跳过未使用的阶段 ¶

Skip stages in multi-stage builds which don’t affect the target stage. (Default: true).
跳过在多阶段构建中不影响目标阶段的阶段。(默认值：true)。

--squash --压缩 ¶

Squash all of the image’s new layers into a single new layer; any preexisting layers are not squashed.
将图像的所有新图层压缩成一个新图层；任何现有图层不会被压缩。

--squash-all

Squash all of the new image’s layers (including those inherited from a base image) into a single new layer.
将新图像的所有图层（包括从基础图像继承的图层）压缩成一个新图层。

--ssh=default | id[=socket>

SSH agent socket or keys to expose to the build. The socket path can be left empty to use the value of default=$SSH_AUTH_SOCK
要暴露给构建的 SSH 代理套接字或密钥。套接字路径可以留空以使用 default=$SSH_AUTH_SOCK 的值

To later use the ssh agent, use the --mount option in a RUN instruction within a Containerfile:
要稍后使用 SSH 代理，请在 Containerfile 中的 RUN 指令中使用 --mount 选项：

RUN --mount=type=ssh,id=id mycmd

--tag, -t=imageName

Specifies the name which is assigned to the resulting image if the build process completes successfully. If imageName does not include a registry name, the registry name localhost is prepended to the image name.
指定在构建过程成功完成时分配给结果图像的名称。如果 imageName 不包括注册表名称，则在图像名称前添加注册表名称 localhost。

--target=stageName

Set the target build stage to build. When building a Containerfile with multiple build stages, --target can be used to specify an intermediate build stage by name as the final stage for the resulting image. Commands after the target stage is skipped.
将目标构建阶段设置为构建。在使用多个构建阶段的 Containerfile 构建时，--target 可用于指定一个中间构建阶段的名称作为结果图像的最终阶段。目标阶段之后的命令将被跳过。

--timestamp=seconds --timestamp=秒 ¶

Set the create timestamp to seconds since epoch to allow for deterministic builds (defaults to current time). By default, the created timestamp is changed and written into the image manifest with every commit, causing the image’s sha256 hash to be different even if the sources are exactly the same otherwise. When --timestamp is set, the created timestamp is always set to the time specified and therefore not changed, allowing the image’s sha256 hash to remain the same. All files committed to the layers of the image is created with the timestamp.
将创建时间戳设置为自纪元以来的秒数，以便进行确定性构建（默认为当前时间）。默认情况下，每次提交时都会更改并写入图像清单中的创建时间戳，即使源代码完全相同，也会导致图像的 sha256 哈希不同。当设置 --timestamp 时，创建时间戳始终设置为指定时间，因此不会更改，从而使图像的 sha256 哈希保持不变。提交到图像层的所有文件都使用该时间戳创建。

If the only instruction in a Containerfile is FROM, this flag has no effect.
如果 Containerfile 中的唯一指令是 FROM ，则此标志无效。

--tls-verify

Require HTTPS and verify certificates when contacting registries (default: true). If explicitly set to true, TLS verification is used. If set to false, TLS verification is not used. If not specified, TLS verification is used unless the target registry is listed as an insecure registry in containers-registries.conf(5)
在联系注册表时需要 HTTPS 并验证证书（默认值为 true）。如果显式设置为 true，则使用 TLS 验证。如果设置为 false，则不使用 TLS 验证。如果未指定，则除非目标注册表在 containers-registries.conf(5) 中被列为不安全注册表，否则将使用 TLS 验证。

--ulimit=type=soft-limit[:hard-limit]

Specifies resource limits to apply to processes launched when processing RUN instructions. This option can be specified multiple times. Recognized resource types include: “core”: maximum core dump size (ulimit -c) “cpu”: maximum CPU time (ulimit -t) “data”: maximum size of a process’s data segment (ulimit -d) “fsize”: maximum size of new files (ulimit -f) “locks”: maximum number of file locks (ulimit -x) “memlock”: maximum amount of locked memory (ulimit -l) “msgqueue”: maximum amount of data in message queues (ulimit -q) “nice”: niceness adjustment (nice -n, ulimit -e) “nofile”: maximum number of open files (ulimit -n) “nproc”: maximum number of processes (ulimit -u) “rss”: maximum size of a process’s (ulimit -m) “rtprio”: maximum real-time scheduling priority (ulimit -r) “rttime”: maximum amount of real-time execution between blocking syscalls “sigpending”: maximum number of pending signals (ulimit -i) “stack”: maximum stack size (ulimit -s)
指定要应用于处理 RUN 指令时启动的进程的资源限制。此选项可以多次指定。已识别的资源类型包括：“core”：最大核心转储大小（ulimit -c）“cpu”：最大 CPU 时间（ulimit -t）“data”：进程数据段的最大大小（ulimit -d）“fsize”：新文件的最大大小（ulimit -f）“locks”：文件锁的最大数量（ulimit -x）“memlock”：锁定内存的最大量（ulimit -l）“msgqueue”：消息队列中的数据量最大值（ulimit -q）“nice”：优先级调整（nice -n，ulimit -e）“nofile”：打开文件的最大数量（ulimit -n）“nproc”：进程的最大数量（ulimit -u）“rss”：进程的最大大小（ulimit -m）“rtprio”：最大实时调度优先级（ulimit -r）“rttime”：在阻塞系统调用之间的最大实时执行时间“sigpending”：挂起信号的最大数量（ulimit -i）“stack”：最大堆栈大小（ulimit -s）

--unsetenv=env --unsetenv=env

Unset environment variables from the final image.
从最终镜像中取消设置环境变量。

--unsetlabel=label

Unset the image label, causing the label not to be inherited from the base image.
取消图像标签，导致标签不会从基础图像继承。

--userns=how --userns=如何 ¶

Sets the configuration for user namespaces when handling RUN instructions. The configured value can be “” (the empty string) or “container” to indicate that a new user namespace is created, it can be “host” to indicate that the user namespace in which podman itself is being run is reused, or it can be the path to a user namespace which is already in use by another process.
在处理 RUN 指令时设置用户命名空间的配置。配置的值可以是“”（空字符串）或“container”表示创建新的用户命名空间，也可以是“host”表示正在重用 podman 本身运行的用户命名空间，或者可以是另一个进程已经使用的用户命名空间的路径。

--userns-gid-map=mapping
--userns-gid-map=映射 ¶

Directly specifies a GID mapping to be used to set ownership, at the filesystem level, on the working container’s contents. Commands run when handling RUN instructions defaults to being run in their own user namespaces, configured using the UID and GID maps.
直接指定要在工作容器内容的文件系统级别上设置所有权的 GID 映射。处理 RUN 指令时运行的命令默认在其自己的用户命名空间中运行，使用 UID 和 GID 映射进行配置。

Entries in this map take the form of one or more triples of a starting in-container GID, a corresponding starting host-level GID, and the number of consecutive IDs which the map entry represents.
此映射中的条目采用一个或多个三元组的形式，其中包括一个起始容器内 GID、一个对应的起始主机级 GID，以及映射条目表示的连续 ID 数。

This option overrides the remap-gids setting in the options section of /etc/containers/storage.conf.
此选项覆盖了 /etc/containers/storage.conf 中选项部分中的 remap-gids 设置。

If this option is not specified, but a global --userns-gid-map setting is supplied, settings from the global option is used.
如果未指定此选项，但提供了全局 --userns-gid-map 设置，则使用全局选项中的设置。

If none of --userns-uid-map-user, --userns-gid-map-group, or --userns-gid-map are specified, but --userns-uid-map is specified, the GID map is set to use the same numeric values as the UID map.
如果未指定 --userns-uid-map-user、--userns-gid-map-group 或 --userns-gid-map 中的任何一个，但指定了 --userns-uid-map，则 GID 映射设置为使用与 UID 映射相同的数值。

--userns-gid-map-group=group
--userns-gid-map-group=group

Specifies that a GID mapping to be used to set ownership, at the filesystem level, on the working container’s contents, can be found in entries in the /etc/subgid file which correspond to the specified group. Commands run when handling RUN instructions defaults to being run in their own user namespaces, configured using the UID and GID maps. If --userns-uid-map-user is specified, but --userns-gid-map-group is not specified, podman assumes that the specified user name is also a suitable group name to use as the default setting for this option.
指定要用于在工作容器内容的文件系统级别上设置所有权的 GID 映射，可以在 /etc/subgid 文件中的条目中找到，这些条目对应于指定的组。处理 RUN 指令时运行的命令默认在其自己的用户命名空间中运行，使用 UID 和 GID 映射进行配置。如果指定了 --userns-uid-map-user，但未指定 --userns-gid-map-group，则 podman 假定指定的用户名也是一个适合用作此选项的默认设置的组名。

NOTE: When this option is specified by a rootless user, the specified mappings are relative to the rootless user namespace in the container, rather than being relative to the host as it is when run rootful.
注意：当根用户指定此选项时，指定的映射是相对于容器中的根用户命名空间，而不是相对于在 rootful 模式下运行时的主机。

--userns-uid-map=mapping
--userns-uid-map=mapping

Directly specifies a UID mapping to be used to set ownership, at the filesystem level, on the working container’s contents. Commands run when handling RUN instructions default to being run in their own user namespaces, configured using the UID and GID maps.
直接指定要在工作容器内容的文件系统级别上设置所有权的 UID 映射。处理 RUN 指令时运行的命令默认在其自己的用户命名空间中运行，使用 UID 和 GID 映射进行配置。

Entries in this map take the form of one or more triples of a starting in-container UID, a corresponding starting host-level UID, and the number of consecutive IDs which the map entry represents.
此映射中的条目采用一个或多个三元组的形式，其中包括一个起始容器内 UID、一个对应的起始主机级 UID，以及映射条目表示的连续 ID 数。

This option overrides the remap-uids setting in the options section of /etc/containers/storage.conf.
此选项覆盖了 /etc/containers/storage.conf 中选项部分中的 remap-uids 设置。

If this option is not specified, but a global --userns-uid-map setting is supplied, settings from the global option is used.
如果未指定此选项，但提供了全局 --userns-uid-map 设置，则使用全局选项中的设置。

If none of --userns-uid-map-user, --userns-gid-map-group, or --userns-uid-map are specified, but --userns-gid-map is specified, the UID map is set to use the same numeric values as the GID map.
如果未指定 --userns-uid-map-user、--userns-gid-map-group 或 --userns-uid-map 中的任何一个选项，但指定了 --userns-gid-map，则 UID 映射设置为使用与 GID 映射相同的数值。

--userns-uid-map-user=user

Specifies that a UID mapping to be used to set ownership, at the filesystem level, on the working container’s contents, can be found in entries in the /etc/subuid file which correspond to the specified user. Commands run when handling RUN instructions defaults to being run in their own user namespaces, configured using the UID and GID maps. If --userns-gid-map-group is specified, but --userns-uid-map-user is not specified, podman assumes that the specified group name is also a suitable user name to use as the default setting for this option.
指定要用于在工作容器内容的文件系统级别上设置所有权的 UID 映射，可以在 /etc/subuid 文件中找到与指定用户对应的条目。处理 RUN 指令时运行的命令默认在其自己的用户命名空间中运行，使用 UID 和 GID 映射进行配置。如果指定了 --userns-gid-map-group，但未指定 --userns-uid-map-user，则 podman 假定指定的组名也是适合用作此选项的默认设置的用户名称。

NOTE: When this option is specified by a rootless user, the specified mappings are relative to the rootless user namespace in the container, rather than being relative to the host as it is when run rootful.
注意：当根用户指定此选项时，指定的映射是相对于容器中的根用户命名空间，而不是相对于在 rootful 模式下运行时的主机。

--uts=how --uts=how

Sets the configuration for UTS namespaces when handling RUN instructions. The configured value can be “” (the empty string) or “container” to indicate that a new UTS namespace to be created, or it can be “host” to indicate that the UTS namespace in which podman itself is being run is reused, or it can be the path to a UTS namespace which is already in use by another process.
设置处理 RUN 指令时 UTS 命名空间的配置。配置的值可以是“”（空字符串）或“container”表示要创建一个新的 UTS 命名空间，也可以是“host”表示正在运行 podman 的 UTS 命名空间被重用，或者可以是另一个进程已经在使用的 UTS 命名空间的路径。

--volume, -v=[HOST-DIR:CONTAINER-DIR[:OPTIONS]]

Mount a host directory into containers when executing RUN instructions during the build.
在构建过程中执行 RUN 指令时，将主机目录挂载到容器中。

The OPTIONS are a comma-separated list and can be one or more of:
OPTIONS 是一个逗号分隔的列表，可以是一个或多个：

• [rw|ro] [读写|只读]

• [z|Z|O]

• [U]

• [[r]shared|[r]slave|[r]private]^[1]

The CONTAINER-DIR must be an absolute path such as /src/docs. The HOST-DIR must be an absolute path as well. Podman bind-mounts the HOST-DIR to the specified path when processing RUN instructions.
CONTAINER-DIR 必须是绝对路径，例如 /src/docs 。 HOST-DIR 也必须是绝对路径。在处理 RUN 指令时，Podman 将 HOST-DIR 绑定到指定的路径。

You can specify multiple -v options to mount one or more mounts.
您可以指定多个 -v 选项来挂载一个或多个挂载点。

You can add the :ro or :rw suffix to a volume to mount it read-only or read-write mode, respectively. By default, the volumes are mounted read-write. See examples.
您可以向卷添加 :ro 或 :rw 后缀，以将其挂载为只读或读写模式。默认情况下，卷是以读写模式挂载的。请参阅示例。

Chowning Volume Mounts

By default, Podman does not change the owner and group of source volume directories mounted. When running using user namespaces, the UID and GID inside the namespace may correspond to another UID and GID on the host.
默认情况下，Podman 不会更改挂载的源卷目录的所有者和组。在使用用户命名空间运行时，命名空间内的 UID 和 GID 可能对应主机上的另一个 UID 和 GID。

The :U suffix tells Podman to use the correct host UID and GID based on the UID and GID within the namespace, to change recursively the owner and group of the source volume.
:U 后缀告诉 Podman 根据命名空间内的 UID 和 GID 使用正确的主机 UID 和 GID，递归更改源卷的所有者和组。

Warning use with caution since this modifies the host filesystem.
警告谨慎使用，因为这会修改主机文件系统。

Labeling Volume Mounts

Labeling systems like SELinux require that proper labels are placed on volume content mounted into a container. Without a label, the security system might prevent the processes running inside the container from using the content. By default, Podman does not change the labels set by the OS.
类似 SELinux 的标签系统要求在挂载到容器中的卷内容上放置适当的标签。如果没有标签，安全系统可能会阻止容器内运行的进程使用内容。默认情况下，Podman 不会更改操作系统设置的标签。

To change a label in the container context, add one of these two suffixes :z or :Z to the volume mount. These suffixes tell Podman to relabel file objects on the shared volumes. The z option tells Podman that two containers share the volume content. As a result, Podman labels the content with a shared content label. Shared volume labels allow all containers to read/write content. The Z option tells Podman to label the content with a private unshared label. Only the current container can use a private volume.
要在容器上下文中更改标签，请在卷挂载中添加这两个后缀 :z 或 :Z 中的一个。这些后缀告诉 Podman 重新标记共享卷上的文件对象。 z 选项告诉 Podman 两个容器共享卷内容。因此，Podman 使用共享内容标签标记内容。共享卷标签允许所有容器读写内容。 Z 选项告诉 Podman 使用私有未共享标签标记内容。只有当前容器可以使用私有卷。

Note: Do not relabel system files and directories. Relabeling system content might cause other confined services on the host machine to fail. For these types of containers, disabling SELinux separation is recommended. The option --security-opt label=disable disables SELinux separation for the container. For example, if a user wanted to volume mount their entire home directory into the build containers, they need to disable SELinux separation.
注意: 不要重新标记系统文件和目录。重新标记系统内容可能会导致主机上其他受限服务失败。对于这些类型的容器，建议禁用 SELinux 分离。选项 --security-opt label=disable 用于禁用容器的 SELinux 分离。例如，如果用户想要将整个家目录挂载到构建容器中，他们需要禁用 SELinux 分离。

$ podman build --security-opt label=disable -v $HOME:/home/user .

Overlay Volume Mounts

The :O flag tells Podman to mount the directory from the host as a temporary storage using the Overlay file system. The RUN command containers are allowed to modify contents within the mountpoint and are stored in the container storage in a separate directory. In Overlay FS terms the source directory is the lower, and the container storage directory is the upper. Modifications to the mount point are destroyed when the RUN command finishes executing, similar to a tmpfs mount point.
:O 标志告诉 Podman 将主机上的目录作为临时存储使用 Overlay 文件系统挂载。 RUN 命令容器允许修改挂载点内的内容，并将其存储在容器存储中的一个单独目录中。在 Overlay FS 术语中，源目录是下层，容器存储目录是上层。对挂载点的修改在 RUN 命令执行完毕时被销毁，类似于 tmpfs 挂载点。

Any subsequent execution of RUN commands sees the original source directory content, any changes from previous RUN commands no longer exists.
任何后续执行 RUN 命令都会看到原始源目录内容，之前 RUN 命令的更改不再存在。

One use case of the overlay mount is sharing the package cache from the host into the container to allow speeding up builds.
一个 overlay 挂载的用例是将主机中的软件包缓存共享到容器中，以加快构建速度。

Note: 注意：

• Overlay mounts are not currently supported in rootless mode.
  在非 root 模式下，暂不支持 Overlay 挂载。

• The O flag is not allowed to be specified with the Z or z flags. Content mounted into the container is labeled with the private label. On SELinux systems, labels in the source directory needs to be readable by the container label. If not, SELinux container separation must be disabled for the container to work.
  不允许使用 O 标志与 Z 或 z 标志一起指定。挂载到容器中的内容带有私有标签。在 SELinux 系统上，源目录中的标签需要容器标签可读。如果不可读，则必须禁用容器的 SELinux 容器分离功能才能正常工作。

• Modification of the directory volume mounted into the container with an overlay mount can cause unexpected failures. Do not modify the directory until the container finishes running.
  使用叠加挂载修改挂载到容器中的目录卷可能导致意外故障。在容器完成运行之前，请勿修改目录。

By default bind mounted volumes are private. That means any mounts done inside containers are not be visible on the host and vice versa. This behavior can be changed by specifying a volume mount propagation property.
默认情况下，绑定挂载的卷是 private 的。这意味着容器内部进行的任何挂载对主机都不可见，反之亦然。可以通过指定卷挂载传播属性来更改此行为。

When the mount propagation policy is set to shared, any mounts completed inside the container on that volume is visible to both the host and container. When the mount propagation policy is set to slave, one way mount propagation is enabled and any mounts completed on the host for that volume is visible only inside of the container. To control the mount propagation property of volume use the :[r]shared, :[r]slave or :[r]private propagation flag. For mount propagation to work on the source mount point (mount point where source dir is mounted on) has to have the right propagation properties. For shared volumes, the source mount point has to be shared. And for slave volumes, the source mount has to be either shared or slave. ^[1]
当挂载传播策略设置为 shared 时，在容器内完成的任何挂载都对主机和容器可见。当挂载传播策略设置为 slave 时，启用单向挂载传播，并且主机上为该卷完成的任何挂载仅在容器内可见。要控制卷的挂载传播属性，请使用 :[r]shared 、 :[r]slave 或 :[r]private 传播标志。要使挂载传播在源挂载点（源目录挂载的挂载点）上工作，必须具有正确的传播属性。对于共享卷，源挂载点必须是共享的。对于从属卷，源挂载点必须是共享或从属的。 ^[1]

Use df <source-dir> to determine the source mount and then use findmnt -o TARGET,PROPAGATION <source-mount-dir> to determine propagation properties of source mount, if findmnt utility is not available, the source mount point can be determined by looking at the mount entry in /proc/self/mountinfo. Look at optional fields and see if any propagation properties are specified. shared:X means the mount is shared, master:X means the mount is slave and if nothing is there that means the mount is private. ^[1]
使用 df <source-dir> 确定源挂载点，然后使用 findmnt -o TARGET,PROPAGATION <source-mount-dir> 确定源挂载点的传播属性，如果 findmnt 实用程序不可用，可以通过查看 /proc/self/mountinfo 中的挂载条目来确定源挂载点。查看 optional fields 并查看是否指定了任何传播属性。 shared:X 意味着挂载是 shared ， master:X 意味着挂载是 slave ，如果没有任何内容，那意味着挂载是 private 。 ^[1]

To change propagation properties of a mount point use the mount command. For example, to bind mount the source directory /foo do mount --bind /foo /foo and mount --make-private --make-shared /foo. This converts /foo into a shared mount point. The propagation properties of the source mount can be changed directly. For instance if / is the source mount for /foo, then use mount --make-shared / to convert / into a shared mount.
要更改挂载点的传播属性，请使用 mount 命令。例如，要绑定挂载源目录 /foo ，请执行 mount --bind /foo /foo 和 mount --make-private --make-shared /foo 。这将把/foo 转换为 shared 挂载点。源挂载点的传播属性可以直接更改。例如，如果 / 是 /foo 的源挂载点，则使用 mount --make-shared / 将 / 转换为 shared 挂载。

EXAMPLES 示例

Build named image and manifest list using specified Containerfile with default farm:
使用指定的 Containerfile 构建命名图像和清单列表，使用默认农场：

$ podman farm build --local -t name -f /path/to/containerfile .

Build named image and manifest list using the specified farm:
使用指定的农场构建命名图像和清单列表：

$ podman farm build --farm myfarm -t name .

Build named image and manifest list using the specified farm, removing all images from farm nodes, after they are pushed to registry:
使用指定的 farm 构建命名的镜像和清单列表，在将它们推送到注册表后，从 farm 节点中删除所有镜像

$ podman farm build --farm myfarm --cleanup -t name .

Build named images and manifest list for specified platforms using default farm:
使用默认 farm 为指定的平台构建命名的镜像和清单列表

$ podman farm build --platforms arm64,amd64 -t name .

SEE ALSO 参见 ¶

podman(1), podman-farm(1), buildah(1), containers-certs.d(5), containers-registries.conf(5), crun(1), runc(8), useradd(8), Containerfile(5), containerignore(5)

HISTORY 历史 ¶

September 2023, Originally compiled by Urvashi Mohnani <umohnani@redhat.com>
2023 年 9 月，原始编写者为乌尔瓦希·莫纳尼 <umohnani@redhat.com>

FOOTNOTES 脚注 ¶

1: The Podman project is committed to inclusivity, a core value of open source. The master and slave mount propagation terminology used here is problematic and divisive, and needs to be changed. However, these terms are currently used within the Linux kernel and must be used as-is at this time. When the kernel maintainers rectify this usage, Podman will follow suit immediately.
1：Podman 项目致力于包容性，这是开源的核心价值观。这里使用的 master 和 slave 挂载传播术语存在问题和分歧，需要进行更改。然而，这些术语目前在 Linux 内核中使用，因此目前必须按原样使用。当内核维护者纠正这种用法时，Podman 将立即跟进。