尧图网站建设 
云原生【免费下载链接】buildahA tool that facilitates building OCI images.项目地址https://gitcode.com/gh_mirrors/bu/buildah点击查看免费下载导读本篇教程围绕 Buildah 如何将 OCI 兼容镜像移入、移出私有或公有容器镜像仓库container registry展开完整演示从启动本地私有 Registry、推送镜像、Skopeo 验证、Docker 互操作测试到推送/拉取 Docker Hub的端到端流程。读完本文你将掌握buildah push、buildah from、buildah pull等命令在仓库场景下的核心用法理解 transport 协议、--tls-verify、--creds、--pull-always等关键参数的真实语义并能把 Buildah 构建出的标准 OCI 镜像安全地发布到任意仓库。本文以仓库中的 docs/tutorials/02-registries-repositories.md 为主体脉络并结合 cmd/buildah/push.go、cmd/buildah/from.go、cmd/buildah/pull.go 等源码展开原理级解读。前置条件上一教程留下的镜像本文是 Buildah 教程系列的第二篇。在 第一篇教程 中我们从 scratch 构建了一个名为fedora-bashecho的镜像——一个包含了 bash 脚本runecho.sh、并设置了CMD的小型 OCI 镜像并且已经用docker-daemon协议把它推送到了本地 Docker daemon。本篇将把同一个镜像推送到一个私有的容器镜像仓库。如果你还没有这个镜像可以按第一篇教程的流程重新构建从 scratch 创建空容器、用buildah copy放入脚本、buildah config --cmd配置启动命令、最后buildah commit生成镜像# newcontainer$(buildah from scratch) # buildah copy $newcontainer ./runecho.sh /usr/bin/ # buildah config --cmd /usr/bin/runecho.sh $newcontainer # buildah commit $newcontainer fedora-bashecho理解镜像来源与目标Buildah 的 transport 机制buildah from、buildah push、buildah pull等命令在指定镜像时都遵循transport:details的格式。默认且隐含假设的查找顺序是先看本地 containers-storagecontainers-storage:中是否已有该镜像再去容器镜像仓库默认是 Docker Hubdocker:拉取。以buildah from为例其源码中的示例直接体现了多种 transport 的写法见 cmd/buildah/from.go# buildah from --pull imagename # buildah from docker-daemon:imagename:imagetag # buildah from --name myimagename myregistry/myrepository/imagename:imagetag也就是说如果本地 Docker daemon 中已经下载好了 registry 镜像就不必再去仓库拉取可以直接用docker-daemontransport 引用它# registryctr$(buildah from docker-daemon:registry:latest)同理在buildah push侧见 cmd/buildah/push.go如果目标地址没有显式给出 transport源码会自动补上docker://并按容器镜像仓库处理# buildah push imageID docker://registry.example.com/repository:tag # buildah push imageID docker-daemon:image:tag # buildah push imageID oci:/path/to/layout:image:tag从源码看push命令支持docker、docker-daemon、oci、oci-archive、dir等全部containers-transports(5)所列的 transport不指定 transport 时日志会提示Assuming docker:// as the transport method for DESTINATION。第一步拉取并启动本地私有 Registry在推送镜像之前需要先有一个接收镜像的仓库。最简单的方式是直接拉取官方 registry 镜像并把buildah from返回的容器名保存到 bash 变量中与第一篇教程中的做法一致# registryctr$(buildah from registry)提示使用docker-daemontransport 也可以复用 Docker daemon 中已有的 registry 镜像避免重复从 Docker Hub 下载# registryctr$(buildah from docker-daemon:registry:latest)接下来启动这个 registry 容器。建议在单独的终端shell中启动并让它保持前台运行# buildah run --nethost $registryctr /entrypoint.sh /etc/docker/registry/config.yml这里使用了--nethost让容器共享宿主机网络栈这样 registry 直接监听宿主机的 5000 端口/entrypoint.sh /etc/docker/registry/config.yml是 registry 容器镜像内置的启动入口与默认配置文件路径。如果希望看到 registry 内部的更多细节尤其是排查推送/拉取问题时可以用 debug 日志级别重新启动# buildah --log-leveldebug run --nethost $registryctr /entrypoint.sh /etc/docker/registry/config.yml--log-leveldebug是 Buildah 的全局选项可以加在任何 Buildah 命令前面用于输出底层调用链日志例如push源码中大量使用logrus.Debugf记录 transport 假设、镜像 digest 等信息见 cmd/buildah/push.go。需要注意这里运行的 registry 是从 Docker Hub 拉取的Docker registry 镜像但它是通过buildah run直接运行的——此刻并没有任何 Docker daemon 在运行这也再次印证了 Buildah 无守护进程daemon-less的特性。第二步推送镜像到私有 RegistryRegistry 启动后就在等待处理请求。现在把fedora-bashecho推送到本地私有仓库。默认情况下Buildah只允许到仓库的安全HTTPS连接并验证证书。因此对于运行在 localhost:5000 上的明文HTTP本地 registry需要显式关闭 TLS 验证# buildah push --tls-verifyfalse fedora-bashecho docker://localhost:5000/ipbabble/fedora-bashecho:latest这条命令中有三个要点--tls-verifyfalse关闭 HTTPS 证书校验。在push命令的源码cmd/buildah/push.go中该标志默认值为true其说明为require HTTPS and verify certificates when accessing the registry. TLS verification cannot be used when talking to an insecure registry.从 pkg/parse/parse.go 的SystemContextFromOptions可以看到--tls-verifyfalse最终会转换为DockerInsecureSkipTLSVerify true并同步作用于 OCI 与 docker-daemon 传输。docker://localhost:5000/ipbabble/fedora-bashecho:latest显式指定 transport 与仓库地址。localhost:5000是刚才 registry 监听的主机与端口。ipbabble命名空间类似多租户的 Docker Hub仓库 URL 中的第二段这里是ipbabble用于区分不同用户的同名镜像避免与他人相似命名的镜像冲突。第三步用 Skopeo 验证镜像已入库Skopeo 是 containers 生态中专门用于在仓库中直接检查镜像而无需先把镜像拉下来的工具它已经发展出很多其他用途。验证镜像是否成功存入私有 registry# skopeo inspect --tls-verifyfalse docker://localhost:5000/ipbabble/fedora-bashecho:latest { Name: localhost:5000/ipbabble/fedora-bashecho, Digest: sha256:6806f9385f97bc09f54b5c0ef583e58c3bc906c8c0b3e693d8782d0a0acf2137, RepoTags: [ latest ], Created: 2017-12-05T21:38:12.311901938Z, DockerVersion: , Labels: { name: fedora-bashecho }, Architecture: amd64, Os: linux, Layers: [ sha256:0cb7556c714767b8da6e0299cbeab765abaddede84769475c023785ae66d10ca ] }输出中的Digestsha256:6806f938...是镜像内容寻址的唯一标识Layers列表则对应镜像的文件系统层。这个 digest 在后面 Docker 拉取验证时会出现一致的值这是 OCI 镜像内容可移植性的直接证据。第四步验证对 Docker 的可移植性OCI 镜像最核心的价值之一就是跨引擎可移植。重新启动 Docker和第一篇教程一样然后从私有 registry 拉取并运行这个镜像# systemctl start docker # docker pull localhost:5000/ipbabble/fedora-bashecho Using default tag: latest Trying to pull repository localhost:5000/ipbabble/fedora-bashecho ... sha256:6806f9385f97bc09f54b5c0ef583e58c3bc906c8c0b3e693d8782d0a0acf2137: Pulling from localhost:5000/ipbabble/fedora-bashecho 0cb7556c7147: Pull complete Digest: sha256:6806f9385f97bc09f54b5c0ef583e58c3bc906c8c0b3e693d8782d0a0acf2137 Status: Downloaded newer image for localhost:5000/ipbabble/fedora-bashecho:latest # docker run --rm localhost:5000/ipbabble/fedora-bashecho This is a new container named ipbabble [ 0 ] This is a new container named ipbabble [ 1 ] This is a new container named ipbabble [ 2 ] This is a new container named ipbabble [ 3 ] This is a new container named ipbabble [ 4 ] This is a new container named ipbabble [ 5 ] This is a new container named ipbabble [ 6 ] This is a new container named ipbabble [ 7 ] This is a new container named ipbabble [ 8 ] This is a new container named ipbabble [ 9 ] # systemctl stop docker注意 Docker 拉取时显示的 digest 与 Skopeo inspect 输出完全一致且容器按镜像CMD配置直接运行了runecho.sh脚本。验证完毕后可以停掉 Docker daemonsystemctl stop docker——它在本例中仅用于互操作性演示。第五步推送镜像到 Docker Hub推送 Docker Hub 与推送私有 registry 一样简单前提是你拥有带凭据的账户。下面示例使用的是 Docker Hub 的 API key其形式为username:password示例密码已做隐私脱敏处理# buildah push --credsipbabble:5bbb9990-6eeb-1234-af1a-aaa80066887c fedora-bashecho docker://ipbabble/fedora-bashecho:latest要点说明--creds指定仓库访问凭据格式为[username[:password]]。在push源码cmd/buildah/push.go中--creds的说明是use[username[:password]]for accessing the registry它最终会被解析进SystemContext.DockerAuthConfig见 pkg/parse/parse.go。如果只给用户名或完全省略命令行会交互式提示输入缺失部分密码输入时不回显。docker://ipbabble/fedora-bashecho:latest不写 registry 主机名和端口即使用 Docker Hub 的默认主机与默认 443 端口这是 docker transport 的默认行为。同样用 Skopeo 验证注意 Docker Hub 场景也需要--creds访问私有仓库# skopeo inspect --creds ipbabble:5bbb9990-6eeb-1234-af1a-aaa80066887c docker://ipbabble/fedora-bashecho:latest { Name: docker.io/ipbabble/fedora-bashecho, Digest: sha256:6806f9385f97bc09f54b5c0ef583e58c3bc906c8c0b3e693d8782d0a0acf2137, RepoTags: [ latest ], Created: 2017-12-05T21:38:12.311901938Z, DockerVersion: , Labels: { name: fedora-bashecho }, Architecture: amd64, Os: linux, Layers: [ sha256:0cb7556c714767b8da6e0299cbeab765abaddede84769475c023785ae66d10ca ] }注意此时镜像的Name变成了docker.io/ipbabble/fedora-bashecho而Digest与之前在私有 registry 中的完全一致——同一镜像内容在不同仓库间保持字节级一致。登录方式的补充说明除了每次推送时用--creds更推荐用buildah login保存凭据。buildah login是独立命令见 cmd/buildah/login.go例如buildah login quay.io它会把凭据写入认证文件默认${XDG_RUNTIME_DIR}/containers/auth.json见 docs/buildah-push.1.md后续推送/拉取会自动使用也可用REGISTRY_AUTH_FILE环境变量覆盖默认认证文件路径。第六步从仓库拉取镜像现在用buildah from从 Docker Hub 把镜像拉取回来。但在拉取之前先清理本地 containers-storage确保本地没有fedora-bashecho的副本——否则 Buildah 会发现镜像已存在而跳过拉取。先查看当前本地镜像# buildah images IMAGE ID IMAGE NAME CREATED AT SIZE d4cd7d73ee42 docker.io/library/registry:latest Dec 1, 2017 22:15 31.74 MB e31b0f0b0a63 docker.io/library/fedora-bashecho:latest Dec 5, 2017 21:38 772 B删除本地的fedora-bashecho镜像# buildah rmi fedora-bashecho untagged: docker.io/library/fedora-bashecho:latest e31b0f0b0a63e94c5a558d438d7490fab930a282a4736364360ab9b92cb25f3a确认镜像已删除# buildah images IMAGE ID IMAGE NAME CREATED AT SIZE d4cd7d73ee42 docker.io/library/registry:latest Dec 1, 2017 22:15 31.74 MB然后从 Docker Hub 拉取不带 registry 主机名默认走 Docker Hub# buildah from ipbabble/fedora-bashecho再检查本地 containers-storage确认镜像已就位# buildah images IMAGE ID IMAGE NAME CREATED AT SIZE d4cd7d73ee42 docker.io/library/registry:latest Dec 1, 2017 22:15 31.74 MB 864871ac1c45 docker.io/ipbabble/fedora-bashecho:latest Dec 5, 2017 21:38 315.4 MB成功镜像已经从 Docker Hub 拉取到本地存储。不想手动清理用--pull-always强制拉取如果不想先执行rmi清理步骤可以直接用--pull-always标志强制重新拉取镜像并覆盖本地同名镜像# buildah from --pull-always ipbabble/fedora-bashecho从 cmd/buildah/from.go 源码看--pull-always与--pull-never都是为兼容旧习惯保留的隐藏标志推荐的正式用法是--pull参数其取值语义如下取值行为always即使本地已有同名镜像也强制从仓库拉取missing默认仅当本地没有该镜像时才拉取never只使用本地已有镜像绝不访问仓库newer仅当仓库中的镜像比本地更新时才拉取--pull不带参数时等价于--pullalways源码中通过NoOptDefVal always实现。独立的buildah pull命令见 cmd/buildah/pull.go也提供--policy missing|always|ifnewer|never、--all-tags下载仓库中所有标签、--platform/--arch/--os按平台拉取等选项适合只下载镜像而不创建工作容器的场景。参考push 命令的常用选项速查结合 docs/buildah-push.1.md 与 cmd/buildah/push.gobuildah push在仓库场景下常用的选项包括选项作用--tls-verify是否要求 HTTPS 并验证证书默认true访问明文/自签名证书仓库需设为false--creds [username[:password]]仓库访问凭据缺省部分交互式输入--authfile path认证文件路径默认${XDG_RUNTIME_DIR}/containers/auth.json--cert-dir path指定访问仓库用的 CA 证书目录默认/etc/containers/certs.d--format oci|v2s2|v2s1推送到目标时使用的 manifest 类型默认跟随源镜像--digestfile file推送完成后把镜像 digest 写入指定文件--quiet, -q关闭进度输出--retry/--retry-delay推送失败重试次数默认 3与重试间隔默认 2s--remove-signatures推送时不复制签名--sign-by fingerprint用指定 GPG 指纹对推送的镜像签名另外BUILD_REGISTRY_SOURCES环境变量JSON 格式含insecureRegistries、blockedRegistries、allowedRegistries三组列表可用于按仓库名限制允许推送的 registryregistries.conf/etc/containers/registries.conf则负责在镜像名不含 registry 部分时决定查询哪些仓库。小结通过本教程你已经完成了 Buildah 与容器镜像仓库的完整交互闭环启动私有 Registrybuildah from registrybuildah run --nethost全程无需 Docker daemon推送私有仓库buildah push --tls-verifyfalse fedora-bashecho docker://localhost:5000/ipbabble/fedora-bashecho:latestSkopeo 验证入库在不拉取镜像的前提下核对 digest、标签、标签层信息Docker 互操作验证docker pull/docker run直接运行 Buildah 构建的镜像digest 完全一致推送 Docker Hub--creds携带凭据默认 transport 自动指向 Docker Hub拉取回本地buildah from/--pull-always强制覆盖或用buildah pull --policy精细控制拉取策略。整个过程验证了 Buildah 构建的 OCI 镜像在私有仓库、公有仓库与不同容器引擎之间具备一致的内容寻址digest与良好的可移植性。更多命令细节可参考仓库中的buildah-push(1)、buildah-from(1)、buildah-pull(1)等手册页docs 目录以及 Buildah 与 Podman 关系、安装说明等文档README.md、install.md。赞分享云原生【免费下载链接】buildahA tool that facilitates building OCI images.项目地址https://gitcode.com/gh_mirrors/bu/buildah点击查看免费下载相关推荐容器镜像仓库访问日志记录Containerd镜像拉取与推送操作容器镜像仓库访问日志记录Containerd镜像拉取与推送操作 在容器化部署流程中镜像仓库Registry的访问记录是排查部署故障、审计安全合规的关键依云原生容器运行时LTX-Video 快速上手指南跑通文生视频与图生视频的最短路径LTX Video 快速上手指南跑通文生视频与图生视频的最短路径 LTX Video 是基于 DiT 架构的开源视频生成模型官方仓库支持文生视频、图生视频、人工智能大模型媒体生成视频多模态Micro框架容器镜像仓库私有仓库配置与镜像推送Micro框架容器镜像仓库私有仓库配置与镜像推送 为什么需要私有镜像仓库 在使用Micro框架开发微服务时随着项目规模增长团队协作和版本管理变得尤为重要后端微服务Web框架上一篇Powerlevel10k 字体配置完整指南5 步搞定终端特殊符号变方框的问题下一篇npm-check-updates配置验证功能避免常见的配置错误创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Buildah 与容器镜像仓库实战指南：私有 Registry 与 Docker Hub 的推送、拉取与互操作
云原生【免费下载链接】buildahA tool that facilitates building OCI images.项目地址https://gitcode.com/gh_mirrors/bu/buildah点击查看免费下载导读本篇教程围绕 Buildah 如何将 OCI 兼容镜像移入、移出私有或公有容器镜像仓库container registry展开完整演示从启动本地私有 Registry、推送镜像、Skopeo 验证、Docker 互操作测试到推送/拉取 Docker Hub的端到端流程。读完本文你将掌握buildah push、buildah from、buildah pull等命令在仓库场景下的核心用法理解 transport 协议、--tls-verify、--creds、--pull-always等关键参数的真实语义并能把 Buildah 构建出的标准 OCI 镜像安全地发布到任意仓库。本文以仓库中的 docs/tutorials/02-registries-repositories.md 为主体脉络并结合 cmd/buildah/push.go、cmd/buildah/from.go、cmd/buildah/pull.go 等源码展开原理级解读。前置条件上一教程留下的镜像本文是 Buildah 教程系列的第二篇。在 第一篇教程 中我们从 scratch 构建了一个名为fedora-bashecho的镜像——一个包含了 bash 脚本runecho.sh、并设置了CMD的小型 OCI 镜像并且已经用docker-daemon协议把它推送到了本地 Docker daemon。本篇将把同一个镜像推送到一个私有的容器镜像仓库。如果你还没有这个镜像可以按第一篇教程的流程重新构建从 scratch 创建空容器、用buildah copy放入脚本、buildah config --cmd配置启动命令、最后buildah commit生成镜像# newcontainer$(buildah from scratch) # buildah copy $newcontainer ./runecho.sh /usr/bin/ # buildah config --cmd /usr/bin/runecho.sh $newcontainer # buildah commit $newcontainer fedora-bashecho理解镜像来源与目标Buildah 的 transport 机制buildah from、buildah push、buildah pull等命令在指定镜像时都遵循transport:details的格式。默认且隐含假设的查找顺序是先看本地 containers-storagecontainers-storage:中是否已有该镜像再去容器镜像仓库默认是 Docker Hubdocker:拉取。以buildah from为例其源码中的示例直接体现了多种 transport 的写法见 cmd/buildah/from.go# buildah from --pull imagename # buildah from docker-daemon:imagename:imagetag # buildah from --name myimagename myregistry/myrepository/imagename:imagetag也就是说如果本地 Docker daemon 中已经下载好了 registry 镜像就不必再去仓库拉取可以直接用docker-daemontransport 引用它# registryctr$(buildah from docker-daemon:registry:latest)同理在buildah push侧见 cmd/buildah/push.go如果目标地址没有显式给出 transport源码会自动补上docker://并按容器镜像仓库处理# buildah push imageID docker://registry.example.com/repository:tag # buildah push imageID docker-daemon:image:tag # buildah push imageID oci:/path/to/layout:image:tag从源码看push命令支持docker、docker-daemon、oci、oci-archive、dir等全部containers-transports(5)所列的 transport不指定 transport 时日志会提示Assuming docker:// as the transport method for DESTINATION。第一步拉取并启动本地私有 Registry在推送镜像之前需要先有一个接收镜像的仓库。最简单的方式是直接拉取官方 registry 镜像并把buildah from返回的容器名保存到 bash 变量中与第一篇教程中的做法一致# registryctr$(buildah from registry)提示使用docker-daemontransport 也可以复用 Docker daemon 中已有的 registry 镜像避免重复从 Docker Hub 下载# registryctr$(buildah from docker-daemon:registry:latest)接下来启动这个 registry 容器。建议在单独的终端shell中启动并让它保持前台运行# buildah run --nethost $registryctr /entrypoint.sh /etc/docker/registry/config.yml这里使用了--nethost让容器共享宿主机网络栈这样 registry 直接监听宿主机的 5000 端口/entrypoint.sh /etc/docker/registry/config.yml是 registry 容器镜像内置的启动入口与默认配置文件路径。如果希望看到 registry 内部的更多细节尤其是排查推送/拉取问题时可以用 debug 日志级别重新启动# buildah --log-leveldebug run --nethost $registryctr /entrypoint.sh /etc/docker/registry/config.yml--log-leveldebug是 Buildah 的全局选项可以加在任何 Buildah 命令前面用于输出底层调用链日志例如push源码中大量使用logrus.Debugf记录 transport 假设、镜像 digest 等信息见 cmd/buildah/push.go。需要注意这里运行的 registry 是从 Docker Hub 拉取的Docker registry 镜像但它是通过buildah run直接运行的——此刻并没有任何 Docker daemon 在运行这也再次印证了 Buildah 无守护进程daemon-less的特性。第二步推送镜像到私有 RegistryRegistry 启动后就在等待处理请求。现在把fedora-bashecho推送到本地私有仓库。默认情况下Buildah只允许到仓库的安全HTTPS连接并验证证书。因此对于运行在 localhost:5000 上的明文HTTP本地 registry需要显式关闭 TLS 验证# buildah push --tls-verifyfalse fedora-bashecho docker://localhost:5000/ipbabble/fedora-bashecho:latest这条命令中有三个要点--tls-verifyfalse关闭 HTTPS 证书校验。在push命令的源码cmd/buildah/push.go中该标志默认值为true其说明为require HTTPS and verify certificates when accessing the registry. TLS verification cannot be used when talking to an insecure registry.从 pkg/parse/parse.go 的SystemContextFromOptions可以看到--tls-verifyfalse最终会转换为DockerInsecureSkipTLSVerify true并同步作用于 OCI 与 docker-daemon 传输。docker://localhost:5000/ipbabble/fedora-bashecho:latest显式指定 transport 与仓库地址。localhost:5000是刚才 registry 监听的主机与端口。ipbabble命名空间类似多租户的 Docker Hub仓库 URL 中的第二段这里是ipbabble用于区分不同用户的同名镜像避免与他人相似命名的镜像冲突。第三步用 Skopeo 验证镜像已入库Skopeo 是 containers 生态中专门用于在仓库中直接检查镜像而无需先把镜像拉下来的工具它已经发展出很多其他用途。验证镜像是否成功存入私有 registry# skopeo inspect --tls-verifyfalse docker://localhost:5000/ipbabble/fedora-bashecho:latest { Name: localhost:5000/ipbabble/fedora-bashecho, Digest: sha256:6806f9385f97bc09f54b5c0ef583e58c3bc906c8c0b3e693d8782d0a0acf2137, RepoTags: [ latest ], Created: 2017-12-05T21:38:12.311901938Z, DockerVersion: , Labels: { name: fedora-bashecho }, Architecture: amd64, Os: linux, Layers: [ sha256:0cb7556c714767b8da6e0299cbeab765abaddede84769475c023785ae66d10ca ] }输出中的Digestsha256:6806f938...是镜像内容寻址的唯一标识Layers列表则对应镜像的文件系统层。这个 digest 在后面 Docker 拉取验证时会出现一致的值这是 OCI 镜像内容可移植性的直接证据。第四步验证对 Docker 的可移植性OCI 镜像最核心的价值之一就是跨引擎可移植。重新启动 Docker和第一篇教程一样然后从私有 registry 拉取并运行这个镜像# systemctl start docker # docker pull localhost:5000/ipbabble/fedora-bashecho Using default tag: latest Trying to pull repository localhost:5000/ipbabble/fedora-bashecho ... sha256:6806f9385f97bc09f54b5c0ef583e58c3bc906c8c0b3e693d8782d0a0acf2137: Pulling from localhost:5000/ipbabble/fedora-bashecho 0cb7556c7147: Pull complete Digest: sha256:6806f9385f97bc09f54b5c0ef583e58c3bc906c8c0b3e693d8782d0a0acf2137 Status: Downloaded newer image for localhost:5000/ipbabble/fedora-bashecho:latest # docker run --rm localhost:5000/ipbabble/fedora-bashecho This is a new container named ipbabble [ 0 ] This is a new container named ipbabble [ 1 ] This is a new container named ipbabble [ 2 ] This is a new container named ipbabble [ 3 ] This is a new container named ipbabble [ 4 ] This is a new container named ipbabble [ 5 ] This is a new container named ipbabble [ 6 ] This is a new container named ipbabble [ 7 ] This is a new container named ipbabble [ 8 ] This is a new container named ipbabble [ 9 ] # systemctl stop docker注意 Docker 拉取时显示的 digest 与 Skopeo inspect 输出完全一致且容器按镜像CMD配置直接运行了runecho.sh脚本。验证完毕后可以停掉 Docker daemonsystemctl stop docker——它在本例中仅用于互操作性演示。第五步推送镜像到 Docker Hub推送 Docker Hub 与推送私有 registry 一样简单前提是你拥有带凭据的账户。下面示例使用的是 Docker Hub 的 API key其形式为username:password示例密码已做隐私脱敏处理# buildah push --credsipbabble:5bbb9990-6eeb-1234-af1a-aaa80066887c fedora-bashecho docker://ipbabble/fedora-bashecho:latest要点说明--creds指定仓库访问凭据格式为[username[:password]]。在push源码cmd/buildah/push.go中--creds的说明是use[username[:password]]for accessing the registry它最终会被解析进SystemContext.DockerAuthConfig见 pkg/parse/parse.go。如果只给用户名或完全省略命令行会交互式提示输入缺失部分密码输入时不回显。docker://ipbabble/fedora-bashecho:latest不写 registry 主机名和端口即使用 Docker Hub 的默认主机与默认 443 端口这是 docker transport 的默认行为。同样用 Skopeo 验证注意 Docker Hub 场景也需要--creds访问私有仓库# skopeo inspect --creds ipbabble:5bbb9990-6eeb-1234-af1a-aaa80066887c docker://ipbabble/fedora-bashecho:latest { Name: docker.io/ipbabble/fedora-bashecho, Digest: sha256:6806f9385f97bc09f54b5c0ef583e58c3bc906c8c0b3e693d8782d0a0acf2137, RepoTags: [ latest ], Created: 2017-12-05T21:38:12.311901938Z, DockerVersion: , Labels: { name: fedora-bashecho }, Architecture: amd64, Os: linux, Layers: [ sha256:0cb7556c714767b8da6e0299cbeab765abaddede84769475c023785ae66d10ca ] }注意此时镜像的Name变成了docker.io/ipbabble/fedora-bashecho而Digest与之前在私有 registry 中的完全一致——同一镜像内容在不同仓库间保持字节级一致。登录方式的补充说明除了每次推送时用--creds更推荐用buildah login保存凭据。buildah login是独立命令见 cmd/buildah/login.go例如buildah login quay.io它会把凭据写入认证文件默认${XDG_RUNTIME_DIR}/containers/auth.json见 docs/buildah-push.1.md后续推送/拉取会自动使用也可用REGISTRY_AUTH_FILE环境变量覆盖默认认证文件路径。第六步从仓库拉取镜像现在用buildah from从 Docker Hub 把镜像拉取回来。但在拉取之前先清理本地 containers-storage确保本地没有fedora-bashecho的副本——否则 Buildah 会发现镜像已存在而跳过拉取。先查看当前本地镜像# buildah images IMAGE ID IMAGE NAME CREATED AT SIZE d4cd7d73ee42 docker.io/library/registry:latest Dec 1, 2017 22:15 31.74 MB e31b0f0b0a63 docker.io/library/fedora-bashecho:latest Dec 5, 2017 21:38 772 B删除本地的fedora-bashecho镜像# buildah rmi fedora-bashecho untagged: docker.io/library/fedora-bashecho:latest e31b0f0b0a63e94c5a558d438d7490fab930a282a4736364360ab9b92cb25f3a确认镜像已删除# buildah images IMAGE ID IMAGE NAME CREATED AT SIZE d4cd7d73ee42 docker.io/library/registry:latest Dec 1, 2017 22:15 31.74 MB然后从 Docker Hub 拉取不带 registry 主机名默认走 Docker Hub# buildah from ipbabble/fedora-bashecho再检查本地 containers-storage确认镜像已就位# buildah images IMAGE ID IMAGE NAME CREATED AT SIZE d4cd7d73ee42 docker.io/library/registry:latest Dec 1, 2017 22:15 31.74 MB 864871ac1c45 docker.io/ipbabble/fedora-bashecho:latest Dec 5, 2017 21:38 315.4 MB成功镜像已经从 Docker Hub 拉取到本地存储。不想手动清理用--pull-always强制拉取如果不想先执行rmi清理步骤可以直接用--pull-always标志强制重新拉取镜像并覆盖本地同名镜像# buildah from --pull-always ipbabble/fedora-bashecho从 cmd/buildah/from.go 源码看--pull-always与--pull-never都是为兼容旧习惯保留的隐藏标志推荐的正式用法是--pull参数其取值语义如下取值行为always即使本地已有同名镜像也强制从仓库拉取missing默认仅当本地没有该镜像时才拉取never只使用本地已有镜像绝不访问仓库newer仅当仓库中的镜像比本地更新时才拉取--pull不带参数时等价于--pullalways源码中通过NoOptDefVal always实现。独立的buildah pull命令见 cmd/buildah/pull.go也提供--policy missing|always|ifnewer|never、--all-tags下载仓库中所有标签、--platform/--arch/--os按平台拉取等选项适合只下载镜像而不创建工作容器的场景。参考push 命令的常用选项速查结合 docs/buildah-push.1.md 与 cmd/buildah/push.gobuildah push在仓库场景下常用的选项包括选项作用--tls-verify是否要求 HTTPS 并验证证书默认true访问明文/自签名证书仓库需设为false--creds [username[:password]]仓库访问凭据缺省部分交互式输入--authfile path认证文件路径默认${XDG_RUNTIME_DIR}/containers/auth.json--cert-dir path指定访问仓库用的 CA 证书目录默认/etc/containers/certs.d--format oci|v2s2|v2s1推送到目标时使用的 manifest 类型默认跟随源镜像--digestfile file推送完成后把镜像 digest 写入指定文件--quiet, -q关闭进度输出--retry/--retry-delay推送失败重试次数默认 3与重试间隔默认 2s--remove-signatures推送时不复制签名--sign-by fingerprint用指定 GPG 指纹对推送的镜像签名另外BUILD_REGISTRY_SOURCES环境变量JSON 格式含insecureRegistries、blockedRegistries、allowedRegistries三组列表可用于按仓库名限制允许推送的 registryregistries.conf/etc/containers/registries.conf则负责在镜像名不含 registry 部分时决定查询哪些仓库。小结通过本教程你已经完成了 Buildah 与容器镜像仓库的完整交互闭环启动私有 Registrybuildah from registrybuildah run --nethost全程无需 Docker daemon推送私有仓库buildah push --tls-verifyfalse fedora-bashecho docker://localhost:5000/ipbabble/fedora-bashecho:latestSkopeo 验证入库在不拉取镜像的前提下核对 digest、标签、标签层信息Docker 互操作验证docker pull/docker run直接运行 Buildah 构建的镜像digest 完全一致推送 Docker Hub--creds携带凭据默认 transport 自动指向 Docker Hub拉取回本地buildah from/--pull-always强制覆盖或用buildah pull --policy精细控制拉取策略。整个过程验证了 Buildah 构建的 OCI 镜像在私有仓库、公有仓库与不同容器引擎之间具备一致的内容寻址digest与良好的可移植性。更多命令细节可参考仓库中的buildah-push(1)、buildah-from(1)、buildah-pull(1)等手册页docs 目录以及 Buildah 与 Podman 关系、安装说明等文档README.md、install.md。赞分享云原生【免费下载链接】buildahA tool that facilitates building OCI images.项目地址https://gitcode.com/gh_mirrors/bu/buildah点击查看免费下载相关推荐容器镜像仓库访问日志记录Containerd镜像拉取与推送操作容器镜像仓库访问日志记录Containerd镜像拉取与推送操作 在容器化部署流程中镜像仓库Registry的访问记录是排查部署故障、审计安全合规的关键依云原生容器运行时LTX-Video 快速上手指南跑通文生视频与图生视频的最短路径LTX Video 快速上手指南跑通文生视频与图生视频的最短路径 LTX Video 是基于 DiT 架构的开源视频生成模型官方仓库支持文生视频、图生视频、人工智能大模型媒体生成视频多模态Micro框架容器镜像仓库私有仓库配置与镜像推送Micro框架容器镜像仓库私有仓库配置与镜像推送 为什么需要私有镜像仓库 在使用Micro框架开发微服务时随着项目规模增长团队协作和版本管理变得尤为重要后端微服务Web框架上一篇Powerlevel10k 字体配置完整指南5 步搞定终端特殊符号变方框的问题下一篇npm-check-updates配置验证功能避免常见的配置错误创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考