1. 镜像复制：告别Docker，实现跨仓库的“乾坤大挪移”

我刚开始接触容器那会儿，最头疼的就是镜像迁移。比如，想把Docker Hub上的一个基础镜像搬到公司内网的私有仓库里，常规操作是 docker pull 拉下来，再 docker tag 打上私有仓库的标签，最后 docker push 推上去。这一套流程下来，不仅步骤繁琐，最关键的是，你本地必须得装一个完整的Docker守护进程。有时候在CI/CD的构建节点上，或者在一些资源受限的环境里，装个Docker都嫌重。直到我发现了Skopeo的 copy 命令，才真正体会到什么叫“轻装上阵”。

Skopeo的 copy 命令，你可以把它理解成一个专为镜像设计的“超级快递员”。它不需要Docker引擎这个“大仓库”，自己就能直接跟世界各地的“快递收发点”（也就是各种镜像仓库）打交道。它的核心能力是在不同类型的镜像存储之间进行直接复制。这个“类型”范围非常广，比如远程的Docker Registry（docker://）、符合OCI标准的本地目录（oci:）、普通的文件目录（dir:），甚至是像Podman使用的容器存储（containers-storage:）。这意味着，你可以在Docker Hub、Quay.io、你的私有Harbor、以及本地文件夹之间，随意搬运镜像，中间不需要经过Docker这个“二道贩子”。

来，我们看几个我实战中最常用的例子，你就明白它有多方便了。

1.1 从公网仓库“扒”镜像到本地文件夹

有时候你需要分析一个镜像的层结构，或者单纯就是想备份下来，用Skopeo可以一键搞定。比如，我想把官方的Nginx镜像保存到本地一个叫 nginx-backup 的文件夹里：

skopeo copy docker://nginx:latest dir:./nginx-backup

执行这条命令后，Skopeo会去Docker Hub拉取 nginx:latest 镜像，然后把它以OCI格式解包，存放到当前目录下的 nginx-backup 文件夹中。你进去看看，里面会有 manifest.json、oci-layout 等文件，这就是镜像的原始“拆解”状态。下次你想用的时候，可以直接用 podman load 从这个目录加载，或者再用Skopeo把它 copy 到任何地方。这个场景在需要离线分析镜像内容，或者搭建离线环境时，简直是神器。

1.2 给私有仓库搬家，带认证的那种

公司业务升级，镜像仓库从旧的Registry迁移到新的Harbor，这是常有的事。用Skopeo做这件事，流程清晰又可靠。假设旧仓库地址是 old-registry.example.com，新仓库是 new-harbor.example.com，我们要迁移一个叫 myapp 的应用镜像，标签是 v1.2.0。

首先，我们需要提供认证信息。Skopeo支持多种方式，最直接的是通过 --src-creds 和 --dest-creds 参数：

skopeo copy \
  --src-creds=olduser:oldpassword \
  --dest-creds=newuser:newpassword \
  docker://old-registry.example.com/myapp:v1.2.0 \
  docker://new-harbor.example.com/library/myapp:v1.2.0

这里有个细节：目标路径我写的是 library/myapp，这是因为Harbor默认有个 library 项目。当然，你也可以提前在Harbor创建好对应的项目，比如 myproject，那么目标地址就写成 docker://new-harbor.example.com/myproject/myapp:v1.2.0。这个操作是原子性的，镜像的所有层和配置会被完整地复制过去，比用Docker CLI一层层拉取推送要稳定得多，尤其是在网络不太好的情况下。

1.3 格式转换：把Docker格式变成更标准的OCI格式

容器镜像世界主要有两种格式：Docker格式和OCI（Open Container Initiative）格式。OCI是更开放的标准。有时候，为了兼容性或者规范，我们需要把镜像从Docker格式转换成OCI格式。Skopeo在复制过程中就能轻松完成这个转换。

比如，我有一个在本地Docker存储里的镜像，想把它转换成OCI格式存到本地目录：

skopeo copy \
  --format oci \
  containers-storage:localhost/myapp:latest \
  oci:./myapp-oci:latest

通过 --format oci 参数，Skopeo会在复制时，将镜像清单（manifest）和配置（config）都转换为OCI标准格式。这对于需要严格遵循OCI规范的工具链或安全扫描场景非常有用。反过来，从OCI目录复制到Docker仓库时，Skopeo也会自动处理格式兼容问题，基本不需要你操心。

2. 镜像洞察：不拉取镜像，也能“看透”它的老底

