容器技术已经彻底改变了现代软件的交付方式，但仅仅会用docker run和docker build并不足以发挥它的全部威力。许多团队在拥抱Docker后反而遇到镜像体积臃肿、构建速度缓慢、安全漏洞频发乃至运行时性能不佳等问题。这些困境的根源，往往在于没有遵循一套系统化的实践准则。本文从镜像构建、运行时配置到安全与可观测性，梳理出真正值得落地的Docker最佳实践，帮助你打造更轻、更快、更稳的容器化应用。
一、把镜像做小，是对自己和基础设施的双重善待
镜像体积直接影响拉取速度、磁盘占用和启动时间。最好的第一步是使用精简的基础镜像，Alpine和Distroless都是常见选择。Alpine体积小且包管理方便，但需要注意其基于musl libc，某些二进制可能与glibc不兼容；Distroless镜像几乎不含任何shell和包管理器，能显著降低攻击面，但排障时也缺少工具。根据你的应用运行时特性做取舍，而不是盲目追求最小。
第二个关键是善用.dockerignore文件。将.git、node_modules、target、__pycache__等无关目录排除在构建上下文之外，不仅缩小传输到守护进程的数据量，也避免缓存失效和敏感信息意外打入镜像。很多团队明明有几十MB的上下文，却因为忽略了这一行文件导致每次构建都像在用拨号网络。
二、采用多阶段构建，让最终产物只有“需要的”
多阶段构建是当前最值得推荐的最佳实践之一。它允许你在同一个Dockerfile中使用多个FROM指令，将编译环境与运行环境彻底分离。例如，编译一个Go程序时，第一阶段使用golang镜像完成代码编译，第二阶段从scratch或alpine复制出二进制文件而已。这样最终的镜像只包含运行时依赖，没有编译器、源代码和临时文件。对于Python或Node应用，同样可以把依赖安装阶段与运行阶段拆开，利用虚拟环境或node_modules的精确拷贝，避免携带缓存和无用包。
三、利用层缓存机制，合理地排列指令顺序
Dockerfile中的每条指令都会产生一层缓存，但只有当指令本身和上下文未变化时，缓存才会命中。因此，应当把更新频率最低的操作放在最前面，把变化最快的内容放到最后。比如先复制requirements.txt或package.json，执行依赖安装，再复制源代码。这样，只要依赖文件不变，即使源码频繁修改，依赖层也能直接命中缓存，构建速度能提升一个数量级。相反，如果把COPY .写在前，任何文件变动都会使后续所有层全部失效，代价极大。
还要避免在一个RUN指令中执行apt-get update和install时忘记清理缓存，这会平白增加几十MB的层体积。正确做法是在同一层内安装必要软件包后，立即删除/var/lib/apt/lists/下的缓存文件。
四、安全防线：非root用户、只读根文件系统与镜像扫描
默认情况下，容器以root身份运行，这本身就违背了最小权限原则。一个被攻破的进程很容易获得宿主机的根权限逃逸入口。最佳实践是在镜像中创建专用用户，并设置USER指令，确保容器进程使用非root身份。同时，在docker run时配合–read-only挂载根文件系统，再把临时写入的目录（如/tmp、/var/run）单独挂载为可写卷。这样即使攻击者拿到shell，也无法篡改系统二进制或持久化破坏。
此外，定期使用trivy、grype等工具扫描镜像中的漏洞，只拉取并固定官方镜像的sha256摘要或精确版本标签，避免使用latest。在CI流水线中集成扫描，一旦发现高危漏洞就阻止发布，这是防止供应链攻击的关键防线。
五、声明运行时的资源边界与健康检查
容器不是虚拟机，它应该被当作一种受约束的进程。在docker run或编排平台中显式设置内存上限、CPU份额和swap大小，可以防止某个失控的容器拖垮整个主机。同样重要的还有HEALTHCHECK指令。为应用定义真实的健康探测接口（如/healthz），Docker会根据探测结果决定容器是否处于unhealthy状态，调度器也能据此自动重启或替换。相比依赖进程是否存活，这个信号更反映业务可用性。
六、日志与可观测性：让容器“说人话”
容器内的进程应将日志输出到标准输出和标准错误，而不是写入文件。Docker会统一捕获这些流，并提供给docker logs或日志采集代理。如果应用文件系统是只读的，写文件也根本行不通。最佳实践是采用JSON格式的日志，并附带请求ID、时间戳和级别，方便后续汇聚到ELK或Loki。另外，不要只依赖docker logs，建议在容器内暴露Prometheus指标端点，配合采集器形成完整的可观测性闭环。
七、把容器当作不可变基础设施的一部分
最后一个重要实践是改变思维模式。容器一旦启动，就不应该通过进入容器修补代码或安装额外工具来“事后补救”。一切变更都应基于新的镜像构建与重新部署。配合蓝绿发布或金丝雀发布，可以迅速回滚到旧版本。这种不可变性使得环境一致性成为现实：开发、测试、生产运行的是完全相同的工件，不再有“在我机器上明明能跑”的尴尬。
最终，Docker最佳实践不是一套冰冷的规则，而是一种平衡艺术。你需要根据应用类型、团队规模和基础设施状况做出合理的取舍。以小镜像为目标，用多阶段构建清理杂质，靠缓存策略提速，按最小权限原则加固安全，并让资源限制与健康检查成为默认配置，再辅以结构化日志和指标监控——这样构建出的容器，不仅轻巧高效，而且稳定可靠。当你正确执行这些实践时，Docker就不再只是一个打包工具，而是驱动整个交付流程顺畅运转的引擎，帮助团队更自信地应对每一次迭代与深夜发布。
