docker push 是干什么的
推送镜像到远程仓库分三步：先登录仓库，再把本地镜像按仓库地址、命名空间、名称与标签重新打标，最后推送。镜像名里必须带仓库地址，否则会被当成默认公共仓库的路径而拒绝；集群拉取私有镜像还需要在配置里提供仓库凭据。
基本信息
| 基本流程 | 登录仓库，重新打标到目标地址，再推送 |
|---|---|
| 命名格式 | 仓库地址、命名空间、应用名与标签四部分完整写清 |
| 认证 | 登录凭据保存在本机配置文件中，流水线里用密钥注入 |
| 集群拉取 | 工作负载需要引用仓库凭据才能拉取私有镜像 |
| 标签策略 | 同时推语义版本与提交短标识，便于回溯 |
| 体积影响 | 推送按层上传，已存在的层会被跳过 |
典型使用场景
- 流水线交付：构建后推送镜像，部署过程从仓库拉取
- 跨环境分发：测试通过的镜像统一推到仓库，各环境按同一标签拉取
- 团队共享基础镜像：把统一的基础环境镜像推上去，避免各人重复构建
- 版本归档：为每次发布保留不可变标签，回滚时有确定的镜像可用
- 离线环境准备：先在可联网环境推送，再由内网仓库同步
- 多架构发布：把不同架构的镜像推到同一标签下供不同机器拉取
常见报错与原因
| 报错 | 原因 | 处理方式 |
|---|---|---|
| 无权限访问 | 未登录或账号缺少仓库写权限 | 重新登录并确认权限范围 |
| 仓库不存在 | 命名空间或仓库名写错，且未开启自动创建 | 核对地址或先在仓库侧创建 |
| 标签被拒绝 | 目标仓库启用了不可变标签策略 | 改用新版本号，不要覆盖历史标签 |
| 连接超时 | 网络或仓库地址不可达 | 确认地址与网络策略 |
| 层上传中断 | 网络不稳定或镜像过大 | 重试，必要时精简镜像层 |
完整推送流程
完整推送流程
docker login registry.example.com # 登录仓库
docker tag myapp:1.0.0 registry.example.com/ns/myapp:1.0.0 # 打标到目标地址
docker push registry.example.com/ns/myapp:1.0.0 # 推送
docker push registry.example.com/ns/myapp:1.0.0-abc1234 # 同时推提交标识
# 集群侧需要提供仓库凭据才能拉取私有镜像流水线里不要把仓库密码打印到日志：使用注入的凭据文件或专用凭据机制，日志一旦被保存，密码就等于长期泄露。
同时推语义版本与提交短标识：前者便于人读与回滚，后者便于精确定位到某次提交构建出的镜像。
覆盖已有标签会让生产环境在无感知的情况下换掉镜像内容：重要环境应使用不可变标签或按摘要引用。
推送是按层上传：基础层已存在于仓库时只上传变化层，这也是统一基础镜像版本能显著缩短流水线时间的原因。