贝壳主机网
注意：部分文章发布时间较长，可能存在未知因素，购买时建议在本站搜索商家名称，先充分了解商家动态。
交流：唯一投稿邮箱：hostvps@88.com。
Docker如今已经成为云原生时代的基础设施，几乎每位后端工程师都在使用容器打包应用。然而，很多人把Dockerfile写成了“可以运行”的脚本，忽略了镜像体积、安全性、可维护性等关键维度。结果就是构建慢、部署慢、漏洞多、排障难。想要真正驾驭容器，必须理解并践行一套成熟的Docker最佳实践。下面这十条黄金法则，能够帮助你在生产环境中构建出更小、更稳、更安全的容器化应用。
一、镜像瘦身，从多阶段构建开始
初学者最常见的做法是把编译环境和运行环境放在同一个镜像里，导致一个Java或者Node项目镜像动辄上GB。最佳实践是使用多阶段构建：第一个阶段安装依赖、编译代码，第二个阶段只拷贝运行时所需的产物。例如，Golang应用可以先用golang:1.21编译二进制，再将它拷贝到alpine基础镜像中。这样镜像体积可能从800MB降到20MB，攻击面也随之大幅缩小。多阶段构建不仅加快了镜像拉取速度，还降低了存储和带宽成本，是容器化改造必须迈出的第一步。
二、善用.dockerignore，别把敏感文件带进上下文
构建镜像时，Docker会将当前目录的全部文件发送到守护进程作为构建上下文。如果缺少.dockerignore，包含node_modules、target、.git、.env等目录和文件都会被无谓地打包并可能泄露密钥。最佳实践是像使用.gitignore一样维护.dockerignore，至少排除版本控制目录、临时文件、日志、本地依赖和密钥文件。这不仅能加快构建速度，还能避免将数据库密码或云服务凭证意外烧录进镜像层。
三、合并RUN指令，减少镜像层数
每个RUN、COPY、ADD指令都会生成一个新的镜像层。为了利用缓存，很多人喜欢一条指令装一个包，结果产生大量无意义的层并占用更多存储空间。最佳实践是将相关的APT或yum安装命令合并到一个RUN中，并且在同一层里完成安装、清理缓存和删除临时文件。比如在执行apt-get install后立即执行rm -rf /var/lib/apt/lists/*，这样不会把包索引文件留在镜像里。当然，合并需要有度，过度合并会破坏缓存命中率，因此还要根据依赖变更频率合理拆分。
四、指定精确的基础镜像标签，拒绝latest
使用FROM ubuntu:latest虽然方便，但latest标签会随着时间推移指向新版本，导致不同时间构建的镜像基础环境不一致，难以复现。最佳实践是使用精确的版本标签，甚至使用基于内容寻址的Digest来锁定镜像版本，例如ubuntu:22.04或ubuntu@sha256:xxxx。这样在重新构建时可以保证可重复性，也便于安全团队追踪镜像来源。如果确实需要跟踪版本更新，应该通过自动化流水线定期更新并测试，而不是在生产环境依赖一个漂浮不定的标签。
五、以非root用户运行容器
很多Dockerfile默认使用root用户启动进程，这在一旦容器被入侵时，攻击者将立即获得容器内的最高权限，并可能利用权限提升漏洞影响宿主机。最佳实践是在镜像中创建专用用户，并在启动应用程序之前切换到该用户。例如，在Dockerfile中执行RUN useradd -r appuser，然后使用USER appuser。对于需要在运行期写入卷的容器，还需提前设置目录属主和权限。这样能够显著降低容器逃逸和横向移动的风险。
六、为容器设置资源限制和健康检查
容器没有天然的自我限制，一个失控的进程可能耗尽宿主机的CPU或内存。最佳实践是在运行容器时指定–memory和–cpus，或者在Compose、Kubernetes Manifest中声明resource limits。与此同时，还应当为应用定义健康检查命令，比如使用HEALTHCHECK指令定期探测HTTP接口或TCP端口。Kubernetes的liveness和readiness探针可以更精细化地区分容器是否存活、是否具备接收流量能力。资源限制让系统保持稳定，健康检查则让编排器能够自动摘除和恢复异常实例。
七、日志写到标准输出，避免文件堆积
容器是临时且可替换的，如果应用将日志写入容器内的文件，一旦容器重建日志就会丢失，而且分布式环境下很难统一收集。最佳实践是让应用直接输出日志到stdout和stderr，由Docker或容器编排平台负责采集。这也是十二要素应用的要求之一。对于现有应用，可以在启动命令中使用工具将日志重定向到标准输出，并确保日志轮转、格式化合理。这样ELK、Loki、CloudWatch等日志系统才能无缝接入。
八、使用只读根文件系统增强安全性
生产环境中的容器，理想情况下其根文件系统应该是只读的，只有明确声明的卷才可写。这样即使攻击者拿到代码执行权限，也无法篡改应用二进制或系统配置。最佳实践是在运行时加入–read-only标志，并配合–tmpfs /tmp为临时文件提供可写空间。应用如果总是试图读写根目录，往往意味着架构存在问题。只读文件系统还能让镜像在多个节点间更安全地共享，减少配置漂移的可能性。
九、定期扫描镜像漏洞并给镜像签名
镜像不是构建完就高枕无忧了。基础镜像和依赖中可能包含新发现的高危漏洞。最佳实践是使用Trivy、Clair或Grype等工具对镜像进行扫描，并将扫描接入CI/CD流水线，一旦发现高危漏洞就阻断发布。同时，考虑使用Docker Content Trust或Notation对镜像进行数字签名，确保镜像在构建后没有被篡改。签名与扫描双管齐下，能让流水线从源头建立信任。
十、在编排环境统一管理容器生命周期
单机Docker命令适合开发调试，但生产环境需要统一调度。最佳实践是使用Docker Compose做多容器本地编排，并逐步将工作负载迁移到Kubernetes或Swarm等平台。编排平台提供自动修复、滚动更新、服务发现和负载均衡能力，让上述所有最佳实践能够以声明式方式落地。更重要的是，将配置、密钥和资源限制都定义在代码中，实现基础设施即代码，确保环境之间的可复现性。
容器化的价值不仅在于“打包一次，到处运行”，更在于通过严谨的设计让交付过程变得更加可控。多阶段构建、非root用户、只读文件系统、资源限制、健康检查这些实践并非孤立的技巧，而是一整套面向故障和安全的设计哲学。当你开始认真对待镜像体积和运行权限时，许多潜伏的问题就会提前暴露并得到解决。把Docker最佳实践落到每一个流水线、每一份配置中，你会发现应用的交付速度、运行稳定性和安全水准都迈上一个新台阶。
