docker镜像交付标准三步是构建、打标签、推送至私有仓库，需注重命名规范、安全配置和环境适配：构建用多阶段与slim基础镜像；标签用语义化版本+git哈希；推送前需登录、配置非安全仓库、重命名镜像并验证拉取与元数据。
构建、打标签、推送至私有仓库是 Docker 镜像交付的标准三步。关键不在命令本身，而在每一步的命名规范、安全配置和环境适配是否到位。
构建镜像：从 Dockerfile 到可运行镜像
构建前确保 Dockerfile 语义清晰、分层合理，避免在最后阶段安装运行时依赖导致镜像体积膨胀。
- 使用多阶段构建（multi-stage）分离编译环境与运行环境，例如 Go 或 Java 项目中将 build 阶段与 final 阶段解耦
- 基础镜像优先选 slim 或 alpine 变体（如 python:3.11-slim），但需验证兼容性，避免因缺失 libc 等导致运行失败
- 构建命令建议显式指定上下文路径与标签，避免隐式行为：
docker build -t myapp:dev -f ./Dockerfile .
打标签：让镜像具备可识别性与可追溯性
标签不是随意后缀，而是部署策略和治理规则的体现。不加标签或滥用 latest 会破坏版本一致性。
- 推荐组合使用语义化版本 + Git 提交短哈希，例如：
myapp:v1.2.0-git-abc123 - 私有仓库推送前必须重命名镜像，使其符合目标仓库地址格式：
docker tag myapp:v1.2.0 192.168.200.129:5000/myapp:v1.2.0 - 若仓库启用了内容信任（Docker Content Trust），需提前启用：
export DOCKER_CONTENT_TRUST=1
推送至私有仓库：认证、信任与网络配置
推送失败常因三类问题：未登录、地址不被信任、镜像名格式错误。其中“不被信任”最易被忽略。
- 先完成登录：
docker login 192.168.200.129:5000 --username=admin --password-stdin
密码建议通过管道传入，避免明文留在历史记录中 - 若私有仓库未启用 HTTPS，需在
/etc/docker/daemon.json中声明非安全注册表：
"insecure-registries": ["192.168.200.129:5000"]
修改后必须重启 Docker：systemctl restart docker - 推送命令仅作用于已标记的镜像名：
docker push 192.168.200.129:5000/myapp:v1.2.0
验证与调试：推送后必做的两件事
推送成功不代表可用。应立即验证拉取行为与镜像完整性。
- 在另一台机器或容器内执行拉取测试：
docker pull 192.168.200.129:5000/myapp:v1.2.0 - 检查镜像元数据是否完整：
docker inspect 192.168.200.129:5000/myapp:v1.2.0 | grep -E "(RepoTags|Created)" - 访问仓库健康接口确认服务状态：
curl -X GET http://192.168.200.129:5000/v2/_catalog
