贝壳主机网
注意：部分文章发布时间较长，可能存在未知因素，购买时建议在本站搜索商家名称，先充分了解商家动态。
交流：唯一投稿邮箱：hostvps@88.com。
Docker已经从一个流行工具变成了软件基础设施。但很多团队在使用Docker时，仍然停留在“打包应用”的阶段。镜像越来越大，构建越来越慢，容器权限过高，安全漏洞此起彼伏。如果你刚刚开始优化自己的Docker使用方式，希望这篇文章能帮你理清方向。所谓最佳实践，不是一条条死记硬背的命令，而是从镜像构建、容器运行、安全加固到业务编排的一整套设计原则。
先从镜像构建说起。镜像越小，传输越快，攻击面越小，这是所有实践的起点。首先要选择合适的基础镜像，尽量使用官方镜像，并且不要用latest标签，而应该固定到具体的版本。比如Python应用可以用python:3.12-slim，Debian系镜像相比Alpine更兼容常见软件包，而slim版本已经砍掉不少无用组件。下一步是使用多阶段构建。多阶段构建可以把编译环境和运行环境彻底分开，例如一个Golang服务，第一阶段用golang:1.22来编译源码，第二阶段用debian:bookworm-slim，只把编译出的二进制文件复制进去。这样最终镜像里没有Go编译器，也没有源码和缓存，体积可能直接缩小几十倍。
构建指令的顺序也很有讲究。Docker会缓存每一层构建结果，如果可能失效的步骤放在前面，后面的缓存就全部失效。所以应该把变化最频繁的指令放在Dockerfile末尾。比如先复制package.json或requirements.txt，执行依赖安装，然后再COPY整个项目源码，这样只要源文件没变，依赖层就可以复用。还要记得在RUN指令中清理临时文件。使用apt安装软件包后，删除/var/lib/apt/lists缓存，使用npm install后清除缓存目录。合并多条RUN指令可以减少镜像层数，但也不要为了减少层数而牺牲可读性。另外，在项目根目录放一个.dockerignore文件，把.git、node_modules、__pycache__等无用的目录排除在构建上下文之外，既加快传输，也避免因无关文件导致缓存失效。
再来看容器运行时的习惯。很多镜像默认以root用户启动，这是很危险的做法。一旦容器被攻破，攻击者就直接获得了宿主机的高权限。在Dockerfile中，应该创建一个专用用户，比如useradd -r -s /sbin/nologin appuser，并在运行前切换USER appuser。如果应用需要写文件，可以把相关目录授权给这个用户，或者挂载卷时指定正确的属主。运行时还要设置资源限制。使用docker run -m 1g –cpus=1可以限制这个容器最多使用1GB内存和1个CPU核心，避免单个服务把宿主机拖垮。配合重启策略，比如restart=on-failure:5，能让容器在异常退出后自动拉起。
健康检查是很多团队容易忽略的环节。Dockerfile里加上HEALTHCHECK指令，告诉Docker如何探测服务是否正常。例如对Web服务，可以定期用curl或者wget去访问健康检查端点。这样编排系统才知道容器虽然还在运行，但已经无法服务了，从而触发替换。日志处理也需要注意，应用应该把日志写到标准输出和标准错误，而不是本地文件。Docker默认会收集这些日志，配合json-file或其他日志驱动，可以直接进入集中式日志平台。如果写入文件，日志轮转和采集都会变得麻烦。
安全加固可以从基础操作开始。运行容器时，可以通过–cap-drop=ALL来丢弃所有Linux能力，然后只回填必需的能力，比如–cap-add=NET_BIND_SERVICE允许绑定低端口。使用–read-only把根文件系统设为只读，应用只能往临时目录或挂载卷里写文件，这样可以防止恶意修改镜像内文件。镜像漏洞扫描要集成到CI流程中，可以使用Trivy或Clair，定期扫描并拦截含高危漏洞的镜像。敏感信息绝对不能写进镜像或环境变量里，现代Docker Swarm和Kubernetes都支持密钥管理，至少也要使用运维平台提供的配置中心。
当从单容器走向多服务编排时，docker-compose是最简单的入口。在compose文件中定义服务时，注意depends_on只等待容器启动，不等待服务就绪。所以还要配合健康检查。建议把需要持久化的数据放在命名卷或绑定挂载中，并指定挂载目录的属主，避免权限混乱。网络方面，默认的bridge网络对容器之间访问有隔离效果，如果服务不需要对外暴露，就不要映射端口到宿主机。反过来，需要对外暴露的服务，应该明确指定端口范围，并考虑增加TLS终结的网关。
实践这些最佳实践并不会一步到位，很多团队一开始只求“能跑”，之后慢慢开始关心“跑得好”。这很正常。重要的是建立一种习惯，每次写Dockerfile和编排文件时，都从镜像体积、权限最小化、资源边界、可观测性这几个维度去检查。你会发现，大多数莫名其妙的问题都源自一次粗心的镜像构建或一个过于宽松的权限。如果把基础打牢，后续的部署、扩容、故障恢复都会顺畅很多。所谓最佳实践，其实就是对细节的持续尊重，让Docker真正成为团队的利器。
