RUNBOOK / Docker
docker compose pull 失败：服务范围、依赖与镜像拉取边界
Compose 项目中某个服务拉取失败，直接执行全量 pull 时难以判断是哪个镜像或依赖发生问题。
故障现象与判断依据
最可能原因
docker compose pull 可以按服务执行且不会启动容器；先用 compose 配置确认服务镜像，再只拉取目标服务，以免把构建、启动和网络故障混在一起。
LOG$ docker compose pull db
[+] Running
⠿ db Pulling
⠿ 45b42c59be33 Already exists安全诊断
以下命令用于读取状态、验证解析或复现请求；先确认目标主机、权限与影响范围。命令中的占位符必须替换为当前环境的实际值。
READ / VERIFYdocker compose config
docker compose pull <service>
# 仅在确认 compose 文件与服务名后继续
docker pull <resolved-image>推荐修复步骤
- 1执行 docker compose config，确认目标服务的 image、依赖和当前 compose 文件来源。
- 2执行 docker compose pull <service>，先针对一个服务复现；不要用 --ignore-pull-failures 掩盖失败。
- 3对具体失败镜像单独执行 docker pull，继续区分 Registry 认证、manifest 与 layer 下载阶段。
验证、限制与回滚
修复后的验证
目标服务的 docker compose pull 成功并显示已存在或下载完成；docker compose config 输出仍指向预期镜像。
风险提示与回滚
不要以关闭证书校验、删除全部缓存、无限重试、关闭防火墙或放宽到 chmod 777 来替代根因定位。任何配置变更前先保留原文件和校验结果；若验证失败，恢复该备份并重新采集日志。
可信来源与适用边界
参考来源docker compose pull | Docker Docs ↗
pull can target a Compose service and does not start containers 此页将环境级案例与本 Runbook 的检查步骤分开呈现，不能把示例日志当作当前服务器的真实事件。
网络环境检测
当 DNS、代理链路、海外依赖源或下载超时已通过本页命令确认是网络层问题时，可继续核对独立网络服务；这不替代本地根因修复。
访问边界云官方网站 →具体套餐、价格、可用线路、服务内容及相关规则以官网当前页面为准；不会携带你在工作台输入的命令、日志、Token、IP 或邮箱。