Docker Eng — Deep Workflow
Containers package applications with their dependencies. Optimize for small, reproducible images and clear runtime contracts—not “SSH into a mini VM.”
When to Offer This Workflow
Trigger conditions:
- - Authoring Dockerfiles for apps or CI
- CVEs in base images; accidental secrets in layers
- Slow builds or oversized images pushing registry costs
Initial offer:
Use six stages: (1) base image & supply chain, (2) Dockerfile structure, (3) runtime config & secrets, (4) security hardening, (5) health & observability, (6) ops & debugging). Confirm registry and orchestrator (Kubernetes, ECS, etc.).
Stage 1: Base Image & Supply Chain
Goal: Pin tags or digests; prefer minimal bases (distroless, slim) when compatible.
Practices
- - Scan images regularly (Trivy, Grype); track SBOM where required
Stage 2: Dockerfile Structure
Goal: Multi-stage builds: compile in builder, copy only artifacts to runtime; order layers for cache hits (dependency manifests before source).
Practices
- - Maintain a robust
.dockerignore (exclude secrets, build artifacts, VCS noise)
Stage 3: Runtime Config & Secrets
Goal: Configuration via environment variables; secrets injected at runtime (K8s secrets, IAM, vault)—never COPY real secrets into the image.
Stage 4: Security Hardening
Goal: Run as non-root; read-only filesystem where possible; minimal packages in final image; avoid leaking build tools in production.
Stage 5: Health & Observability
Goal: HEALTHCHECK or orchestrator probes match real readiness (dependencies up); logs to stdout/stderr in structured form.
Stage 6: Ops & Debugging
Goal: Tag images with git SHA; document how to exec/debug (or use debug sidecars for distroless).
Final Review Checklist
- - [ ] Base image pinned and scanned
- [ ] Multi-stage build; minimal runtime layer
- [ ] No secrets in layers
- [ ] Non-root and least privilege
- [ ] Health/readiness aligned with app
- [ ] .dockerignore and reproducible builds
Tips for Effective Guidance
- - Explain layer caching order—why
COPY package.json before COPY . matters. - Distroless images: no shell—use ephemeral debug containers or sidecars.
Handling Deviations
- - Windows containers: different paths and base images—validate separately.
Docker Eng — 深度工作流
容器将应用程序及其依赖项打包。优化目标是小巧、可复现的镜像以及清晰的运行时契约——而不是“SSH进一个迷你虚拟机”。
何时提供此工作流
触发条件:
- - 为应用或CI编写Dockerfile
- 基础镜像中存在CVE漏洞;层中意外包含密钥
- 构建缓慢或镜像过大导致注册表成本增加
初始提供:
使用六个阶段:(1) 基础镜像与供应链,(2) Dockerfile结构,(3) 运行时配置与密钥,(4) 安全加固,(5) 健康与可观测性,(6) 运维与调试。确认注册表和编排器(Kubernetes、ECS等)。
阶段1:基础镜像与供应链
目标: 固定标签或摘要;兼容时优先选择最小基础镜像(distroless、slim)。
实践
- - 定期扫描镜像(Trivy、Grype);必要时追踪SBOM
阶段2:Dockerfile结构
目标: 多阶段构建:在构建阶段编译,仅将产物复制到运行时;按缓存命中顺序排列层(依赖清单放在源码之前)。
实践
- - 维护健壮的.dockerignore(排除密钥、构建产物、版本控制噪声)
阶段3:运行时配置与密钥
目标: 通过环境变量进行配置;密钥在运行时注入(K8s密钥、IAM、保险库)——切勿将真实密钥COPY到镜像中。
阶段4:安全加固
目标: 以非root用户运行;尽可能使用只读文件系统;最终镜像中最小化软件包;避免在生产环境中泄露构建工具。
阶段5:健康与可观测性
目标: HEALTHCHECK或编排器探针匹配真实就绪状态(依赖项已就绪);日志以结构化形式输出到stdout/stderr。
阶段6:运维与调试
目标: 使用git SHA标记镜像;记录如何执行/调试(或为distroless镜像使用调试sidecar)。
最终审查清单
- - [ ] 基础镜像已固定并扫描
- [ ] 多阶段构建;最小化运行时层
- [ ] 层中无密钥
- [ ] 非root且最小权限
- [ ] 健康/就绪状态与应用对齐
- [ ] .dockerignore和可复现构建
有效指导技巧
- - 解释层缓存顺序——为什么先COPY package.json再COPY .很重要。
- Distroless镜像:无shell——使用临时调试容器或sidecar。
处理偏差
- - Windows容器:不同的路径和基础镜像——需单独验证。