在决定是否使用一个镜像之前，你肯定想先了解一下它：基于什么系统？里面装了啥软件？暴露了哪些端口？环境变量怎么设置的？传统做法是 docker pull 拉下来，再 docker inspect 查看。但如果这个镜像有好几个G，或者你只是想快速确认一下版本信息，拉取整个镜像就太浪费时间了。Skopeo的 inspect 命令就是为解决这个痛点而生的，它可以直接查询远程仓库的镜像元数据，而无需下载整个镜像。

这功能在CI/CD流水线里特别实用。比如，你的流水线需要基于一个基础镜像构建应用，你可以先用 skopeo inspect 快速检查这个基础镜像的标签是否指向了预期的版本（通过Digest判断），或者看看它的创建时间，避免使用一个过于陈旧的镜像。

2.1 快速查看镜像基本信息

最基本的使用就是查看一个远程镜像的详细信息：

skopeo inspect docker://ubuntu:22.04

执行后，你会得到一份结构清晰的JSON输出，里面包含了这个镜像的“身份证信息”：

• Digest：镜像唯一的哈希值，这是镜像内容的绝对标识。标签（如 :latest）是可以移动的，但Digest永远不会变。判断两个镜像是否完全一致，就看Digest。
• Architecture 和 OS：镜像是为amd64还是arm64架构构建的？操作系统是Linux还是Windows？
• Created：镜像的创建时间，帮你判断它是不是“新鲜出炉”。
• Labels：镜像制作者打上的各种标签，比如维护者信息、许可证、版本说明等。
• Env：镜像中预设的环境变量，比如 PATH 的设置、语言环境等。
• Cmd 和 Entrypoint：容器启动时默认执行的命令。

这些信息对于评估镜像的适用性和安全性至关重要。比如，看到 Env 里设置了 JAVA_HOME，你就知道这是个Java环境镜像。

2.2 获取原始清单，进行深度分析

inspect 命令默认输出的是经过整理的、对人类友好的信息。但有些高级场景，比如你需要解析镜像的层（Layer）信息，或者需要获取完整的、原始的清单（Manifest）JSON，这时可以加上 --raw 参数：

skopeo inspect --raw docker://nginx:latest

这个命令返回的就是镜像仓库API返回的原始清单。这份清单里详细列出了镜像的所有层（layers）及其对应的摘要（digest）和大小（size）。对于做镜像安全扫描、分析镜像层优化空间，或者编写一些需要处理镜像层的自动化脚本来说，这份原始数据是必不可少的。我常用这个功能来对比同一个应用不同版本镜像的层差异，找出哪一层的变动导致了镜像体积的暴增。

2.3 结合jq工具，玩转镜像信息提取

Skopeo的输出是JSON格式，这就给了我们巨大的操作空间。配合 jq 这个命令行JSON处理神器，你可以像查数据库一样提取任何你想要的信息。

举个例子，我只想快速获取所有官方Ubuntu镜像的标签列表里，22.04这个版本的Digest是多少：

skopeo inspect --raw docker://ubuntu:22.04 | jq -r '.digest'

又比如，我想批量检查一组基础镜像的创建日期，看看有没有超过一年的“老古董”：

for image in alpine:latest nginx:stable python:3.11-slim; do
  echo -n "$image: "
  skopeo inspect docker://$image | jq -r '.Created'
done

这种组合技，能让你在自动化脚本中灵活地根据镜像元数据做出决策，极大地提升了运维效率。

3. 标签管理：摸清仓库家底，告别混乱版本

你有没有遇到过这种情况：想用某个镜像，但不确定仓库里到底有哪些版本可用？或者想清理一些旧的、临时的构建标签，却不知道从何下手？对于私有仓库的管理员来说，理清镜像标签更是一项日常且重要的工作。Skopeo提供的 list-tags 和 delete 命令，就是管理镜像标签的“瑞士军刀”。

3.1 列出所有标签，看清全貌

list-tags 命令非常简单直接，就是向指定的镜像仓库地址发起请求，列出该镜像名下所有的标签。

skopeo list-tags docker://docker.io/library/redis

运行这条命令，你会得到一个包含 latest、7.2、7.2-alpine、6.2 等所有标签的列表。这对于开发者来说，是选择合适版本的第一步。对于管理员，这是进行仓库清理和审计的基础。我习惯在清理仓库前，先用这个命令把某个项目的所有镜像标签列表导出到文件，然后再进行分析。

这里有个小技巧：很多私有仓库（如Harbor）的API路径可能和Docker Hub略有不同。如果直接使用仓库地址列表失败，可以尝试在镜像名前加上仓库的项目名。例如，在Harbor中，一个放在 myproject 项目下的 backend 镜像，其地址应该是 docker://harbor.example.com/myproject/backend。

