Docker Compose 多容器编排助手

解决什么问题

手写 docker-compose.yml 时，最容易翻车的不是语法，而是那些「看起来能跑」的隐患：数据库容器已经启动但还没开始监听端口，应用容器就抢先连接并崩溃退出；生产环境用了 latest 标签，某天镜像更新直接把部署搞挂；反向代理所在的网络竟然能直连数据库，一旦容器被打穿，爆炸半径波及全部数据层。多容器栈的服务发现、启动顺序、数据持久化、环境差异，每一项都琐碎，拼在一起就很难靠记忆维护。

这个技能把多容器编排拆成一套可重复的流程，让 Agent 生成结构清晰、符合 Docker 最佳实践的 Compose 配置，而不是一段临时拼凑的 YAML。

核心能力与工作流程

1. 梳理应用栈：先分析架构，识别应用、数据库（PostgreSQL、MySQL、MongoDB）、缓存（Redis、Memcached）、消息队列（RabbitMQ、Kafka）、后台 worker 与反向代理（Nginx、Traefik），并绘制服务间的依赖关系与启动顺序。

2. 定义服务与镜像：应用服务用 build 指向本地 Dockerfile，基础设施服务使用固定版本号的官方镜像，生产环境明确避免 latest，保证可复现部署。

3. 网络与服务发现：按层划分命名网络（前端网、后端网），服务之间直接用 Compose 服务名作为 DNS 主机名通信，不再硬编码 IP。

4. 数据卷与持久化：持久数据使用命名卷；开发环境用 bind mount 挂载源码实现热重载，同时保证卷内文件属主与容器运行用户一致。

5. 健康检查与启动顺序：给关键服务配置 healthcheck，配合 depends_on 的 condition: service_healthy，让依赖服务等到上游真正就绪再启动。

6. 环境分层覆盖：生成共享的 docker-compose.yml 基础文件，再叠加 docker-compose.override.yml（开发：bind mount、调试端口、详细日志）与 docker-compose.prod.yml（生产：资源限制、重启策略、日志驱动优化），避免整份文件复制粘贴。

适用边界与注意点

• 主机端口冲突：端口被占用时 Compose 会绑定失败，仅需容器间通信的服务可把端口留空（ports: []）。
• 卷权限不匹配：非 root 容器写挂载卷可能因属主不符失败，需要在 Compose 里指定 user: 或在 entrypoint 中 chown。
• 构建缓存失效：Dockerfile 中靠前的 COPY/ADD 变动会让后续所有层缓存失效，应把依赖安装放在源码拷贝之前。
• 启动期 DNS：依赖容器尚未分配 IP 时可能解析失败，健康检查能缓解，但应用层仍建议加入重试逻辑。
• 孤儿资源：从 Compose 文件移除服务后，旧容器仍在运行，需要 docker compose up --remove-orphans 清理，并定期 docker volume prune。
• 技能基于 Docker Compose V2，覆盖 Node.js、Python、Ruby、Go、Java、PHP、.NET 等运行时，但不会替代你对基础设施合规与备份策略的判断。