NAME¶ 名称
podman-build - Build a container image using a Containerfile
podman-build - 使用 Containerfile 构建容器镜像
SYNOPSIS¶ 概要
podman build [options] [context]
podman 构建 [选项] [上下文]
podman image build [options] [context]
podman 镜像构建 [选项] [上下文]
DESCRIPTION¶ 描述
podman build Builds an image using instructions from one or more
Containerfiles or Dockerfiles and a specified build context directory. A
Containerfile uses the same syntax as a Dockerfile internally. For this
document, a file referred to as a Containerfile can be a file named
either ‘Containerfile’ or ‘Dockerfile’.
podman build 使用一个或多个 Containerfiles 或 Dockerfiles 中的指令以及指定的构建上下文目录构建镜像。Containerfile 在内部使用与 Dockerfile 相同的语法。在本文档中，所谓的 Containerfile 可以是一个名为 'Containerfile' 或 'Dockerfile' 的文件。
The build context directory can be specified as the http(s) URL of an archive,
git repository or Containerfile.
构建上下文目录可以指定为存档、git 仓库或 Containerfile 的 http(s) URL。
When invoked with -f and a path to a Containerfile, with no explicit CONTEXT
directory, Podman uses the Containerfile’s parent directory as its build context.
当使用 -f 和 Containerfile 路径调用时，没有明确的 CONTEXT 目录，Podman 使用 Containerfile 的父目录作为其构建上下文。
Containerfiles ending with a “.in” suffix are preprocessed via CPP(1). This
can be useful to decompose Containerfiles into several reusable parts that can
be used via CPP’s #include directive. Containerfiles ending in .in are
restricted to no comment lines unless they are CPP commands.
Note, a Containerfile.in file can still be used by other tools when manually
preprocessing them via cpp -E.
以“.in”后缀结尾的 Containerfiles 通过 CPP(1) 预处理。这对将 Containerfiles 分解为几个可重用部分并通过 CPP 的 #include 指令使用非常有用。以 .in 结尾的 Containerfiles 除非是 CPP 命令，否则不允许有注释行。请注意，Containerfile.in 文件仍然可以通过其他工具手动预处理后使用 cpp -E 。
When the URL is an archive, the contents of the URL is downloaded to a temporary
location and extracted before execution.
当 URL 是一个存档文件时，URL 的内容会被下载到临时位置并在执行之前被解压。
When the URL is a Containerfile, the Containerfile is downloaded to a temporary
location.
当 URL 是一个 Containerfile 时，Containerfile 会被下载到临时位置。
When a Git repository is set as the URL, the repository is cloned locally and
then set as the context. A URL is treated as a Git repository if it
has a git:// prefix or a .git suffix.
当将 Git 存储库设置为 URL 时，存储库会在本地克隆，然后设置为上下文。如果 URL 具有 git:// 前缀或 .git 后缀，则将其视为 Git 存储库。
NOTE: podman build uses code sourced from the Buildah project to build
container images. This Buildah code creates Buildah containers for the
RUN options in container storage. In certain situations, when the
podman build crashes or users kill the podman build process, these external
containers can be left in container storage. Use the podman ps --all --storage
command to see these containers. External containers can be removed with the
podman rm --storage command.
注意： podman build 使用从 Buildah 项目获取的代码来构建容器映像。这 Buildah 代码为 RUN 选项中的容器存储创建 Buildah 容器。在某些情况下，当 podman build 崩溃或用户终止 podman build 进程时，这些外部容器可能会留在容器存储中。使用 podman ps --all --storage 命令查看这些容器。可以使用 podman rm --storage 命令删除外部容器。
podman buildx build command is an alias of podman build. Not all buildx build features are available in Podman. The buildx build option is provided for scripting compatibility.
podman buildx build 命令是 podman build 的别名。并非所有 buildx build 功能在 Podman 中都可用。提供 buildx build 选项以实现脚本兼容性。
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 选项冲突。
--all-platforms¶ --所有平台 ¶
Instead of building for a set of platforms specified using the --platform option, inspect the build’s base images, and build for all of the platforms for which they are all available. Stages that use scratch as a starting point can not be inspected, so at least one non-scratch stage must be present for detection to work usefully.
不再构建一组使用 --platform 选项指定的平台，而是检查构建的基础镜像，并为所有可用的平台构建。使用 scratch 作为起点的阶段无法被检查，因此至少必须存在一个非 scratch 阶段，以使检测能够有效工作。
--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 格式编写图像时会被丢弃。
--arch=arch¶
Set the architecture of the image to be built, and that of the base image to be
pulled, if the build uses one, to the provided value instead of using the
architecture of the build host. Unless overridden, subsequent lookups of the
same image in the local storage matches this architecture, regardless of the
host. (Examples: arm, arm64, 386, amd64, ppc64le, s390x)
将要构建的镜像的架构和要拉取的基础镜像的架构（如果构建使用基础镜像）设置为提供的值，而不是使用构建主机的架构。除非被覆盖，否则在本地存储中对相同镜像的后续查找将匹配此架构，而不考虑主机。（示例：arm、arm64、386、amd64、ppc64le、s390x）
--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.tarContainer 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 命名空间。
--compress¶ --压缩
This option is added to be aligned with other containers CLIs.
Podman doesn’t communicate with a daemon or a remote server.
Thus, compressing the data before sending it is irrelevant to Podman. (This option is not available with the remote Podman client, including Mac and Windows (excluding WSL2) machines)
此选项已添加以与其他容器 CLI 对齐。 Podman 不与守护程序或远程服务器通信。因此，在发送数据之前对其进行压缩对于 Podman 是无关紧要的。（此选项不适用于远程 Podman 客户端，包括 Mac 和 Windows（不包括 WSL2）机器）
--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 无根系统上不支持此选项。
--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) 文件。
--cw=options¶
Produce an image suitable for use as a confidential workload running in a
trusted execution environment (TEE) using krun (i.e., crun built with the
libkrun feature enabled and invoked as krun). Instead of the conventional
contents, the root filesystem of the image will contain an encrypted disk image
and configuration information for krun.
使用 krun 生成适用于在受信任执行环境（TEE）中运行的保密工作负载的镜像（即，使用启用了 libkrun 功能并作为 krun 调用的 crun）。镜像的根文件系统将包含加密的磁盘镜像和 krun 的配置信息，而不是传统的内容。
The value for options is a comma-separated list of key=value pairs, supplying
configuration information which is needed for producing the additional data
which will be included in the container image.
options 的值是一个逗号分隔的 key=value 对列表，提供配置信息，用于生成将包含在容器镜像中的附加数据所需的信息。
Recognized keys are: 可识别的键包括：
attestation_url: The location of a key broker / attestation server.
If a value is specified, the new image’s workload ID, along with the passphrase
used to encrypt the disk image, will be registered with the server, and the
server’s location will be stored in the container image.
At run-time, krun is expected to contact the server to retrieve the passphrase
using the workload ID, which is also stored in the container image.
If no value is specified, a passphrase value must be specified.
attestation_url: 密钥经纪人/认证服务器的位置。如果指定了值，则新镜像的工作负载 ID 以及用于加密磁盘镜像的密码将在服务器上注册，并且服务器的位置将存储在容器镜像中。在运行时，krun 预计会联系服务器，使用工作负载 ID 检索密码，该 ID 也存储在容器镜像中。如果未指定值，则必须指定密码值。
cpus: The number of virtual CPUs which the image expects to be run with at
run-time. If not specified, a default value will be supplied.
cpus: 镜像在运行时期望运行的虚拟 CPU 数。如果未指定，将提供默认值。
firmware_library: The location of the libkrunfw-sev shared library. If not
specified, buildah checks for its presence in a number of hard-coded
locations.
firmware_library: libkrunfw-sev 共享库的位置。如果未指定， buildah 将在一些硬编码的位置检查其存在。
memory: The amount of memory which the image expects to be run with at
run-time, as a number of megabytes. If not specified, a default value will be
supplied.
memory: 镜像在运行时期望运行的内存量，以兆字节为单位。如果未指定，将提供默认值。
passphrase: The passphrase to use to encrypt the disk image which will be
included in the container image.
If no value is specified, but an attestation_url value is specified, a
randomly-generated passphrase will be used.
The authors recommend setting an attestation_url but not a passphrase.
密码短语：用于加密磁盘映像的密码短语，该密码短语将包含在容器映像中。如果未指定任何值，但指定了 attestation_url 值，则将使用随机生成的密码短语。作者建议设置 attestation_url，但不设置密码短语。
slop: Extra space to allocate for the disk image compared to the size of the
container image’s contents, expressed either as a percentage (..%) or a size
value (bytes, or larger units if suffixes like KB or MB are present), or a sum
of two or more such specifications. If not specified, buildah guesses that
25% more space than the contents will be enough, but this option is provided in
case its guess is wrong.
slop：为磁盘映像分配的额外空间，与容器映像内容的大小相比，可以表示为百分比（..%）或大小值（字节，或者如果存在 KB 或 MB 等后缀，则为更大单位），或两个或更多这样的规范的总和。如果未指定， buildah 猜测比内容多 25% 的空间将足够，但提供此选项以防其猜测错误。
type: The type of trusted execution environment (TEE) which the image should
be marked for use with. Accepted values are “SEV” (AMD Secure Encrypted
Virtualization - Encrypted State) and “SNP” (AMD Secure Encrypted
Virtualization - Secure Nested Paging). If not specified, defaults to “SNP”.
类型：应标记为可与之一起使用的受信任执行环境（TEE）的类型的映像。接受的值为“SEV”（AMD 安全加密虚拟化 - 加密状态）和“SNP”（AMD 安全加密虚拟化 - 安全嵌套分页）。如果未指定，默认为“SNP”。
workload_id: A workload identifier which will be recorded in the container
image, to be used at run-time for retrieving the passphrase which was used to
encrypt the disk image. If not specified, a semi-random value will be derived
from the base image’s image ID.
workload_id: 将记录在容器映像中的工作负载标识符，用于在运行时检索用于加密磁盘映像的密码。如果未指定，则将从基础映像的映像 ID 派生出一个半随机值。
This option is not supported on the remote client, including Mac and Windows
(excluding WSL2) machines.
此选项不受远程客户端支持，包括 Mac 和 Windows（不包括 WSL2）机器。
--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 强制在所有情况下进行压缩。
--disable-content-trust¶
This is a Docker-specific option to disable image verification to a container
registry and is not supported by Podman. This option is a NOOP and provided
solely for scripting compatibility.
这是一个 Docker 特定选项，用于禁用对容器注册表的镜像验证，不受 Podman 支持。此选项是一个 NOOP，并且仅用于脚本兼容性。
--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 选项。
--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-groupsis 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
--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）机器。
--logsplit=bool-value¶ --logsplit=布尔值 ¶
If --logfile and --platform are specified, the --logsplit option allows
end-users to split the log file for each platform into different files in the
following format: ${logfile}_${platform-os}_${platform-arch}.
This option is not supported on the remote client, including Mac and Windows
(excluding WSL2) machines.
如果指定了 --logfile 和 --platform ，则 --logsplit 选项允许最终用户将每个平台的日志文件拆分为以下格式的不同文件： ${logfile}_${platform-os}_${platform-arch} 。此选项不受支持在远程客户端上，包括 Mac 和 Windows（不包括 WSL2）机器。
--manifest=manifest¶ --manifest=清单 ¶
Name of the manifest list to which the image is added. Creates the manifest list if it does not exist. This option is useful for building multi architecture images.
要将图像添加到的清单列表的名称。如果清单列表不存在，则创建清单列表。此选项对于构建多架构图像非常有用。
--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 mynetto 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_optionsin 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/24to thetap0interface in the container, with gateway10.0.2.3, enable DNS forwarder reachable at10.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=string¶
Set the OS of the image to be built, and that of the base image to be pulled, if the build uses one, instead of using the current operating system of the build host. Unless overridden, subsequent lookups of the same image in the local storage matches this OS, regardless of the host.
设置要构建的映像的操作系统，以及要拉取的基础映像的操作系统（如果构建使用基础映像），而不是使用构建主机的当前操作系统。除非被覆盖，否则在本地存储中查找相同映像的后续查找将匹配此操作系统，而不考虑主机。
--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 基础镜像中设置，因此通常不需要使用此选项。
--output, -o=output-opts¶
--output, -o=输出选项 ¶
Output destination (format: type=local,dest=path)
输出目的地（格式：type=local,dest=path）
The --output (or -o) option extends the default behavior of building a container image by allowing users to export the contents of the image as files on the local filesystem, which can be useful for generating local binaries, code generation, etc. (This option is not available with the remote Podman client, including Mac and Windows (excluding WSL2) machines)
--output（或 -o）选项扩展了构建容器映像的默认行为，允许用户将映像内容导出为本地文件系统上的文件，这对于生成本地二进制文件、代码生成等非常有用。（此选项在远程 Podman 客户端中不可用，包括 Mac 和 Windows（不包括 WSL2）机器）
The value for --output is a comma-separated sequence of key=value pairs, defining the output type and options.
--output 的值是一个逗号分隔的 key=value 对序列，定义了输出类型和选项。
Supported keys are: 支持的键包括:
dest: Destination path for exported output. Valid value is absolute or relative path,
-means the standard output.
dest: 导出输出的目标路径。有效值为绝对路径或相对路径，-表示标准输出。type: Defines the type of output to be used. Valid values is documented below.
type: 定义要使用的输出类型。下面记录了有效值。
Valid type values are: 有效的类型数值为:
local: write the resulting build files to a directory on the client-side.
local: 将生成的构建文件写入客户端上的目录。tar: write the resulting files as a single tarball (.tar).
tar: 将生成的文件写入单个 tar 压缩包 (.tar)。
If no type is specified, the value defaults to local.
Alternatively, instead of a comma-separated sequence, the value of --output can be just a destination (in the dest format) (e.g. --output some-path, --output -) where --output some-path is treated as if type=local and --output - is treated as if type=tar.
如果未指定类型，则该值默认为本地。或者，--output 的值可以只是一个目标（以 dest 格式）（例如 --output some-path ， --output - ），其中 --output some-path 被视为 type=local， --output - 被视为 type=tar。
--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 命名空间的路径。
--platform=os/arch[/variant][,…]¶
Set the os/arch of the built image (and its base image, when using one)
to the provided value instead of using the current operating system and
architecture of the host (for example linux/arm). Unless overridden,
subsequent lookups of the same image in the local storage matches this
platform, regardless of the host.
将构建的镜像的操作系统/架构（以及使用基础镜像时）设置为提供的值，而不是使用主机的当前操作系统和架构（例如 linux/arm ）。除非被覆盖，否则在本地存储中查找相同镜像时，会匹配此平台，而不考虑主机。
If --platform is set, then the values of the --arch, --os, and
--variant options is overridden.
如果设置了 --platform ，则会覆盖 --arch 、 --os 和 --variant 选项的值。
The --platform option can be specified more than once, or given a
comma-separated list of values as its argument. When more than one platform is
specified, the --manifest option is used instead of the --tag
option.
选项 --platform 可以指定多次，或者将逗号分隔的值列表作为其参数。当指定多个平台时，将使用选项 --manifest 而不是选项 --tag 。
Os/arch pairs are those used by the Go Programming Language. In several cases
the arch value for a platform differs from one produced by other tools such as
the arch command. Valid OS and architecture name combinations are listed as
values for $GOOS and $GOARCH at https://golang.org/doc/install/source#environment,
and can also be found by running go tool dist list.
Os/arch 对是 Go 编程语言使用的。在几种情况下，平台的 arch 值与其他工具（如 arch 命令）生成的值不同。有效的 OS 和架构名称组合作为 $GOOS 和 $GOARCH 的值列在 https://golang.org/doc/install/source#environment，也可以通过运行 go tool dist list 找到。
While podman build is happy to use base images and build images for any
platform that exists, RUN instructions are able to succeed without
the help of emulation provided by packages like qemu-user-static.
虽然 podman build 乐于使用基础镜像和为任何现有平台构建镜像，但 RUN 指令能够在不依赖像 qemu-user-static 这样的软件包提供的仿真的情况下成功。
--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.
较新：如果注册表上的图像比本地容器存储中的图像更新，则拉取。当摘要不同时，图像被视为更新。比较时间戳容易出错。如果找到本地图像，则拉取错误会被抑制。
Pull image policy. The default is missing.
拉取图像策略。默认值为 missing。
--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 supportedno-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 冲突。
--sign-by=fingerprint¶
Sign the image using a GPG key with the specified FINGERPRINT. (This option is not available with the remote Podman client, including Mac and Windows (excluding WSL2) machines,)
使用指定的指纹的 GPG 密钥对镜像进行签名。（此选项不适用于远程 Podman 客户端，包括 Mac 和 Windows（不包括 WSL2）机器。）
--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
--stdin¶
Pass stdin into the RUN containers. Sometime commands being RUN within a Containerfile
want to request information from the user. For example apt asking for a confirmation for install.
Use --stdin to be able to interact from the terminal during the build.
将 stdin 传递到 RUN 容器中。有时在 Containerfile 中运行的命令需要从用户请求信息。例如，apt 请求确认安装。使用 --stdin 可以在构建过程中从终端进行交互。
--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 命名空间的路径。
--variant=variant¶
Set the architecture variant of the image to be built, and that of the base
image to be pulled, if the build uses one, to the provided value instead of
using the architecture variant of the build host.
设置要构建的镜像的架构变体，以及如果构建使用基础镜像，则拉取基础镜像的架构变体为提供的值，而不是使用构建主机的架构变体。
--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
Oflag is not allowed to be specified with theZorzflags. 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 an image using local Containerfiles¶
使用本地 Containerfiles 构建镜像
Build image using Containerfile with content from current directory:
使用来自当前目录内容的 Containerfile 构建镜像：
$ podman build .
Build image using specified Containerfile with content from current directory:
使用指定的 Containerfile 构建镜像，内容来自当前目录：
$ podman build -f Containerfile.simple .
Build image using Containerfile from stdin with content from current directory:
使用来自标准输入的 Containerfile 构建镜像，内容来自当前目录：
$ cat $HOME/Containerfile | podman build -f - .
Build image using multiple Containerfiles with content from current directory:
使用多个 Containerfile 构建镜像，内容来自当前目录：
$ podman build -f Containerfile.simple -f Containerfile.notsosimple .
Build image with specified Containerfile with content from $HOME directory. Note cpp is applied to Containerfile.in before processing as Containerfile:
使用指定的 Containerfile 构建镜像，内容来自 $HOME 目录。注意在处理为 Containerfile 之前，Containerfile.in 上应用了 cpp ：
$ podman build -f Containerfile.in $HOME
Build image with the specified tag with Containerfile and content from current directory:
使用指定的标签和当前目录中的 Containerfile 和内容构建镜像：
$ podman build -t imageName .
Build image ignoring registry verification for any images pulled via the Containerfile:
通过 Containerfile 拉取的任何镜像都忽略注册表验证构建镜像：
$ podman build --tls-verify=false -t imageName .
Build image with the specified logging format:
使用指定的日志格式构建镜像
$ podman build --runtime-flag log-format=json .
Build image using debug mode for logging:
使用调试模式构建镜像以进行日志记录
$ podman build --runtime-flag debug .
Build image using specified registry attributes when pulling images from the selected Containerfile:
从选定的 Containerfile 拉取镜像时使用指定的注册表属性构建镜像
$ podman build --authfile /tmp/auths/myauths.json --cert-dir $HOME/auth --tls-verify=true --creds=username:password -t imageName -f Containerfile.simple .
Build image using specified resource controls when running containers during the build:
在构建过程中运行容器时使用指定的资源控制来构建镜像
$ podman build --memory 40m --cpu-period 10000 --cpu-quota 50000 --ulimit nofile=1024:1028 -t imageName .
Build image using specified SELinux labels and cgroup config running containers during the build:
在构建过程中运行容器时使用指定的 SELinux 标签和 cgroup 配置构建镜像
$ podman build --security-opt label=level:s0:c100,c200 --cgroup-parent /path/to/cgroup/parent -t imageName .
Build image with read-only and SELinux relabeled volume mounted from the host into running containers during the build:
在构建过程中将来自主机的只读和 SELinux 重新标记的卷挂载到运行容器中构建镜像
$ podman build --volume /home/test:/myvol:ro,Z -t imageName .
Build image with overlay volume mounted from the host into running containers during the build:
使用从主机挂载到运行容器中的叠加卷构建镜像：
$ podman build -v /var/lib/yum:/var/lib/yum:O -t imageName .
Build image using layers and then removing intermediate containers even if the build fails.
使用层构建镜像，即使构建失败也会删除中间容器。
$ podman build --layers --force-rm -t imageName .
Build image ignoring cache and not removing intermediate containers even if the build succeeds:
构建镜像时忽略缓存，即使构建成功也不会删除中间容器。
$ podman build --no-cache --rm=false -t imageName .
Build image using the specified network when running containers during the build:
在构建过程中运行容器时，使用指定的网络构建镜像
$ podman build --network mynet .
Building a multi-architecture image using the --manifest option (requires emulation software)¶
使用 --manifest 选项构建多架构镜像（需要仿真软件）
Build image using the specified architectures and link to a single manifest on successful completion:
在成功完成时使用指定的架构构建镜像，并链接到单个清单
$ podman build --arch arm --manifest myimage /tmp/mysrc
$ podman build --arch amd64 --manifest myimage /tmp/mysrc
$ podman build --arch s390x --manifest myimage /tmp/mysrc
Similarly build using a single command
类似地，使用单个命令构建
$ podman build --platform linux/s390x,linux/ppc64le,linux/amd64 --manifest myimage /tmp/mysrc
Build image using multiple specified architectures and link to single manifest on successful completion:
使用多个指定的架构构建镜像，并在成功完成时链接到单个清单：
$ podman build --platform linux/arm64 --platform linux/amd64 --manifest myimage /tmp/mysrc
Building an image using a URL, Git repo, or archive¶
使用 URL、Git 存储库或存档构建镜像 ¶
The build context directory can be specified as a URL to a Containerfile, a
Git repository, or URL to an archive. If the URL is a Containerfile, it is
downloaded to a temporary location and used as the context. When a Git
repository is set as the URL, the repository is cloned locally to a temporary
location and then used as the context. Lastly, if the URL is an archive, it is
downloaded to a temporary location and extracted before being used as the
context.
构建上下文目录可以指定为 Containerfile 的 URL、Git 仓库或存档的 URL。如果 URL 是 Containerfile，则会下载到临时位置并用作上下文。当 Git 仓库设置为 URL 时，仓库会被克隆到本地临时位置，然后用作上下文。最后，如果 URL 是存档，则会下载到临时位置并在用作上下文之前进行提取。
Building an image using a URL to a Containerfile¶
使用 URL 构建镜像到 Containerfile
Build image from Containerfile downloaded into temporary location used as the build context:
从下载到临时位置的 Containerfile 构建镜像作为构建上下文：
$ podman build https://10.10.10.1/podman/Containerfile
Building an image using a Git repository¶
使用 Git 存储库构建镜像 ¶
Podman clones the specified GitHub repository to a temporary location and
use it as the context. The Containerfile at the root of the repository is used
and it only works if the GitHub repository is a dedicated repository.
Podman 克隆指定的 GitHub 存储库到临时位置，并将其用作上下文。存储库根目录中的 Containerfile 被使用，仅在 GitHub 存储库是专用存储库时才有效。
Build image from specified git repository downloaded into temporary location used as the build context:
从指定的 git 存储库构建镜像，下载到临时位置并用作构建上下文：
$ podman build -t hello https://github.com/containers/PodmanHello.git
$ podman run hello
Note: GitHub does not support using git:// for performing clone operation due to recent changes in their security guidance (https://github.blog/2021-09-01-improving-git-protocol-security-github/). Use an https:// URL if the source repository is hosted on GitHub.
注意：由于最近对其安全指南进行了更改，GitHub 不支持使用 git:// 执行 clone 操作。如果源存储库托管在 GitHub 上，请使用 https:// URL。
Building an image using a URL to an archive¶
使用 URL 构建镜像到存档文件
Podman fetches the archive file, decompress it, and use its contents as the
build context. The Containerfile at the root of the archive and the rest of the
archive are used as the context of the build. Passing the
-f PATH/Containerfile option as well tells the system to look for that file
inside the contents of the archive.
Podman 获取存档文件，解压缩并使用其内容作为构建上下文。存档根目录下的 Containerfile 和存档的其余部分被用作构建的上下文。同时传递 -f PATH/Containerfile 选项告诉系统在存档内容中查找该文件。
$ podman build -f dev/Containerfile https://10.10.10.1/podman/context.tar.gz
Note: supported compression formats are ‘xz’, ‘bzip2’, ‘gzip’ and ‘identity’
(no compression).
注意：支持的压缩格式包括 'xz'、'bzip2'、'gzip' 和 'identity'（无压缩）。
Files¶ 文件
.containerignore/.dockerignore¶
.containerignore/.dockerignore
If the file .containerignore or .dockerignore exists in the context directory,
podman build reads its contents. Use the --ignorefile option to override the
.containerignore path location.
Podman uses the content to exclude files and directories from the context
directory, when executing COPY and ADD directives in the
Containerfile/Dockerfile
如果上下文目录中存在 .containerignore 或 .dockerignore 文件，则 podman build 会读取其内容。使用 --ignorefile 选项来覆盖 .containerignore 路径位置。Podman 使用这些内容来在执行 Containerfile/Dockerfile 中的 COPY 和 ADD 指令时排除上下文目录中的文件和目录。
The .containerignore and .dockerignore files use the same syntax; if both
are in the context directory, podman build only uses .containerignore.
.containerignore 和 .dockerignore 文件使用相同的语法；如果两者都在上下文目录中，则 podman build 仅使用 .containerignore。
Users can specify a series of Unix shell globs in a .containerignore file to
identify files/directories to exclude.
用户可以在 .containerignore 文件中指定一系列 Unix shell 通配符，以识别要排除的文件/目录。
Podman supports a special wildcard string ** which matches any number of
directories (including zero). For example, **/*.go excludes all files that
end with .go that are found in all directories.
Podman 支持一个特殊的通配符字符串 ** ，它匹配任意数量的目录（包括零个）。例如，**/*.go 排除了所有以.go 结尾的文件，这些文件位于所有目录中。
Example .containerignore file:
示例 .containerignore 文件:
# exclude this content for image
*/*.c
**/output*
src
*/*.c
Excludes files and directories whose names ends with .c in any top level
subdirectory. For example, the source file include/rootless.c.
*/*.c 排除了任何顶层子目录中以 .c 结尾的文件和目录。例如，源文件包括/rootless.c。
**/output*
Excludes files and directories starting with output from any directory.
**/output* 从任何目录中排除以 output 开头的文件和目录。
src
Excludes files named src and the directory src as well as any content in it.
src 排除名为 src 的文件和目录 src 以及其中的任何内容。
Lines starting with ! (exclamation mark) can be used to make exceptions to
exclusions. The following is an example .containerignore file that uses this
mechanism:
以 !（感叹号）开头的行可用于对排除项进行例外处理。以下是一个使用此机制的示例 .containerignore 文件：
*.doc
!Help.doc
Exclude all doc files except Help.doc from the image.
从镜像中排除除 Help.doc 之外的所有文档文件。
This functionality is compatible with the handling of .containerignore files
described here:
此功能与此处描述的 .containerignore 文件的处理兼容：
https://github.com/containers/common/blob/main/docs/containerignore.5.md
registries.conf (/etc/containers/registries.conf)
registries.conf is the configuration file which specifies which container
registries is consulted when completing image names which do not include
a registry or domain portion.
registries.conf 是配置文件，指定在完成不包括注册表或域部分的图像名称时要查询哪些容器注册表。
Troubleshooting¶ 故障排除
lastlog sparse file¶ lastlog 稀疏文件
Using a useradd command within a Containerfile with a large UID/GID creates
a large sparse file /var/log/lastlog. This can cause the
build to hang forever. Go language does not support sparse files correctly,
which can lead to some huge files being created in the container image.
在 Containerfile 中使用 useradd 命令并设置一个大的 UID/GID 会创建一个大的稀疏文件 /var/log/lastlog 。这可能导致构建永远挂起。Go 语言不正确支持稀疏文件，这可能导致在容器镜像中创建一些巨大的文件。
When using the useradd command within the build script, pass the
--no-log-init or -l option to the useradd command. This option tells
useradd to stop creating the lastlog file.
在构建脚本中使用 useradd 命令时，向 useradd 命令传递 --no-log-init or -l 选项。此选项告诉 useradd 停止创建 lastlog 文件。
SEE ALSO¶ 参见 ¶
podman(1), buildah(1), containers-certs.d(5), containers-registries.conf(5), crun(1), runc(8), useradd(8), podman-ps(1), podman-rm(1), Containerfile(5), containerignore(5)
HISTORY¶ 历史 ¶
Aug 2020, Additional options and .containerignore added by Dan Walsh <dwalsh@redhat.com>
2020 年 8 月，由丹·沃尔什添加了额外选项和 .containerignore <dwalsh@redhat.com>
May 2018, Minor revisions added by Joe Doss <joe@solidadmin.com>
2018 年 5 月，由乔·多斯进行了轻微修订 <joe@solidadmin.com>
December 2017, Originally compiled by Tom Sweeney <tsweeney@redhat.com>
2017 年 12 月，最初由 Tom Sweeney 编写 <tsweeney@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 将立即跟进。