Docker Compose Optimizer

分析 docker-compose.yml 文件是否符合最佳实践、安全性、性能及生产就绪性要求。审计服务配置、网络设置、卷挂载、健康检查、依赖管理以及资源限制等维度。

使用方式

"优化我的 docker-compose.yml"
"检查 Docker Compose 是否存在安全问题"
"审查我的多服务架构配置"
"让我的 Compose 配置达到生产就绪标准"

工作原理

1. 配置分析

cat docker-compose.yml 2>/dev/null || cat docker-compose.yaml 2>/dev/null || cat compose.yml 2>/dev/null
ls docker-compose*.yml 2>/dev/null

2. 服务审计

• 镜像版本固化：使用带标签的镜像（而非 latest）
• 为每个服务定义健康检查（health check）
• 重启策略合理（生产环境推荐 unless-stopped）
• 环境变量：敏感信息应置于 .env 文件中，而非内联写入
• 构建上下文：是否已配置 .dockerignore？
• 端口映射：避免不必要的宿主机端口暴露

3. 网络配置

• 自定义网络 vs 默认 bridge 网络
• 通过 DNS 名称实现服务发现
• 避免将服务端口不必要地暴露至宿主机
• 服务组之间的网络隔离
• 对外部网络的连接需求

4. 卷与存储

• 命名卷（named volumes）vs 绑定挂载（bind mounts）—— 数据持久化优先使用命名卷
• 开发阶段使用绑定挂载（支持热重载）
• 生产环境使用卷驱动（volume drivers），便于备份与复制
• 临时或敏感数据使用 tmpfs
• 制定合理的卷清理策略

5. 依赖关系与启动顺序

• depends_on 配合健康检查条件（condition: service_healthy）
• 启动顺序控制：数据库 → 应用 → 工作进程（worker）
• 优雅关闭（配置 stop_grace_period）
• 初始化容器模式（init containers），可通过 profiles 实现

6. 资源管理

• 内存限制（mem_limit、memswap_limit）
• CPU 限制（cpus、cpu_shares）
• 日志配置（日志驱动、单文件最大尺寸 max-size、最大保留文件数 max-file）
• 生产服务的 ulimit 设置

7. 开发环境 vs 生产环境

• 覆盖文件（docker-compose.override.yml 用于开发环境）
• 基于 profile 的服务选择机制
• 仅开发环境启用的服务（如 mailhog、adminer、pgadmin）
• 仅生产环境启用的服务（如监控、日志收集）

输出示例

## Docker Compose 分析

**服务数量：** 6 | **网络数量：** 1（默认） | **卷数量：** 3

### 🔴 问题（2 项）
1. **缺失健康检查** —— 6 个服务中有 4 个未配置健康检查
   仅使用 `depends_on` 而未指定 `condition: service_healthy` 将导致依赖不可靠
   → 请为 db、redis、api、worker 添加 healthcheck 配置

2. **密钥硬编码在 Compose 文件中** —— 数据库密码以明文形式内联
   `POSTGRES_PASSWORD: mypassword123`
   → 请移至 .env 文件或使用 Docker secrets 管理

### 🟡 改进建议（4 项）
3. 所有服务均未设置内存限制 —— 存在某服务内存溢出（OOM）后误杀其他服务的风险
4. redis 和 postgres 镜像使用了 `latest` 标签
5. 当前使用默认 bridge 网络 —— 建议创建自定义网络以增强服务间隔离性
6. 未配置日志大小限制 —— 日志文件将持续增长，无自动轮转或清理机制

### ✅ 已遵循的良好实践
- 使用命名卷（named volumes）保障数据库数据持久化
- 重启策略已设为 `unless-stopped`
- 构建上下文采用多阶段 Dockerfile
- 通过 override 文件分离开发环境配置