docker pull 是干什么的
docker pull 从镜像仓库把镜像下载到本地：默认走 Docker Hub，也可以在镜像名前带仓库地址来指定私有仓库。生产环境的做法是固定具体版本标签，必要时用摘要锁定内容，避免同一份编排文件在不同时间拉到不同版本的镜像，导致故障无法复现。
基本信息
| 基本语法 | docker pull [仓库地址/]仓库名[:标签|@摘要] |
|---|---|
| 默认行为 | 不带标签时拉取 latest，内容会随上游更新而变化 |
| 多架构 | 多平台镜像可用 --platform 指定目标架构，如 linux/amd64 |
| 加速方式 | 国内环境常配置镜像加速地址，写在守护进程配置里并重启生效 |
| 认证 | 私有仓库需要先 docker login，凭据保存在本地配置文件中 |
| 离线场景 | 内网环境可先把镜像导出为文件，再在目标机器导入 |
典型使用场景
- 部署前预热：在目标机器上先拉好镜像，避免发布时集中拉取拖慢整体进度
- 升级前验证：拉取新版本镜像并本地试跑，确认启动正常再切流量
- 构建基础镜像：先把基础镜像拉到本地，缩短构建阶段等待时间
- 跨架构部署：为 ARM 机器指定平台参数，避免拉起后报格式错误
- 离线交付：在能联网的机器拉取后导出，交付到无外网的环境导入
- 固定版本：用摘要锁定镜像内容，保证多环境使用的镜像完全一致
标签与引用方式
| 写法 | 含义 | 适用场景 |
|---|---|---|
| nginx | 等价于 nginx:latest | 本地试验，不建议上生产 |
| nginx:1.27 | 固定版本标签 | 生产部署的常规做法 |
| nginx:1.27-alpine | 固定版本加变体 | 对镜像体积有要求时使用 |
| 名称@sha256 摘要 | 按内容摘要锁定 | 对一致性要求最严格的场景 |
| registry 域名/命名空间/名称 | 指向私有仓库 | 内部服务统一用这种方式 |
拉取示例
拉取示例
docker pull nginx:1.27 # 拉取固定版本
docker pull --platform linux/amd64 nginx:1.27 # 指定架构
docker pull registry.example.com/team/app:1.0.0 # 私有仓库
docker pull registry.example.com/team/app@sha256:abcdef # 摘要锁定
docker images --format "{{.Repository}}:{{.Tag}} {{.Size}}" # 确认拉取结果生产环境不要用 latest：同一份编排文件在不同机器、不同时间拉到的可能是不同版本，出问题时无法复现，回滚也失去基准。
拉取失败先分清原因：认证失败要检查登录状态与仓库权限，超时或连接被拒通常是网络与加速配置问题，找不到标签则是标签名或仓库路径写错。
镜像分层下载：多个镜像共享的基础层已存在时只拉缺失的层，这也是把基础镜像统一到少数几个版本更省时间与磁盘的原因。
内网机器无法直连公网仓库时，常见做法是搭一个内部镜像仓库做代理缓存，既解决拉取问题也统一了镜像来源。
发布前的镜像准备
- 提前在目标机器拉取镜像，避免发布窗口被下载时间占用
- 拉取完成后核对镜像标识，确认与流水线产出的是同一份内容
- 多架构场景确认平台参数，架构不符会在启动阶段直接失败
- 内网环境准备内部仓库或代理缓存，减少对外网的直接依赖
- 定期清理无用镜像，避免磁盘被历史版本逐步占满
- 为关键服务保留上一个可用版本的镜像，回退时无需重新构建
把镜像预拉取放进发布流程的前置步骤：发布窗口只用于验证与切换，整体节奏会明显更可控。