2.3 镜像基础操作：进港提货
2.3 镜像基础操作：进港提货
本节摘要：围绕堆场的四个动作展开——找货（search）、提货（pull）、验货（inspect）、清仓（rmi），并讲透镜像全名的三段式语法。本节是第 3 章镜像体系的入口，学完你就能把任何公开镜像安全地提回本地。
提货之前，先看懂货单
操作规程背熟了，现在去堆场办第一笔正式业务。去堆场提货，先得看懂货单——镜像的完整名称。很多人第一次 pull 就栽在名称语法上，所以本节从"读名字"开始。
一个镜像的完整名称由三段构成：
仓库地址/命名空间/镜像名:标签 <registry address>/<namespace>/<repo>:<tag> 例一：docker.io/library/nginx:1.25-alpine ^^^^^^^^^ ^^^^^^^^^ ^^^^^ ^^^^^^^^^^ 默认堆场 官方空间 货名 标签（版本加变体） 例二：registry.example.com/shop/order-api:1.4.2 自建堆场 企业空间 货名 精确版本标签
三个高频疑问直接给出答案。其一，为什么有时写 nginx 也能拉——省略的部分会补默认值：仓库地址默认 docker.io（Docker Hub），命名空间默认 library（官方镜像专属空间），标签默认 latest。其二，latest 不代表"最新版"，它只是个普通标签名，谁都可以把旧版本标成 latest——生产环境永远用精确版本标签，这是本节最重要的一句话。其三，真正的唯一指纹是内容摘要（以 sha256 开头的一长串），标签会漂移、摘要不会。
四个动作逐一上工
找货：search。 不知道货名时先搜：
# 在公共堆场搜索关键词（输出节选） docker search nginx # NAME DESCRIPTION STARS OFFICIAL # nginx NGINX 源码构建的官方镜像 20000+ [OK] # bitnami/nginx Bitnami 打包的 nginx 200+ # nginx/nginx-ingress 入口控制器镜像 100+
看三列：NAME 是否来自官方空间、STARS 人气、OFFICIAL 是否官方认证。选型建议：基础软件优先官方镜像，衍生需求再看维护活跃的第三方打包。
提货：pull。 指定版本标签提货，这是日常最高频的动作：
# 提一个精确版本的 nginx 镜像（alpine 变体，体积小） docker pull nginx:1.25-alpine # 1.25-alpine: Pull from library/nginx # a480a496ba95: Pull complete <- 逐层下载，每行一层 # f3ace1fa8c9d: Pull complete # Digest: sha256:0423b3e07c628fd54ba6a5b1e79d0f2e2f3d4c9a2b3c1d0e9f8a7b6c5d4e3f2a # Status: Downloaded newer image for nginx:1.25-alpine
注意输出里的两处细节：逐行的 "Pull complete" 是分层下载——镜像不是一坨整体，而是一层一层提回来的（第 3 章深挖）；Digest 行是这次实际提到的货的内容摘要，记下它，日后可凭摘要原样提回完全相同的货。
验货：inspect 与 images。 货到入库，先验后用：
# 本地库存清单 docker images # REPOSITORY TAG IMAGE ID CREATED SIZE # nginx 1.25-alpine 0c7ba8a3f7e2 3 weeks ago 71.8MB # 查看某批货的详细档案：暴露端口、默认启动命令、架构 docker inspect nginx:1.25-alpine --format "架构: {{.Architecture}} | 暴露端口: {{.Config.ExposedPorts}}" # 输出示例：架构: amd64 | 暴露端口: map[80/tcp:{}]
那个 IMAGE ID 是本地库存的唯一编号，SIZE 是磁盘占用。注意 alpine 变体只有几十 MB——同一个软件的镜像变体体积可以差几倍，选型时值得留意（第 3 章专门讲瘦身）。
清仓：rmi。 退掉不要的货，释放堆位：
# 按名称:标签删除 docker rmi nginx:1.25-alpine # Untagged: nginx:1.25-alpine # Deleted: sha256:abc123... <- 删除的是本层独有的数据 # 有容器还在使用该镜像时会被拒绝（错误示例） # Error response from daemon: conflict: unable to remove repository reference # （先删干净引用它的容器，或用 -f 强删——强删只是摘标签，数据层还有人在用就不动）
内网提速：给堆场配个中转仓
身处网络受限环境的读者，直连公共堆场常常超时。解法是配置镜像加速器：让引擎优先从就近的中转仓提货。修改引擎配置文件后重启引擎生效：
引擎配置（daemon.json）中增加一段： { "registry-mirrors": [ "https://<你申请到的加速地址>.mirror.aliyuncs.com", "https://docker.m.daocloud.io" ] }
# 修改配置后重启引擎（Linux） sudo systemctl restart docker # 验证加速器已生效 docker info | grep -A 3 "Registry Mirrors"
中转仓只是缓存：公共堆场上的货它原样转发，内容摘要不变，因此不影响"凭摘要提货"的可靠性。企业内网更彻底的做法是自建私有堆场，第 3.5 节会亲手搭一个。
本节末尾留一个观察题，检验你对分层下载的理解：把同一个镜像的标签删掉重拉（先 rmi 再 pull 不同的标签），注意输出里大量 "Already exists" 与个别 "Pull complete" 的组合——前者是本地已有的共享层直接复用，后者才是真正下载的新层。看懂了这行输出，你就理解了为什么同一台机器上的几十个镜像只占一份基础底座的空间，也为第 3 章的分层原理提前铺好了直觉。
本节要点回顾
- 镜像全名三段式：仓库地址/命名空间/镜像名:标签；缺省补默认（docker.io、library、latest）。
- latest 只是普通标签，不是"最新"承诺；生产用精确版本标签，可复现用内容摘要。
- 四个动作：search 找货、pull 分层提货、inspect 验货、rmi 清仓；镜像被容器引用时清仓会被拒。
- 镜像是分层下载的——输出里每行 Pull complete 对应一层，这是第 3 章的伏笔。
- 网络受限时配镜像加速器，重启引擎生效；加速器不改变内容摘要。
货提回来了，下一节把它吊起来——你的第一次正式起吊。