名称

podman-farm-build - 在农场节点上构建镜像，然后将其捆绑成一个清单列表

简介

podman farm build [options] [context]

描述

podman farm build 在农场的所有节点上构建一个镜像，并将其捆绑成一个清单列表。它使用给定的 Containerfile 在农场节点上执行 podman build 命令。一旦镜像在所有农场节点上构建完成，这些镜像将被推送到通过 --tag 标志指定的注册表。一旦所有镜像都被推送，将本地创建一个清单列表，并将其也推送到注册表。

清单列表将包含农场中每种原生架构类型的一个镜像。

此命令的主要功能是创建多架构构建，这比使用 podman build --arch --platform 通过仿真进行构建要快。

如果未指定农场，构建将被发送到 podman system connection 已知的所有节点。

注意：由于构建的镜像直接推送到注册表，用户必须使用 --tag 选项以 registry/repository/imageName[:tag]` 的格式传入完整的镜像名称。

选项

--add-host=hostname[;hostname[;…]]:ip

向容器的 /etc/hosts 文件中添加一个自定义的主机到 IP 的映射。

该选项接受一个或多个以分号分隔的主机名，这些主机名将映射到单个 IPv4 或 IPv6 地址，以冒号分隔。它还可以用于覆盖 Podman 默认添加到 /etc/hosts 的主机名 IP 地址（另请参阅 --name 和 --hostname 选项）。此选项可以多次指定，以向 /etc/hosts 添加额外的映射。它与 --no-hosts 选项冲突，并与 containers.conf 中的 no_hosts=true 冲突。

除了 IP 地址，还可以指定特殊标志 host-gateway。它解析为容器可以用来连接到主机的 IP 地址。选择的 IP 地址取决于您的网络设置，因此 Podman 无法保证自动确定 host-gateway 地址，这会导致 Podman 失败并显示错误消息。您可以使用 containers.conf 中的 host_containers_internal_ip 选项覆盖此 IP 地址。

Podman 还使用 host-gateway 地址自动将 host.containers.internal 和 host.docker.internal 主机名添加到 /etc/hosts。您可以通过提供 --no-hosts 选项或在 containers.conf 中设置 host_containers_internal_ip=”none” 来阻止此操作。如果未手动配置 host-gateway 地址，并且 Podman 无法自动确定 IP 地址，Podman 将静默跳过将这些内部主机名添加到 /etc/hosts。如果 Podman 在使用 podman machine 运行的虚拟机中（包括 Mac 和 Windows 主机），除非手动配置了 IP 地址，否则 Podman 将静默跳过将内部主机名添加到 /etc/hosts；内部主机名将由 gvproxy DNS 解析器解析。

Podman 默认将使用主机的 /etc/hosts 文件作为基础，即该文件中存在的任何主机名也将存在于容器的 /etc/hosts 文件中。可以使用 containers.conf 中的 base_hosts_file 配置来配置不同的基础文件。

--annotation=annotation=value

向镜像元数据中添加一个镜像注解（例如 annotation=value）。可以多次使用。

注意：此信息在 Docker 镜像格式中不存在，因此在以 Docker 格式写入镜像时会被丢弃。

--authfile=path

认证文件的路径。在 Linux 上默认为 ${XDG_RUNTIME_DIR}/containers/auth.json，在 Windows/macOS 上默认为 $HOME/.config/containers/auth.json。该文件由 podman login 创建。如果在此处找不到授权状态，将检查 $HOME/.docker/config.json，该文件是使用 docker login 设置的。

注意：还可以通过设置 REGISTRY_AUTH_FILE 环境变量来覆盖认证文件的默认路径。这可以通过 export REGISTRY_AUTH_FILE=path 来完成。

--build-arg=arg=value

指定一个构建参数及其值，其插值方式与 Containerfiles 中读取的指令中的环境变量相同，但不会添加到生成的镜像配置中的环境变量列表中。

--build-arg-file=path

指定一个文件，其中包含形式为 arg=value 的构建参数行。建议的文件名为 argfile.conf。

以 # 开头的注释行以及空行将被忽略。所有其他行必须是传递给 --build-arg 的 arg=value 格式。

如果通过 --build-arg-file 和 --build-arg 选项提供了多个参数，则构建参数将在所有提供的文件和命令行参数之间合并。

在读取通过 --build-arg 选项提供的参数之前，会读取 --build-arg-file 选项中提供的任何文件。

当给定参数名称多次指定时，最后一个实例是传递给最终构建的实例。这意味着 --build-arg 的值总是覆盖 --build-arg-file 中的值。

--build-context=name=value

使用其简称及其位置指定一个额外的构建上下文。额外的构建上下文可以像我们在 COPY 指令中访问不同阶段一样引用。

有效值为：

  • 本地目录——例如 --build-context project2=../path/to/project2/src（此选项不适用于远程 Podman 客户端。在 Podman 机器设置（即 macOS 和 Windows）上，路径必须存在于机器虚拟机上）

  • tarball 的 HTTP URL——例如 --build-context src=https://example.org/releases/src.tar

  • 容器镜像——以 container-image:// 前缀指定，例如 --build-context alpine=container-image://alpine:3.15,（也接受 docker://, docker-image://）

在 Containerfile 方面，在所有接受“from”参数的命令上引用构建上下文。这可能看起来像

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

[name] 的值与以下优先级顺序匹配

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

  • 在 Containerfile 中使用 AS [name] 定义的阶段

  • 镜像 [name]，无论是本地的还是远程注册表中的

--cache-from=image

用作潜在缓存源的仓库。当指定时，Buildah 会尝试在指定的仓库中查找缓存镜像，并尝试拉取缓存镜像，而不是实际在本地执行构建步骤。Buildah 仅在它们被认为是有效缓存命中时才尝试拉取先前缓存的镜像。

使用 --cache-to 选项使用缓存内容填充远程仓库。

示例

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

注意：除非指定了 --layers，否则 --cache-from 选项将被忽略。

--cache-to=image

设置此标志以指定用于存储缓存镜像的远程仓库。Buildah 尝试将新构建的缓存镜像推送到远程仓库。

注意：使用 --cache-from 选项以使用远程仓库中的缓存内容。

示例

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

注意：除非指定了 --layers，否则 --cache-to 选项将被忽略。

--cache-ttl

限制缓存镜像的使用，仅考虑创建时间戳在 duration 之前的镜像。例如，如果指定 --cache-ttl=1h，Buildah 会考虑在一小时内创建的中间缓存镜像，并忽略超出此持续时间的中间缓存镜像。

注意：手动设置 --cache-ttl=0 在实现上等同于使用 --no-cache，因为这意味着用户根本不想使用缓存。

--cap-add=CAP_xxx

执行 RUN 指令时，运行指令中指定的命令，并将其功能集中添加指定的功能。某些功能默认授予；此选项可用于添加更多功能。

--cap-drop=CAP_xxx

执行 RUN 指令时，运行指令中指定的命令，并将其功能集中删除指定的功能。默认授予 CAP_CHOWN、CAP_DAC_OVERRIDE、CAP_FOWNER、CAP_FSETID、CAP_KILL、CAP_NET_BIND_SERVICE、CAP_SETFCAP、CAP_SETGID、CAP_SETPCAP 和 CAP_SETUID 功能；此选项可用于删除它们。

如果一个功能同时指定给 --cap-add 和 --cap-drop 选项，则无论选项的给定顺序如何，它都将被删除。

--cert-dir=path

使用 path 中的证书（*.crt、*.cert、*.key）连接到注册表。（默认值：/etc/containers/certs.d）有关详细信息，请参阅 containers-certs.d(5)。（此选项不适用于远程 Podman 客户端，包括 Mac 和 Windows（不包括 WSL2）机器）

--cgroup-parent=path

创建 cgroup 的 cgroup 路径。如果路径不是绝对路径，则该路径被视为相对于 init 进程的 cgroup 路径。如果 cgroup 不存在，则会创建它们。

--cgroupns=how

设置处理 RUN 指令时 cgroup 命名空间的配置。配置值可以是“” (空字符串) 或 “private” 以指示创建新的 cgroup 命名空间，也可以是 “host” 以指示重用 buildah 本身正在运行的 cgroup 命名空间。

--cleanup

成功时从农场节点删除构建的镜像（默认值：false）。

--compat-volumes

处理使用 VOLUME 指令（在此构建中以及从基础镜像继承的指令）标记的目录，使其内容只能由 ADD 和 COPY 指令修改。RUN 指令在这些位置所做的任何更改都将被恢复。在此选项引入之前，此行为是默认行为，但现在默认禁用。

--cpp-flag=flags

设置要传递给 C 预处理器 cpp(1) 的附加标志。以“.in”后缀结尾的 Containerfiles 将通过 cpp(1) 进行预处理。此选项可用于将附加标志传递给 cpp。注意：您还可以通过设置 BUILDAH_CPPFLAGS 环境变量来设置默认的 CPPFLAGS（例如，export BUILDAH_CPPFLAGS=”-DDEBUG”）。

--cpu-period=limit

为完全公平调度器（CFS）设置 CPU 周期，这是一个以微秒为单位的时长。一旦容器的 CPU 配额用尽，它将不会被调度运行，直到当前周期结束。默认为 100000 微秒。

在某些系统上，非 root 用户可能不允许更改资源限制。更多详情，请参阅 https://github.com/containers/podman/blob/main/troubleshooting.md#26-running-containers-with-resource-limits-fails-with-a-permissions-error

在 cgroups V1 的无根（rootless）系统上不支持此选项。

--cpu-quota=limit

限制 CPU 完全公平调度器（CFS）的配额。

限制容器的 CPU 使用率。默认情况下，容器以全部 CPU 资源运行。限制以微秒为单位。如果提供了数字，则容器被允许使用那么多 CPU 时间，直到 CPU 周期结束（可通过 --cpu-period 控制）。

在某些系统上，非 root 用户可能不允许更改资源限制。更多详情，请参阅 https://github.com/containers/podman/blob/main/troubleshooting.md#26-running-containers-with-resource-limits-fails-with-a-permissions-error

在 cgroups V1 的无根（rootless）系统上不支持此选项。

--cpu-shares, -c=shares

CPU 份额（相对权重）。

默认情况下，所有容器获得相同比例的 CPU 周期。可以通过更改容器的 CPU 份额权重相对于所有运行中容器的总权重来修改此比例。默认权重为 1024。

该比例仅在 CPU 密集型进程运行时适用。当一个容器中的任务处于空闲状态时，其他容器可以使用剩余的 CPU 时间。实际的 CPU 时间量取决于系统上运行的容器数量。

例如，考虑三个容器，一个的 cpu-share 为 1024，另外两个的 cpu-share 设置为 512。当所有三个容器中的进程都尝试使用 100% 的 CPU 时，第一个容器获得总 CPU 时间的 50%。如果添加第四个 cpu-share 为 1024 的容器，则第一个容器只获得 33% 的 CPU。其余容器分别获得 16.5%、16.5% 和 33% 的 CPU。

在多核系统上，CPU 时间的份额分布在所有 CPU 内核上。即使一个容器被限制使用少于 100% 的 CPU 时间，它也可以使用每个独立 CPU 内核的 100%。

例如，考虑一个具有三个以上核心的系统。如果容器 C0 以 --cpu-shares=512 启动并运行一个进程，而另一个容器 C1 以 --cpu-shares=1024 启动并运行两个进程，这可能导致 CPU 份额的以下划分

PID

容器

CPU

CPU 份额

100

C0

0

CPU0 的 100%

101

C1

1

CPU1 的 100%

102

C1

2

CPU2 的 100%

在某些系统上，非 root 用户可能不允许更改资源限制。更多详情，请参阅 https://github.com/containers/podman/blob/main/troubleshooting.md#26-running-containers-with-resource-limits-fails-with-a-permissions-error

在 cgroups V1 的无根（rootless）系统上不支持此选项。

--cpuset-cpus=number

允许执行的 CPU。可以指定为逗号分隔的列表（例如 0,1），范围（例如 0-3），或两者的任意组合（例如 0-3,7,11-15）。

在某些系统上，非 root 用户可能不允许更改资源限制。更多详情，请参阅 https://github.com/containers/podman/blob/main/troubleshooting.md#26-running-containers-with-resource-limits-fails-with-a-permissions-error

在 cgroups V1 的无根（rootless）系统上不支持此选项。

--cpuset-mems=nodes

允许执行的内存节点（MEMs）（0-3, 0,1）。仅在 NUMA 系统上有效。

如果系统上有四个内存节点（0-3），使用 --cpuset-mems=0,1，则容器中的进程将只使用前两个内存节点的内存。

在某些系统上，非 root 用户可能不允许更改资源限制。更多详情，请参阅 https://github.com/containers/podman/blob/main/troubleshooting.md#26-running-containers-with-resource-limits-fails-with-a-permissions-error

在 cgroups V1 的无根（rootless）系统上不支持此选项。

--created-annotation

向镜像元数据添加一个镜像 annotation（另请参阅 --annotation），将“org.opencontainers.image.created”设置为当前时间，如果使用了 --source-date-epoch 或 --timestamp 标志，则设置为指定的时间戳。如果为 false，则生成的镜像中不会存在此类 annotation。

注意：此信息在 Docker 镜像格式中不存在，因此在以 Docker 格式写入镜像时会被丢弃。

--creds=[username[:password]]

用于向镜像仓库进行身份验证的 [username[:password]]（如果需要）。如果未提供一个或两个值，则会出现命令行提示，可以输入该值。密码输入时无回显。

请注意，指定的凭据仅用于针对目标注册表进行身份验证。它们不用于镜像或注册表被重写时（请参阅 containers-registries.conf(5)）；要针对这些进行身份验证，请考虑使用 containers-auth.json(5) 文件。

--decryption-key=key[:passphrase]

用于解密镜像的 [key[:passphrase]]。Key 可以指向密钥和/或证书。会尝试使用所有密钥进行解密。如果密钥受密码短语保护，则必须在参数中传递它，否则省略。

--device=host-device[:container-device][:permissions]

向容器添加一个主机设备。其格式为 HOST-DEVICE[:CONTAINER-DEVICE][:PERMISSIONS]，其中 HOST-DEVICE 是主机上设备节点的路径，CONTAINER-DEVICE 是容器中设备节点的路径，PERMISSIONS 是一个权限列表，由 'r' (读取)、'w' (写入) 和 'm' (mknod(2)) 组合而成。

示例：--device=/dev/sdc:/dev/xvdc:rwm。

注意：如果 host-device 是一个符号链接，则会首先解析它。容器只存储主机设备的主设备号和次设备号。

Podman 可能会加载使用指定设备所需的内核模块。Podman 在必要时加载模块的设备是：/dev/fuse。

在无根模式下，新设备从主机绑定挂载到容器中，而不是 Podman 在容器空间内创建它。由于绑定挂载在 SELinux 系统上保留其 SELinux 标签，因此容器在访问挂载设备时可能会遇到权限被拒绝的情况。修改 SELinux 设置以允许容器通过以下命令使用所有设备标签

$ sudo setsebool -P container_use_devices=true

注意：如果用户仅通过组具有访问权限，则从无根容器内部访问设备将失败。crun(1) 运行时通过添加选项 --annotation run.oci.keep_original_groups=1 来提供一个解决方法。

--disable-compression, -D

在构建镜像时不压缩文件系统层，除非目标写入位置要求压缩。这是默认设置，因为镜像层在推送到注册表时会自动压缩，而写入本地存储的镜像只需再次解压缩即可存储。在所有情况下，都可以通过指定 --disable-compression=false 来强制压缩。

--dns=ipaddr

设置自定义 DNS 服务器。

此选项可用于覆盖传递给容器的 DNS 配置。通常，当主机 DNS 配置对容器无效时（例如，127.0.0.1），这是必需的。在这种情况下，每次运行都需要 --dns 标志。

可以指定特殊值 none 来禁止 Podman 在容器中创建 /etc/resolv.conf。然后，镜像中的 /etc/resolv.conf 文件将不加修改地使用。

请注意，**ipaddr** 可以直接添加到容器的 /etc/resolv.conf 中。但这并不能保证。例如，将 dns_enabled 设置为 true 的自定义网络传递给 --network 将导致 /etc/resolv.conf 仅引用 aardvark-dns 服务器。然后 aardvark-dns 将所有非容器名称查询转发到提供的 ipaddr。

此选项不能与设置为 none 的 --network 结合使用。

注意：此选项仅在构建过程中的 RUN 指令期间生效。它不会影响最终镜像中的 /etc/resolv.conf。

--dns-option=option

设置在构建期间使用的自定义 DNS 选项。

--dns-search=domain

设置在构建期间使用的自定义 DNS 搜索域。

--env=env[=value]

向构建的镜像添加一个值（例如 env=value）。可以多次使用。如果既未指定 = 也未指定 value，但 env 在当前环境中已设置，则将当前环境中的值添加到镜像中。

要从构建的镜像中删除环境变量，请使用 --unsetenv 选项。

--farm

此选项指定构建过程中要使用的农场名称。

此选项指定构建过程中要使用的农场名称。

--file, -f=Containerfile

指定一个包含构建镜像指令的 Containerfile，可以是本地文件或 http 或 https URL。如果指定了多个 Containerfile，则只接受最后一个指定文件中的 FROM 指令。

如果未指定构建上下文，并且至少有一个 Containerfile 是本地文件，则其所在的目录将用作构建上下文。

指定选项 -f - 会导致从标准输入读取 Containerfile 内容。

--force-rm

总是在构建后移除中间容器，即使构建失败也是如此（默认为 true）。

--format

控制构建的镜像的清单和配置数据的格式。可识别的格式包括 oci（OCI 镜像规范 v1.0，默认）和 docker（版本 2，使用模式格式 2 作为清单）。

注意：您还可以通过设置 BUILDAH_FORMAT 环境变量来覆盖默认格式。 export BUILDAH_FORMAT=docker

--from

覆盖 Containerfile 中的第一个 FROM 指令。如果 Containerfile 中有多个 FROM 指令，则只更改第一个。

对于远程 podman 客户端，并非所有容器传输都能按预期工作。例如，oci-archive:/x.tar 引用的是远程机器上的 /x.tar，而不是客户端上的。使用 podman 远程客户端时，最好将使用限制为 containers-storage 和 docker:// transports。

--group-add=group | keep-groups

为在容器进程内运行的主用户分配额外的组。

  • keep-groups 是一个特殊标志，告诉 Podman 保留补充组访问权限。

允许容器使用用户的补充组访问。如果文件系统或设备只能由无根用户的组访问，此标志会告诉 OCI 运行时将组访问权限传递到容器中。目前仅适用于 crun OCI 运行时。注意：keep-groups 是排他性的，不能使用此标志指定其他组。（不适用于远程命令，包括 Mac 和 Windows（不包括 WSL2）机器）

--help, -h

打印用法说明

--hooks-dir=path

路径中的每个 *.json 文件都配置了一个 buildah 构建容器的钩子。有关 JSON 文件的语法和钩子注入语义的更多详细信息。Buildah 目前支持 1.0.0 和 0.1.0 两种钩子模式，尽管 0.1.0 模式已弃用。

此选项可以多次设置；后来的选项的路径具有更高的优先级。

对于注释条件，buildah 使用生成的 OCI 配置中设置的任何注释。

对于绑定挂载条件，只考虑调用者通过 --volume 明确请求的挂载。buildah 默认插入的绑定挂载（例如 /dev/shm）不予考虑。

如果根调用者的 --hooks-dir 未设置，Buildah 目前默认为 /usr/share/containers/oci/hooks.d 和 /etc/containers/oci/hooks.d，按优先级递增的顺序。使用这些默认值已弃用。请迁移到明确设置 --hooks-dir。

--http-proxy

默认情况下，如果 Podman 进程设置了代理环境变量，则会将它们传递到容器中。可以通过将值设置为 false 来禁用此功能。传递的环境变量包括 http_proxy、https_proxy、ftp_proxy、no_proxy，以及这些变量的大写版本。此选项仅在主机系统必须使用代理但容器不使用任何代理时才需要。以任何其他方式为容器指定的代理环境变量将覆盖从主机传递的值。（为容器指定代理的其他方式包括使用 --env 标志传递值，或在容器构建时硬编码代理环境。）与远程客户端一起使用时，它使用服务器进程上设置的代理环境变量。

默认为 true。

--identity-label

如果设置，添加默认身份标签 io.buildah.version。（默认值为 true）。

--ignorefile

备用 .containerignore 文件的路径。

--iidfile=ImageIDfile

将构建的镜像 ID 写入文件。当多次指定 --platform 时，尝试使用此选项会触发错误。

--inherit-annotations=bool-value

从基础镜像或基础阶段继承注释。（默认值为 true）。将此标志设置为 false 的用例可能还需要对 --created-annotation 标志执行相同的操作。

--inherit-labels

从基础镜像或基础阶段继承标签。（默认值为 true）。

--ipc=how

设置处理 RUN 指令时 IPC 命名空间的配置。配置值可以是“” (空字符串) 或 “container” 以指示创建新的 IPC 命名空间，也可以是 “host” 以指示重用 podman 本身正在运行的 IPC 命名空间，或者它可以是已由另一个进程使用的 IPC 命名空间的路径。

--isolation=type

控制在运行 RUN 指令时用于运行进程的隔离类型。识别的类型包括 oci (OCI 兼容运行时，默认)、rootless (使用修改后的配置和启用其 --rootless 选项调用的 OCI 兼容运行时，并在其 create 调用中添加 --no-new-keyring --no-pivot，禁用网络和 UTS 命名空间，启用 IPC、PID 和用户命名空间；非特权用户的默认设置) 和 chroot (一个内部包装器，更倾向于 chroot(1) 而非容器技术)。

注意：您还可以通过设置 BUILDAH_ISOLATION 环境变量来覆盖默认隔离类型。 export BUILDAH_ISOLATION=oci

--jobs=number

并行运行多达 N 个并发阶段。如果作业数大于 1，则从 /dev/null 读取标准输入。如果指定为 0，则并行运行的作业数没有限制。

--label=label

向镜像元数据添加一个镜像标签（例如 label=value）。可以多次使用。

用户可以在 Containerfile 中设置一个特殊的 LABEL io.containers.capabilities=CAP1,CAP2,CAP3，指定容器正常运行所需的 Linux 功能列表。容器镜像中指定的此标签告诉 Podman 仅使用这些功能运行容器。Podman 仅使用指定的功能启动容器，前提是此功能列表是默认列表的子集。

如果指定的权能不在默认集合中，Podman 会打印一条错误消息，并使用默认的权能运行容器。

--layer-label=label[=value]

向中间镜像元数据添加一个中间镜像 label（例如 label=value）。它可以多次使用。

如果 label 已命名，但既未提供 = 也未提供 value，则将 label 设置为空值。

--layers

在构建过程中缓存中间镜像（默认值为 true）。

注意：您还可以通过设置 BUILDAH_LAYERS 环境变量来覆盖层的默认值。 export BUILDAH_LAYERS=true

--local, -l

在本地机器和农场节点上构建镜像。

--logfile=filename

将发送到标准输出和标准错误的日志输出写入指定文件，而不是标准输出和标准错误。此选项在远程客户端上不受支持，包括 Mac 和 Windows（不包括 WSL2）机器。

--memory, -m=number[unit]

内存限制。unit 可以是 b (字节)，k (千字节)，m (兆字节)，或 g (吉字节)。

允许限制容器可用的内存。如果主机支持交换内存，则 --m 内存设置可以大于物理 RAM。如果指定限制为 0（不使用 --m），则容器的内存不受限制。实际限制可能会向上取整到操作系统页面大小的倍数（该值非常大，即数万亿）。

在 cgroups V1 的无根（rootless）系统上不支持此选项。

--memory-swap=number[unit]

一个等于内存加交换空间的限制值。unit 可以是 b (字节)，k (千字节)，m (兆字节)，或 g (吉字节)。

必须与 -m (--memory) 标志一起使用。参数值必须大于 -m (--memory) 的值。默认情况下，它被设置为 --memory 值的两倍。

将 number 设置为 -1 以启用无限制的交换空间。

在 cgroups V1 的无根（rootless）系统上不支持此选项。

--network=mode, --net

设置处理 RUN 指令时网络命名空间的配置。

有效的 mode 值为：

  • none：无网络。

  • host：使用 Podman 主机网络栈。注意：host 模式赋予容器对本地系统服务（如 D-bus）的完全访问权限，因此被认为是不安全的。

  • ns:path：要加入的网络命名空间的路径。

  • private：为容器创建一个新的命名空间（默认）

  • <network name|ID>: 加入给定名称或 ID 的网络，例如使用 --network mynet 加入名为 mynet 的网络。仅支持有根用户。

  • slirp4netns[:OPTIONS,...]: 使用 slirp4netns(1) 创建用户网络栈。可以指定这些附加选项，也可以在 containers.conf 中使用 network_cmd_options 设置

    • allow_host_loopback=true|false：允许 slirp4netns 访问主机回环 IP（默认为 10.0.2.2 或当更改 slirp4netns cidr 子网时的第二个 IP，见下面的 cidr 选项）。默认为 false。

    • mtu=MTU：指定此网络使用的 MTU。（默认为 65520）。

    • cidr=CIDR：指定此网络使用的 IP 范围。（默认为 10.0.2.0/24）。

    • enable_ipv6=true|false：启用 IPv6。默认为 true。（outbound_addr6 需要）。

    • outbound_addr=INTERFACE：指定 slirp 绑定的出站接口（仅限 ipv4 流量）。

    • outbound_addr=IPv4：指定 slirp 绑定的出站 ipv4 地址。

    • outbound_addr6=INTERFACE：指定 slirp 绑定的出站接口（仅限 ipv6 流量）。

    • outbound_addr6=IPv6：指定 slirp 绑定的出站 ipv6 地址。

  • pasta[:OPTIONS,…]：使用 pasta(1) 创建一个用户模式的网络栈。
    这是无根容器的默认设置，并且仅在无根模式下受支持。
    默认情况下，IPv4 和 IPv6 地址和路由，以及 pod 接口名称，都从主机复制。如果未配置端口转发，则当任一侧（init 命名空间或容器命名空间）绑定服务时，端口会动态转发。端口转发保留原始源 IP 地址。pasta(1) 中描述的选项可以作为逗号分隔的参数指定。
    在 pasta(1) 选项方面，默认情况下给出 --config-net，以便在容器启动时配置网络，并且默认情况下也假定 --no-map-gw，以避免容器直接使用网关地址访问主机。后者可以通过在 pasta 特定选项中传递 --map-gw 来覆盖（尽管它不是实际的 pasta(1) 选项）。
    此外，还传递 -t none 和 -u none 以禁用基于绑定端口的自动端口转发。类似地，传递 -T none 和 -U none 以禁用从容器到主机的相同功能。
    一些示例：

    • pasta:--map-gw：允许容器使用网关地址直接访问主机。

    • 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，等同于默认的 slirp4netns(1) 选项：禁用 IPv6，将 10.0.2.0/24 分配给容器中的 tap0 接口，网关为 10.0.2.3，启用 DNS 转发器，可在 10.0.2.3 访问，设置 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，等同于带有 Podman 覆盖的默认 slirp4netns(1) 选项：与上面相同，但将 MTU 保留为 65520 字节

    • pasta:-t,auto,-u,auto,-T,auto,-U,auto：启用基于从主机和容器两侧观察到的绑定端口的自动端口转发

    • pasta:-T,5201：启用从容器到主机的 TCP 端口 5201 的转发，使用回环接口而不是 tap 接口以提高性能

--no-cache

不要使用现有缓存镜像进行容器构建。从头开始使用一组新的缓存层进行构建。

--no-hostname

不在容器中创建 /etc/hostname 文件。

默认情况下，Podman 管理 /etc/hostname 文件，添加容器自己的主机名。当设置 --no-hostname 选项时，如果镜像的 /etc/hostname 文件存在，它将保持不变。

--no-hosts

不修改容器中的 /etc/hosts 文件。

Podman 默认控制容器的 /etc/hosts 文件，并为容器的名称（请参阅 --name 选项）和主机名（请参阅 --hostname 选项）、内部 host.containers.internal 和 host.docker.internal 主机，以及使用 --add-host 选项添加的任何主机名添加条目。有关详细信息，请参阅 --add-host 选项。传递 --no-hosts 将禁用此功能，从而保持镜像的 /etc/hosts 文件未修改。通过在 containers.conf 中设置 no_hosts=true 也可以全局实现相同的效果。

此选项与 --add-host 冲突。

--omit-history

省略构建的镜像中的构建历史信息。（默认值为 false）。

此选项适用于最终用户明确希望设置 --omit-history 以省略构建镜像中可选 History 的情况，或在处理使用不包含 History 信息的构建工具构建的镜像时。

--os-feature=feature

设置所构建镜像所需操作系统 feature 的名称。默认情况下，如果镜像不是基于 scratch，则保留基础镜像所需的 OS 功能列表（如果基础镜像指定了任何功能）。此选项通常仅在镜像的操作系统是 Windows 时才有意义。

如果 feature 带有尾随的 -，则从镜像中列出的所需功能集中删除该 feature。

--os-version=version

设置所构建镜像的精确所需操作系统 version。默认情况下，如果镜像不是基于 scratch，则保留基础镜像所需的 OS 版本（如果基础镜像指定了版本）。此选项通常仅在镜像的操作系统是 Windows 时才有意义，并且通常在 Windows 基础镜像中设置，因此使用此选项通常是不必要的。

--pid=pid

设置处理 RUN 指令时 PID 命名空间的配置。配置值可以是“” (空字符串) 或 “container” 以指示创建新的 PID 命名空间，也可以是 “host” 以指示重用 podman 本身正在运行的 PID 命名空间，或者它可以是已由另一个进程使用的 PID 命名空间的路径。

--platforms=p1,p2,p3...

仅在与给定平台匹配的农场节点上构建。

--pull=policy

拉取镜像策略。默认为 missing。

  • always：总是拉取镜像，如果拉取失败则抛出错误。

  • missing: 仅当本地容器存储中不存在镜像时才拉取镜像。如果找不到镜像且拉取失败，则抛出错误。

  • never: 从不拉取镜像，但使用本地容器存储中的镜像。如果找不到镜像，则抛出错误。

  • newer: 如果注册表上的镜像比本地容器存储中的镜像新，则拉取。当摘要不同时，镜像被认为是更新的。比较时间戳容易出错。如果找到了本地镜像，则会抑制拉取错误。

--quiet, -q

抑制指示正在处理哪个指令的输出消息，以及从注册表拉取镜像和写入输出镜像时的进度。

--retry=attempts

在仓库和本地存储之间拉取或推送镜像失败时重试的次数。默认为 3。

--retry-delay=duration

在注册表和本地存储之间拉取或推送镜像失败时，重试尝试之间的延迟持续时间。默认是从两秒开始，然后指数退避。当设置此值时使用此延迟，并且不会发生指数退避。

--rewrite-timestamp

为镜像生成新层时，确保新添加的内容的时间戳不晚于 --source-date-epoch 标志所使用的值（如果提供了该标志），方法是用该值替换任何晚于该值的时间戳。

--rm

成功构建后删除中间容器（默认值为 true）。

--runtime=path

用于运行 RUN 指令指定命令的备用 OCI 兼容运行时 path。

注意：您还可以通过设置 BUILDAH_RUNTIME 环境变量来覆盖默认运行时。 export BUILDAH_RUNTIME=/usr/local/bin/runc

--runtime-flag=flag

添加容器运行时的全局标志。要列出支持的标志，请查阅所选容器运行时的手册页。

注意：不要将前导 -- 传递给标志。要将 runc 标志 --log-format json 传递给 buildah build，给定的选项是 --runtime-flag log-format=json。

--sbom=preset

通过使用指定的扫描器镜像、扫描器命令和合并策略组合扫描工作容器和构建上下文，为输出镜像生成 SBOM（软件物料清单）。必须与一个或多个 --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-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 时，将生成的 SBOM 存储在输出镜像中指定的路径中。没有默认值。

--sbom-image-purl-output=path

生成 SBOM 时，扫描它们以获取 PURL (包 URL) 信息，并将找到的 PURL 列表保存到输出镜像中指定的路径。没有默认值。

--sbom-merge-strategy=method

如果正在使用多个 --sbom-scanner-command 值，则使用指定的方法将后续命令的输出与先前命令的输出合并。可识别的值包括

  • cat 连接文件。

  • merge-cyclonedx-by-component-name-and-version 合并 JSON 文档的“component”字段，忽略当“name”和“version”值的组合已存在时来自文档的值。文档按其生成顺序进行处理，即生成它们的命令的指定顺序。

  • merge-spdx-by-package-name-and-versioninfo 合并 JSON 文档的“package”字段，忽略当“name”和“versionInfo”值的组合已存在时来自文档的值。文档按其生成顺序进行处理，即生成它们的命令的指定顺序。

--sbom-output=file

生成 SBOM 时，将生成的 SBOM 存储在本地文件系统中指定的文件中。没有默认值。

--sbom-purl-output=file

生成 SBOM 时，扫描它们以获取 PURL (包 URL) 信息，并将找到的 PURL 列表保存到本地文件系统中指定的文件中。没有默认值。

--sbom-scanner-command=image

通过从扫描器镜像运行指定的命令来生成 SBOM。如果指定了多个命令，它们将按指定顺序运行。执行以下文本替换

  • {ROOTFS} 构建镜像文件系统的根目录，绑定挂载。

  • {CONTEXT} 构建上下文和额外的构建上下文，绑定挂载。

  • {OUTPUT} 临时输出文件的名称，将读取并与其他文件合并或复制到其他位置。

--sbom-scanner-image=image

使用指定的扫描器镜像生成 SBOM。

--secret=id=id[,src=envOrFile][,env=ENV][,type=file | env]

以安全的方式将秘密信息传递给 Containerfile，用于构建镜像，这些秘密信息不会存储在最终镜像中，也不会在其他阶段可见。秘密的值将从“id”选项指定的环境变量或文件中读取，如果指定了“src”选项，则从“src”选项指定的环境变量或文件中读取，或者从“env”选项指定的环境变量中读取。请参阅 EXAMPLES。秘密默认将挂载到容器的 /run/secrets/id 中。

要稍后使用该秘密，请在 Containerfile 的 RUN 指令中使用 --mount 标志。

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

可以使用 RUN --mount 标志的“target”、“dst”或“destination”选项来覆盖秘密在容器中的位置。

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

注意：更改秘密文件的内容不会触发使用这些秘密的层的重建。

--security-opt=option

安全选项

  • apparmor=unconfined : 关闭容器的 apparmor 限制

  • apparmor=alternate-profile : 为容器设置 apparmor 限制配置文件

  • label=user:USER : 为容器进程设置标签 user

  • label=role:ROLE : 为容器进程设置标签 role

  • label=type:TYPE : 为容器进程设置标签进程类型

  • label=level:LEVEL : 为容器进程设置标签级别

  • label=filetype:TYPE : 为容器文件设置标签文件类型

  • label=disable : 关闭容器的标签分离

  • no-new-privileges : 禁用容器进程获取额外权限

  • seccomp=unconfined : 关闭容器的 seccomp 限制

  • seccomp=profile.json : 用作容器 seccomp 过滤器的 JSON 文件。

--shm-size=number[unit]

/dev/shm 的大小。 单位 可以是 b (字节)、k (千字节)、m (兆字节) 或 g (千兆字节)。如果省略单位，系统将使用字节。如果省略大小，默认值为 64m。当 size 为 0 时，容器用于 IPC 的内存量没有限制。此选项与 --ipc=host 冲突。

--skip-unused-stages

跳过多阶段构建中不影响目标阶段的阶段。（默认值：true）。

--source-date-epoch=seconds

将构建镜像的“created”时间戳设置为自纪元（Unix 时间 0，即 1970 年 1 月 1 日 00:00:00 UTC）以来的秒数（默认是使用 SOURCE_DATE_EPOCH 环境变量中设置的值，如果未设置则使用当前时间）。

当镜像提交时，“created”时间戳会写入镜像的配置和清单中，因此即使 Containerfile 和构建上下文没有其他更改，两次运行相同的构建通常也会生成具有不同 sha256 哈希的镜像。

当设置此标志时，SOURCE_DATE_EPOCH 构建参数将为其声明的阶段提供其值。

当设置此标志时，镜像配置的“created”时间戳始终设置为指定的时间，这应该允许使用相同的输入在不同时间构建相同的镜像。

当设置此标志时，按照 --output 标志指定写入的输出将带有完全指定的时间戳。

与类似的 --timestamp 标志冲突，后者也将其指定的时间设置在新层的内容上。

--squash

将镜像所有新层压缩成一个新层；任何现有层都不会被压缩。

--squash-all

将新镜像的所有层（包括从基础镜像继承的层）压缩成一个新层。

--ssh=default | id[=socket>

SSH 代理套接字或密钥以暴露给构建。套接字路径可以留空以使用 default=$SSH_AUTH_SOCK 的值

要稍后使用 ssh 代理，请在 Containerfile 中的 RUN 指令中使用 --mount 选项

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

--tag, -t=imageName

指定如果构建过程成功完成，分配给结果镜像的名称。如果 imageName 不包含注册表名称，则注册表名称 localhost 会被前置到镜像名称中。

--target=stageName

设置要构建的目标构建阶段。当构建具有多个构建阶段的 Containerfile 时，可以使用 --target 按名称指定一个中间构建阶段作为结果镜像的最终阶段。目标阶段之后的命令将被跳过。

--timestamp=seconds

设置创建时间戳为自纪元以来的秒数，以允许确定性构建（默认为当前时间）。默认情况下，创建时间戳会随着每次提交而更改并写入镜像清单中，即使源完全相同，也会导致镜像的 sha256 哈希值不同。当设置 --timestamp 时，创建时间戳始终设置为指定的时间，因此不会更改，从而允许镜像的 sha256 哈希值保持不变。所有提交到镜像层的文件的创建时间戳都将是该时间戳。

如果 Containerfile 中唯一的指令是 FROM，此标志无效。

--tls-verify

联系注册表时要求 HTTPS 并验证证书（默认值：true）。如果明确设置为 true，则使用 TLS 验证。如果设置为 false，则不使用 TLS 验证。如果未指定，则使用 TLS 验证，除非目标注册表在 containers-registries.conf(5) 中列为不安全注册表

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

指定在处理 RUN 指令时应用于启动进程的资源限制。此选项可以多次指定。识别的资源类型包括：“core”：最大核心转储大小 (ulimit -c) “cpu”：最大 CPU 时间 (ulimit -t) “data”：进程数据段的最大大小 (ulimit -d) “fsize”：新文件的最大大小 (ulimit -f) “locks”：文件锁的最大数量 (ulimit -x) “memlock”：锁定内存的最大量 (ulimit -l) “msgqueue”：消息队列中的最大数据量 (ulimit -q) “nice”：niceness 调整 (nice -n, ulimit -e) “nofile”：最大打开文件数 (ulimit -n) “nproc”：最大进程数 (ulimit -u) “rss”：进程的最大大小 (ulimit -m) “rtprio”：最大实时调度优先级 (ulimit -r) “rttime”：阻塞系统调用之间的最大实时执行量 “sigpending”：最大挂起信号数 (ulimit -i) “stack”：最大堆栈大小 (ulimit -s)

--unsetannotation=annotation

取消设置镜像注释，导致注释不从基础镜像继承。

--unsetenv=env

从最终镜像中取消设置环境变量。

--unsetlabel=label

取消设置镜像标签，导致标签不从基础镜像继承。

--userns=how

设置处理 RUN 指令时用户命名空间的配置。配置值可以是“” (空字符串) 或 “container” 以指示创建新的用户命名空间，也可以是 “host” 以指示重用 podman 本身正在运行的用户命名空间，或者它可以是已由另一个进程使用的用户命名空间的路径。

--userns-gid-map=mapping

直接指定用于在文件系统级别设置工作容器内容所有权的 GID 映射。处理 RUN 指令时运行的命令默认在自己的用户命名空间中运行，使用 UID 和 GID 映射进行配置。

此映射中的条目采用一个或多个三元组的形式，包括起始容器内 GID、对应的起始主机级别 GID 以及映射条目表示的连续 ID 数。

此选项覆盖 /etc/containers/storage.conf 中 options 部分的 remap-gids 设置。

如果未指定此选项，但提供了全局 --userns-gid-map 设置，则使用全局选项中的设置。

如果未指定 --userns-uid-map-user、--userns-gid-map-group 或 --userns-gid-map 中的任何一个，但指定了 --userns-uid-map，则 GID 映射设置为使用与 UID 映射相同的数值。

--userns-gid-map-group=group

指定用于在文件系统级别设置工作容器内容所有权的 GID 映射，可以在 /etc/subgid 文件中与指定组对应的条目中找到。处理 RUN 指令时运行的命令默认在自己的用户命名空间中运行，使用 UID 和 GID 映射进行配置。如果指定了 --userns-uid-map-user，但未指定 --userns-gid-map-group，则 podman 假定指定的用户名为此选项的默认设置也是一个合适的组名。

注意：当无根用户指定此选项时，指定的映射是相对于容器中的无根用户命名空间的，而不是相对于有根运行时的主机。

--userns-uid-map=mapping

直接指定用于在文件系统级别设置工作容器内容所有权的 UID 映射。处理 RUN 指令时运行的命令默认在自己的用户命名空间中运行，使用 UID 和 GID 映射进行配置。

此映射中的条目采用一个或多个三元组的形式，包括起始容器内 UID、对应的起始主机级别 UID 以及映射条目表示的连续 ID 数。

此选项覆盖 /etc/containers/storage.conf 中 options 部分的 remap-uids 设置。

如果未指定此选项，但提供了全局 --userns-uid-map 设置，则使用全局选项中的设置。

如果未指定 --userns-uid-map-user、--userns-gid-map-group 或 --userns-uid-map 中的任何一个，但指定了 --userns-gid-map，则 UID 映射设置为使用与 GID 映射相同的数值。

--userns-uid-map-user=user

指定用于在文件系统级别设置工作容器内容所有权的 UID 映射，可以在 /etc/subuid 文件中与指定用户对应的条目中找到。处理 RUN 指令时运行的命令默认在自己的用户命名空间中运行，使用 UID 和 GID 映射进行配置。如果指定了 --userns-gid-map-group，但未指定 --userns-uid-map-user，则 podman 假定指定的组名也是此选项的默认设置的合适用户名。

注意：当无根用户指定此选项时，指定的映射是相对于容器中的无根用户命名空间的，而不是相对于有根运行时的主机。

--uts=how

设置处理 RUN 指令时 UTS 命名空间的配置。配置值可以是“” (空字符串) 或 “container” 以指示创建新的 UTS 命名空间，也可以是 “host” 以指示重用 podman 本身正在运行的 UTS 命名空间，或者它可以是已由另一个进程使用的 UTS 命名空间的路径。

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

在构建过程中执行 RUN 指令时，将主机目录挂载到容器中。

OPTIONS 是一个逗号分隔的列表，可以是一个或多个：

  • [rw|ro]

  • [z|Z|O]

  • [U]

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

CONTAINER-DIR 必须是绝对路径，例如 /src/docs。HOST-DIR 也必须是绝对路径。Podman 在处理 RUN 指令时将 HOST-DIR 绑定挂载到指定路径。

您可以指定多个 -v 选项来挂载一个或多个挂载点。

您可以在卷后面添加 :ro 或 :rw 后缀，分别以只读或读写模式挂载。默认情况下，卷以读写模式挂载。请参阅示例。

Chowning Volume Mounts（更改卷挂载的属主）

默认情况下，Podman 不更改挂载的源卷目录的所有者和组。当使用用户命名空间运行时，命名空间内的 UID 和 GID 可能对应主机上的另一个 UID 和 GID。

:U 后缀告诉 Podman 根据命名空间内的 UID 和 GID 使用正确的主机 UID 和 GID，以递归更改源卷的所有者和组。

警告：请谨慎使用，因为这会修改主机文件系统。

Labeling Volume Mounts（为卷挂载添加标签）

SELinux 等标签系统要求在挂载到容器的卷内容上放置适当的标签。如果没有标签，安全系统可能会阻止容器内运行的进程使用该内容。默认情况下，Podman 不更改操作系统设置的标签。

要在容器上下文中更改标签，请在卷挂载后面添加 :z 或 :Z 这两个后缀之一。这些后缀告诉 Podman 重新标记共享卷上的文件对象。z 选项告诉 Podman 两个容器共享卷内容。结果，Podman 用共享内容标签标记内容。共享卷标签允许所有容器读/写内容。Z 选项告诉 Podman 用私有非共享标签标记内容。只有当前容器可以使用私有卷。

注意：不要重新标记系统文件和目录。重新标记系统内容可能会导致主机上的其他受限服务失败。对于这些类型的容器，建议禁用 SELinux 分离。选项 --security-opt label=disable 禁用容器的 SELinux 分离。例如，如果用户希望将其整个主目录卷挂载到构建容器中，则需要禁用 SELinux 分离。

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

Overlay Volume Mounts（覆盖卷挂载）

:O 标志告诉 Podman 使用 Overlay 文件系统将主机上的目录挂载为临时存储。 RUN 命令容器被允许修改挂载点内的内容，并将其存储在容器存储中的单独目录中。在 Overlay FS 术语中，源目录是下层，容器存储目录是上层。当 RUN 命令执行完成后，对挂载点的修改将被销毁，类似于 tmpfs 挂载点。

随后的任何 RUN 命令执行都会看到原始源目录内容，之前 RUN 命令所做的任何更改都不再存在。

overlay 挂载的一个用例是将主机的包缓存共享到容器中，以加快构建速度。

注意

  • Overlay 挂载目前在无根模式下不受支持。

  • O 标志不允许与 Z 或 z 标志一起指定。挂载到容器中的内容将带有私有标签。在 SELinux 系统上，源目录中的标签需要可被容器标签读取。否则，必须禁用容器的 SELinux 分离才能使其工作。

  • 使用 overlay 挂载修改挂载到容器中的目录卷可能会导致意外故障。在容器运行完成之前，请勿修改目录。

默认情况下，绑定挂载的卷是 private。这意味着容器内完成的任何挂载在主机上都不可见，反之亦然。此行为可以通过指定卷挂载传播属性来更改。

当挂载传播策略设置为 shared 时，在该卷上容器内部完成的任何挂载对主机和容器都可见。当挂载传播策略设置为 slave 时，启用单向挂载传播，并且在该卷上主机上完成的任何挂载仅在容器内部可见。要控制卷的挂载传播属性，请使用 :[r]shared、:[r]slave 或 :[r]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]

要更改挂载点的传播属性，请使用 mount 命令。例如，要绑定挂载源目录 /foo，请执行 mount --bind /foo /foo 和 mount --make-private --make-shared /foo。这会将 /foo 转换为 shared 挂载点。源挂载的传播属性可以直接更改。例如，如果 / 是 /foo 的源挂载，则使用 mount --make-shared / 将 / 转换为 shared 挂载。

示例

使用指定 Containerfile 和默认 farm 构建命名镜像和清单列表

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

使用指定 farm 构建命名镜像和清单列表

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

使用指定 farm 构建命名镜像和清单列表，在将所有镜像推送到 registry 后，从 farm 节点中删除它们

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

使用默认 farm 为指定平台构建命名镜像和清单列表

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

另请参阅

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)

历史

2023 年 9 月，由 Urvashi Mohnani <umohnani@redhat.com> 首次编译

脚注

1：Podman 项目致力于包容性，这是开源的核心价值。此处使用的 master 和 slave 挂载传播术语存在问题且具有分歧，需要更改。但是，这些术语目前在 Linux 内核中使用，并且在此刻必须照常使用。当内核维护者纠正此用法时，Podman 将立即效仿。