Docker编排

你需要解决的痛点

当你的项目需要同时运行前端、后端、数据库、Redis 等多个服务时，手动执行 docker run 会暴露诸多问题：服务启动顺序失控（比如 API 启动时数据库尚未准备好连接）、网络配置分散难管理、数据卷生命周期不明确（docker compose down 是否删数据全靠猜），以及开发与生产环境差异难以维护。这些问题会让本地环境搭建耗时较长，甚至出现“在我机器上能跑”的排查困境。

技能的工作方式

服务定义：按业务域拆分

将同一应用栈的服务集中在一个 Compose 文件中，遵循“主配置 + 按需覆盖”原则：compose.yml 定义核心服务，compose.override.yml 用于开发环境覆盖，compose.prod.yml 用于生产环境覆盖。每个服务需明确 image/build、ports、environment、volumes、depends_on 和 healthcheck 等关键配置。

网络与数据卷管理

• 网络：利用 Compose 默认创建的 {project}_default 桥接网络，服务通过服务名直接通信（如 http://api:3000）；通过 external: true 连接已存在的外部网络，或在特定调试场景分配静态 IP（ipv4_address: 172.20.0.10）。
• 数据卷：区分命名卷（db_data:，docker compose down 不删除，需加 -v 才会清理）和绑定挂载（.:/app 支持开发热更新），支持只读挂载（ro）限制容器对宿主机文件的修改权限。

健康检查与启动顺序

depends_on 仅等待容器启动，而非服务就绪（如 DB 可能已启动但未接受连接）。正确做法是通过 healthcheck 结合 depends_on: condition: service_healthy（Docker Compose v2.1+）确保服务真正可用。替代方案包括应用内重试数据库连接（推荐）、使用 wait-for-it.sh 作为 entrypoint 包装器，或执行 docker compose up --wait 等待健康检查通过。

Profiles 环境区分

通过 profiles 标记可选服务（如 mailhog 设为 profiles: [dev]），实现开发环境按需启动，避免非必要服务占用资源。

适用边界

适合本地开发环境搭建（前端 + 后端 + 数据库 + Redis 等）、CI/CD 测试环境标准化，以及单机多服务部署。不适用于生产环境多主机编排（需使用 Kubernetes 或 Docker Swarm），且对 Windows 容器支持较弱。