3.2 精准删除，为仓库“瘦身”

镜像仓库不是垃圾桶，无用的镜像（比如每次CI构建产生的临时标签、已经废弃的版本）会白白占用大量的存储空间。delete 命令允许你直接删除远程仓库中的某个特定标签的镜像。但请注意，这个功能需要你的镜像仓库服务端支持Docker Registry API V2的删除操作。像Harbor、GitLab Container Registry等主流仓库都是支持的，但有些简单的Registry服务可能默认关闭此功能。

删除操作需要认证，因为这显然是个危险操作。假设我们要删除私有仓库里一个已经不再使用的测试版本：

skopeo delete \
  --creds=admin:mysecretpassword \
  docker://registry.example.com/myapp:v0.1-test

执行成功后，这个 v0.1-test 标签对应的镜像清单就会被从仓库中移除。如果这个镜像的层没有被其他标签引用，那么这些层数据也会在仓库的垃圾回收（GC）过程后被清理。

重要警告：使用 delete 命令一定要格外小心！尤其是在生产环境。我有一次误操作，差点删掉了正在使用的版本。我的经验是：

1. 先列后删：永远先用 list-tags 确认目标。
2. 使用Digest删除：标签可以被覆盖或移动，但Digest是唯一的。最精准的删除方式是使用镜像的Digest。你可以先通过 inspect 获取到要删除镜像的Digest，然后这样删除：

   skopeo delete \
     --creds=admin:password \
     docker://registry.example.com/myapp@sha256:abc123def456...
   

3. 做好备份：重要镜像在删除前，确保已经备份到其他地方。

4. 批量同步：一键搞定多镜像迁移与备份

前面说的 copy 命令很好，但一次只能操作一个镜像。当我们需要在多个环境（比如开发、测试、生产）之间同步一堆镜像，或者为整个项目组做离线镜像包时，一个个地写 copy 命令就太累了。这就是 sync 命令大显身手的时候。它可以根据一个配置文件，批量、自动化地同步大量镜像，是进行镜像仓库迁移、制作离线镜像包、搭建内网开发环境的终极利器。

4.1 编写同步配置文件

sync 命令的核心是一个YAML格式的配置文件。这个文件定义了“从哪里同步什么镜像”到“哪里”。它的结构非常直观，我举个例子你就明白了。

假设我们公司内部需要从Docker Hub同步一批常用的基础镜像到内网仓库 internal-registry.example.com，同时还要从另一个私有仓库 old-registry.corp.com 同步一些业务镜像。我们可以创建这样一个 sync-config.yaml 文件：

# sync-config.yaml
docker.io:
  images:
    # 从Docker Hub的library项目同步ubuntu镜像，只同步jammy和focal两个标签
    ubuntu:
      - jammy
      - jammy-22.04
      - focal
    # 同步alpine镜像，不指定标签则默认同步所有标签（慎用！）
    alpine:
      - latest
      - 3.19
    # 同步nginx镜像，只同步mainline和stable标签
    nginx:
      - latest
      - stable

old-registry.corp.com:
  images:
    # 从旧仓库同步项目组A的镜像，同步所有标签
    team-a/frontend:
      []
    # 同步项目组B的后端镜像，只同步v1.x系列的最新两个小版本
    team-b/backend:
      - v1.2
      - v1.1

配置文件里，顶层的键（如 docker.io, old-registry.corp.com）是源仓库地址。下面的 images 里，列出了要同步的镜像名和对应的标签列表。[] 表示同步该镜像所有标签，但这样可能会同步非常多标签，包括很多中间构建标签，通常不建议。

4.2 执行同步操作

配置文件写好之后，执行同步就一行命令的事。我们要把上述配置里的镜像，同步到内网仓库的 base-images 项目下：

skopeo sync \
  --src yaml \
  --dest docker \
  --dest-creds=internaluser:internalpass \
  sync-config.yaml \
  internal-registry.example.com/base-images

解释一下参数：

• --src yaml：指定源类型是我们的YAML配置文件。
• --dest docker：指定目标类型是Docker仓库。
• --dest-creds：提供目标仓库的认证信息。
• 最后一个参数是目标仓库的基础地址。

Skopeo会开始工作，依次读取配置文件中的每一项，将指定的镜像和标签从源仓库复制到目标仓库的对应路径下。整个过程是自动化的，你可以泡杯茶等着。这对于初始化一个新的内网环境，或者定期从外网更新基础镜像，效率提升不是一点半点。

