Docker镜像打包规范是一套围绕可复现、可维护、可安全交付目标的工程实践共识。核心要求包括：Dockerfile统一命名与位置；基础镜像禁用latest并显式指定版本；合理分层以利用缓存；非root用户运行；显式声明EXPOSE和HEALTHCHECK；仓库名小写短横线、标签语义化且禁用latest；离线分发用docker save并校验sha256；CI中集成漏洞扫描，镜像签名后启用内容信任，敏感信息不得硬编码。
镜像构建阶段的规范要点
这是规范的起点，决定镜像内容是否可靠：
-
Dockerfile 必须放在项目根目录或明确路径下，且文件名统一为
Dockerfile（无后缀），避免使用-f指定路径带来的歧义。 -
基础镜像需明确版本号，禁用
:latest。例如用python:3.11-slim-bookworm而非python:latest，确保底层系统和依赖可锁定。 -
分层指令顺序要合理：把变动少的放前面（如
FROM、RUN apt-get update && apt-get install），变动多的放后面（如COPY . .），充分利用构建缓存。 -
禁止在容器内以 root 运行应用，应在 Dockerfile 中添加
user nobody或自定义非特权用户，并确保工作目录权限适配。 -
显式声明暴露端口与健康检查：用
EXPOSE 8080和HEALTHCHECK --interval=30s CMD curl -f http://localhost:8080/health || exit 1，便于编排工具识别。
镜像命名与标签管理规范
名字和标签是镜像的“身份证”，直接影响部署准确性和追踪能力：
-
仓库名（repository）采用小写字母+短横线，如
myapp-backend，避免下划线或大写；团队级镜像建议加前缀，如corp/myapp-backend。 -
标签（tag）必须语义化：生产环境只允许使用
vX.Y.Z（符合 SemVer）、git-commit-hash（如a1b2c3d）或build-timestamp（如20260729-1430），禁用latest用于正式发布。 -
一个镜像可打多个标签，例如构建后同时打
v1.2.0、a1b2c3d、20260729-1430，但禁止用不同标签指向不同内容。
打包与分发环节的操作规范
涉及镜像导出、传输、加载，重点在完整性与可验证性：
-
离线分发必须用
docker save -o xxx.tar，而非docker export（后者只导出容器文件系统，丢失元数据和层结构）。 -
tar 包命名需含镜像名+标签+时间戳，如
myapp-backend-v1.2.0-20260729.tar，便于溯源。 -
若需压缩，统一用
gzip（docker save image:v1 | gzip > image-v1.tar.gz），不推荐xz或zstd—— 兼容性优先。 -
加载前应校验 tar 包完整性：接收方执行
sha256sum myapp-backend-v1.2.0-20260729.tar并与发送方提供的 checksum 对比。
安全与审计配套要求
规范若不带安全钩子，容易流于形式：
- 所有镜像构建必须经过扫描：CI 流程中集成 Trivy 或 Grype，阻断含高危 CVE 的镜像推送。
-
镜像签名是上线前提：使用 Cosign 或 Notary v2 对推送至私有 registry 的镜像签名，部署时启用
DOCKER_CONTENT_TRUST=1校验。 -
敏感信息绝不硬编码：配置通过
ENV+ 启动时注入（如docker run -e DB_URL=...），或挂载 secret 文件，Dockerfile 中不出现密钥、token。
