docker镜像生命周期管理核心是拉取、构建、存储、分发、清理五环节闭环。需管控来源可信度、强制语义化标签或digest、采用多阶段构建优化分层、规范标签策略、定期清理悬空及过期镜像，并支持签名与备份。
Docker 镜像生命周期管理，核心是围绕“拉取 → 构建 → 存储 → 分发 → 清理”五个环节形成闭环，不是只管 build 和 push，而是让每个镜像从诞生到退役都有据可查、可控可溯。
拉取与来源管控
避免盲目 pull latest，优先明确镜像来源和可信度：
- 区分官方镜像（如 nginx）、认证发布者（如 bitnami/nginx）和社区镜像，生产环境禁用未经验证的社区镜像
- 统一配置镜像加速器（尤其国内网络），并在 CI/CD 中预设私有仓库白名单
- 拉取时强制指定语义化标签或 digest（如
nginx@sha256:abc...），杜绝版本漂移 - 多架构场景下使用
--platform linux/arm64显式声明，避免运行时报错
构建与分层优化
构建阶段决定镜像质量与后续维护成本：
- 采用多阶段构建：分离编译环境与运行环境，最终镜像体积可减少 60% 以上
- 合理排序 Dockerfile 指令——基础依赖前置、变动频繁内容后置，提升缓存命中率
- 每条 RUN 指令尽量合并操作并清理临时文件（如
&& rm -rf /var/lib/apt/lists/*） - 禁用
docker build --no-cache除非必要，日常构建应依赖层缓存加速
标签与版本治理
标签不是随意命名的别名，而是关键的版本控制锚点：
- 主版本必须使用语义化标签（如 v1.4.2），且不可覆盖；同一镜像 ID 可绑定多个标签
- 按环境打标：例如
myapp:v1.4.2（生产）、myapp:dev-1.4.2-abc123（对应 Git commit） - 避免在生产流程中出现
latest，它只适合本地快速验证或开发流水线末端 - 结合 cosign 或 Notary 对关键镜像签名，校验完整性与来源可信度
存储与清理策略
本地镜像堆积会拖慢构建、占用磁盘、干扰排查：
- 定期执行
docker image prune -a --filter "until=168h"删除一周前未使用的镜像 - 悬空镜像（dangling）用
docker image prune单独清理，不影响正在运行的容器 - 导出关键镜像备份：
docker save nginx:1.25 | gzip > nginx-1.25.tar.gz - 确认使用
overlay2存储驱动（Docker 默认），避免老旧的 aufs 或 devicemapper