4.3 同步到本地目录，制作离线包

另一个高频场景是制作离线部署包。我们需要把生产环境所需的所有镜像打包到一个文件夹里，带到无法连接外网的环境中使用。这时，目标（--dest）可以设置为 dir（目录）。

skopeo sync \
  --src yaml \
  --dest dir \
  ./prod-images-config.yaml \
  ./offline-images

执行后，所有镜像都会以OCI格式保存在 ./offline-images 目录下。你可以把这个目录打包成tar.gz，拷贝到内网机器上。在内网环境中，你可以再用 skopeo sync 命令，以这个目录为源（--src dir），同步到内网的私有仓库中，完成离线部署。

5. 进阶与安全操作：签名、验证与认证管理

除了基本的搬运、查看和管理，Skopeo还提供了一些进阶功能，这些功能在追求安全合规的容器化实践中变得越来越重要。

5.1 镜像签名与验证（实验性功能）

容器镜像的安全供应链越来越受重视。如何确保你拉取到的镜像，就是开发者最初构建的那个，没有被中间人篡改？镜像签名就是答案。Skopeo提供了 standalone-sign 和 standalone-verify 命令来支持简单的镜像签名验证流程。

签名：假设你有一个镜像的清单文件 myapp-manifest.json，你可以用私钥给它签名。

skopeo standalone-sign \
  ./myapp-manifest.json \
  registry.example.com/myapp:v1.0 \
  /path/to/private-key.pem \
  -o signature-file

这条命令会生成一个签名文件 signature-file。这个签名需要和镜像清单一起分发。

验证：当别人拿到你的镜像清单和签名后，可以用对应的公钥来验证。

skopeo standalone-verify \
  ./myapp-manifest.json \
  registry.example.com/myapp:v1.0 \
  sha256:$(cat ./myapp-manifest.json | jq -r '.config.digest') \
  /path/to/public-key.pub

如果验证通过，说明这个镜像清单自签名后没有被修改过。需要注意的是，这套机制是“独立”（standalone）的，它不依赖容器运行时或仓库的复杂策略。更完整的签名方案通常使用Cosign等工具，并与Notary v2等规范结合，但Skopeo提供的这个基础功能对于理解签名原理和实现简单场景很有帮助。

5.2 灵活的认证管理

与各种仓库打交道，认证是绕不开的。Skopeo提供了多种灵活的认证方式：

1. 命令行参数：最直接，但密码会暴露在历史记录中，不安全。适合临时测试。

   skopeo inspect --creds=username:password docker://private.reg/image
   

2. 环境变量：稍微安全一些，可以通过脚本设置。

   export REGISTRY_PASSWORD="mypass"
   skopeo inspect --creds=username:$REGISTRY_PASSWORD docker://private.reg/image
   

3. 认证文件：这是最推荐的生产环境方式。Skopeo可以复用Docker或Podman的认证配置文件（默认是 ~/.docker/config.json 或 ~/.config/containers/auth.json）。你只需要用 skopeo login 登录一次，凭证就会安全地存储在这个文件里。

   skopeo login --username myuser --password-stdin registry.example.com < ~/my_password.txt
   

   登录后，后续使用Skopeo命令访问这个仓库就不再需要输入密码了。skopeo logout 可以用于登出，清除本地凭证。

5.3 计算清单摘要，确保一致性

manifest-digest 是一个小巧但实用的工具。它接收一个镜像清单JSON文件，计算出其SHA256摘要。这个摘要在很多地方都会用到，比如上面验证签名时的 sha256: 参数，或者当你需要精确指定一个镜像时（用 image@sha256:abc... 的方式）。

skopeo manifest-digest ./my-manifest.json

输出就是类似 sha256:fcb2c6ac... 的字符串。在自动化脚本中，当你需要对比两个镜像清单是否完全相同时，计算并对比它们的摘要是最可靠的方法。

从我这些年的使用经验来看，Skopeo的魅力就在于它的“专”和“轻”。它不试图取代Docker或Podman，而是专注于解决容器镜像“流通”环节中的各种痛点。无论是日常开发中的镜像检查，还是大规模的生产环境仓库迁移，它都能以一种简洁高效的方式完成任务。刚开始你可能会觉得命令参数有点多，但用熟之后，你会发现它已经成了你容器工具链中那个最可靠、最不想离开的伙伴。尤其是在那些没有Docker守护进程的环境里，Skopeo就是你和容器镜像世界沟通的桥梁。