当你需要同时运行 Web 前端、后端 API、数据库和缓存等多个容器时，手动 docker run 显然难以维护。Docker Compose 通过一个 YAML 文件定义整个应用栈，实现一键启动、停止和更新。本文将从部署中的真实痛点出发，逐步拆解 Compose 的核心机制、操作步骤与取舍，并指出常见误区。
为什么需要 Compose？从手动管理到声明式编排
假设你有一个典型应用：Nginx 提供静态文件，Node.js 处理 API，PostgreSQL 存储数据，Redis 做缓存。手动启动每个容器需要记忆大量参数，还要处理网络和依赖顺序。Compose 将这一切抽象为 docker-compose.yml 中的服务定义，通过 docker compose up 即可拉起整个栈。
Compose 的核心价值在于“声明式配置”：你描述期望的状态（哪些服务、什么镜像、如何连接），Compose 负责执行。这与 Kubernetes 的理念一脉相承——Kubernetes 官方文档指出，它是一个可移植、可扩展的平台，用于管理容器化工作负载和服务，并促进声明式配置和自动化。Compose 可以看作单机场景下 Kubernetes 的轻量替代。
编写 docker-compose.yml：服务、网络与卷
一个最小但完整的 Compose 文件包含三个顶级元素：services、networks、volumes。services 定义每个容器，networks 定义容器间的通信方式，volumes 提供持久化存储。
version: '3.8'
services:
web:
image: nginx:latest
ports:
- "80:80"
networks:
- frontend
api:
build: ./api
networks:
- frontend
- backend
depends_on:
- db
db:
image: postgres:13
volumes:
- db-data:/var/lib/postgresql/data
networks:
- backend
volumes:
db-data:
networks:
frontend:
backend:这里 web 服务暴露端口到宿主机，api 服务通过构建本地 Dockerfile 生成镜像，db 使用命名卷持久化数据。注意 api 同时连接 frontend 和 backend 两个网络，实现隔离：web 无法直接访问 db。
网络模式的选择
Compose 默认创建 bridge 网络，服务之间通过服务名互相访问。如果你需要更细粒度的控制，可以参考 Docker 容器网络模式详解与配置指南。常见误区是让所有服务共享同一个网络，导致不必要的暴露面。
服务依赖与启动顺序
depends_on 只是控制启动顺序，不保证服务“就绪”。例如 db 容器启动后，PostgreSQL 可能还在初始化，api 连接会失败。你需要健康检查（healthcheck）来确保依赖真正可用。
services:
db:
image: postgres:13
healthcheck:
test: ["CMD", "pg_isready", "-U", "postgres"]
interval: 5s
timeout: 3s
retries: 5
api:
depends_on:
db:
condition: service_healthy这样 api 会等待 db 健康检查通过后才启动。这是多容器编排中最常见的失败点之一。
环境变量与配置管理
不同环境（开发、测试、生产）需要不同的配置。Compose 支持通过 env_file 加载环境变量文件，也可以使用 ${VAR} 引用宿主机环境变量。注意不要将敏感信息硬编码在 Compose 文件中，应使用 Docker secrets 或外部工具管理。
滚动更新与版本升级
当代码更新时，你通常需要重新构建镜像并更新服务。docker compose build 重新构建，docker compose up -d 会检测到镜像变化并重新创建容器。但默认策略是停止旧容器再启动新容器，会有短暂停机。若要零停机，需要借助负载均衡器或使用 Docker Swarm 的滚动更新功能。
这里需要明确：Compose 本身不提供滚动更新，它只是单机编排工具。如果追求高可用和自动扩缩容，应转向 Kubernetes。Kubernetes 提供了 Pod、Service、Deployment 等抽象，支持滚动更新和回滚，但学习曲线陡峭。
与 Kubernetes 的对比与迁移
Compose 适合开发环境、小型部署或单机场景；Kubernetes 适合生产级、多节点集群。迁移时，你可以使用 kompose 工具将 docker-compose.yml 转换为 Kubernetes 清单，但并非所有 Compose 特性都能直接映射，例如 depends_on 需要转换为 initContainer 或 readinessProbe。
Kubernetes 官方文档强调其可移植性和可扩展性，但它也带来了更高的复杂度。如果你的应用只有几个容器，Compose 足够；如果预计要扩展到多节点，尽早规划迁移。
常见误区与失败条件
- 忽略数据持久化：不定义卷，容器删除后数据丢失。使用命名卷或绑定挂载，参见 Docker 数据卷与挂载：实现容器持久化存储。
- 依赖就绪判断错误：仅用 depends_on 不配合健康检查，导致服务启动失败。
- 镜像构建优化不足：每次构建都从头开始，导致构建缓慢。参考 Docker 镜像构建优化技巧。
- 忽视日志与监控：多容器环境下，日志分散，需要集中日志方案。OpenTelemetry 是业界标准的可观测性框架，用于生成、收集和导出遥测数据，支持 traces、metrics 和 logs，可以帮助你统一监控整个应用栈。
总结
Docker Compose 解决了多容器应用编排的痛点，通过声明式配置简化了部署和管理。在实际使用中，要特别注意网络隔离、依赖就绪、数据持久化和配置管理。对于单机场景，Compose 是高效选择；当需要集群化和高级编排时，再考虑 Kubernetes。记住，工具的选择取决于你的实际需求。
参考资料
延伸阅读