容器技术早已从“新鲜玩具”演变为生产环境的中流砥柱，但许多团队在使用Docker时仍停留在“能跑就行”的阶段。镜像体积臃肿、构建缓存失效、权限过度开放、日志丢失……这些问题在微服务架构中会被无限放大。本文将结合真实生产环境经验，总结九条经过验证的Docker最佳实践，帮助你构建更轻、更快、更安全的容器化应用。
一、镜像瘦身：每一兆都是成本
基础镜像的选择直接决定了下限。Alpine Linux凭借其5MB左右的体积成为热门选择，但要注意其musl libc与glibc的差异可能引发兼容性问题。更稳妥的做法是使用distroless镜像——它们只包含运行时依赖，连shell都没有，攻击面大幅缩小。若追求极致，甚至可以尝试从零构建静态二进制镜像。
多阶段构建是必须掌握的技能。在builder阶段安装完整工具链，编译完成后仅将产物复制到运行阶段。以Go应用为例，构建阶段使用golang:1.22，运行阶段使用alpine，最终镜像能从800MB降到20MB。关键点在于：每一条RUN指令都会产生新层，将频繁变化的代码放在Dockerfile末尾，利用层缓存加速迭代。
二、构建优化：缓存是隐形加速器
依赖层与源码层必须分离。将package.json、requirements.txt等依赖清单文件先COPY进镜像，执行依赖安装，再COPY源码。这样当源码变更时，依赖层缓存依然有效。对于npm项目，建议使用npm ci替代npm install，前者严格遵循锁文件，构建结果可复现。
. dockerignore文件的重要性不亚于.gitignore。node_modules、dist、.git等目录若不排除，每次构建都会打包进上下文，不仅拖慢构建速度，还可能覆盖镜像内的正确文件。记住：构建上下文越大，缓存命中率越低。
三、安全加固：容器不是虚拟机
永远不要以root用户运行容器。在Dockerfile末尾添加USER指令，创建专用用户并赋予最小权限。对于需要绑定低端口（如80）的场景，使用setcap赋予特定能力，而非直接切换root。同时，将文件系统挂载为只读（read_only: true），仅对需要写入的目录（如/tmp）单独挂载tmpfs。
镜像扫描应纳入CI流程。Trivy或Grype可以检测已知漏洞，但要注意：Alpine的apk包管理器的漏洞数据库覆盖度有限，对于高安全要求的环境，建议使用Ubuntu或Debian作为基础镜像，并定期执行基础镜像更新。
四、运行时配置：资源限制是保命符
未设置内存限制的容器就像没有刹车的汽车。在docker-compose或Kubernetes中明确设置mem_limit和cpus，防止某个服务的内存泄漏拖垮整个宿主机。JVM应用尤其需要关注：容器内默认的堆大小可能远大于容器限制，务必使用-XX:MaxRAMPercentage=75.0这类比例参数。
优雅停机是生产环境的硬性要求。主进程必须接收SIGTERM信号并完成清理工作。Node.js应用需要自行处理signal事件，Spring Boot则默认支持。配合STOPSIGNAL指令和stop_grace_period，确保容器能在超时前退出，避免强制kill导致的数据损坏。
五、可观测性：日志与健康检查
容器内的日志应输出到stdout/stderr，由日志驱动统一收集，不要写文件。JSON-file驱动默认无大小限制，务必配置max-size和max-file轮转策略。更推荐使用docker logging plugin接入ELK或Loki，但要注意异步写入对性能的影响。
健康检查不能只测端口连通性。使用HEALTHCHECK指令执行实际业务探活，例如检查数据库连接池是否可用。在Kubernetes中，livenessProbe与readinessProbe要区分：前者决定是否重启，后者控制流量分发。错误的探针配置会导致滚动更新期间的服务中断。
六、网络与存储：默认桥接是陷阱
容器间通信应使用自定义网络，而非默认的bridge。自定义网络提供内置DNS解析，服务名即可作为主机名，避免IP变动带来的配置灾难。不要使用–link，它已被官方标记为遗留功能。
持久化数据必须使用volume而非容器层。具名volume（named volume）比bind mount更安全，因为前者由Docker管理权限。但需要注意：MySQL、PostgreSQL等数据库容器，数据目录的权限设置（如–user 999:999）必须与镜像内UID匹配，否则启动即崩溃。
七、构建与部署的自动化哲学
Dockerfile的每条指令都应有明确注释，尤其是那些看似“魔法”的参数。使用BuildKit特性（如–mount=type=cache）可以加速包管理器的缓存复用，但需要前端构建工具支持。对于多架构部署，使用docker buildx构建amd64/arm64联合镜像，避免在树莓派上重新编译。
镜像标签的规范直接决定回滚效率。生产环境禁用latest标签，采用git commit SHA作为唯一标识。配合GitHub Actions或GitLab CI，实现“代码推送→自动构建→安全扫描→推送仓库→触发部署”的全链路自动化。
八、避免常见反模式
不要在容器内运行多个进程。使用supervisor或systemd看似方便，但增加了信号处理复杂度，且难以单独监控每个进程的资源消耗。若确实需要，考虑拆分为多个容器通过内部网络协作。
不要直接修改运行中容器的文件。容器是不可变基础设施，任何变更都应通过重新构建镜像完成。调试时使用docker exec进入容器没问题，但临时安装的包会在容器重建后丢失，这恰恰是正确行为。
九、监控与迭代：最佳实践是动态的
容器化不是终点，而是持续优化的起点。使用cAdvisor或Prometheus监控容器指标，设定CPU、内存的告警阈值。定期审视镜像中是否存在过时的依赖版本，关注Docker官方安全公告。每半年评估一次基础镜像的更新，因为工具链和漏洞库都在快速演进。
总结这九条实践，核心思想可以归结为三点：最小化（镜像体积、权限、攻击面）、可观测（日志、健康、资源）、自动化（构建、扫描、部署）。容器技术的魅力在于它提供了标准化的封装，但标准化不等于一刀切——根据业务场景调整这些原则，例如机器学习训练任务可能需要大内存和GPU，而边缘计算设备则更关注镜像体积。
最后提醒一点：最佳实践是团队协作的产物。让每位开发者在本地就能运行与生产环境一致的容器，通过docker-compose搭建开发环境，通过Kubernetes管理生产负载。当容器变得“无聊”时——一切稳定运行，无需人工干预——你就真正掌握了Docker的精髓。
