Docker Compose

依赖于就绪条件

• depends_on：仅等待容器启动——服务可能尚未就绪
• 添加健康检查 + 条件以实现实际就绪状态：

depends_on:
  db:
    condition: service_healthy

• 如果在目标服务上未定义健康检查，service_healthy会失败

健康检查启动周期

healthcheck:
  test: ["CMD", "pg_isready"]
  start_period: 30s

• start_period：初始宽限期——在此期间的健康检查失败不计入
• 启动缓慢的服务（数据库、Java应用）需要足够的启动周期
• 如果没有它，容器可能在完成初始化前就被标记为不健康

卷销毁

• docker compose down保留卷
• docker compose down -v删除所有卷——导致数据丢失
• -v通常因教程习惯添加——在生产环境中是灾难性的
• 命名卷会保留down匿名卷被删除向下

开发中的资源限制

deploy:
  resources:
    limits:
      memory: 512M

• 在开发过程中设置限制——及早发现内存问题
• 无限制的容器会耗尽所有主机内存——导致其他进程被终止
• 将限制复制到生产配置中——不要在生产环境中才发现限制

.dockerignore 文件

• 如果没有它：node_modules 目录、.git 目录、密钥会被复制到镜像中
• 镜像.gitignore 语法——在与 Dockerfile 同一层级创建
• 过大的构建上下文 = 构建缓慢、镜像庞大、可能存在安全问题
• 至少应包含：.git 目录、node_modules 目录、.env 文件,*.log构建产物

覆盖文件模式

• docker-compose.yml：适用于所有环境的基础配置
• docker-compose.override.yml：自动加载，开发环境专用（挂载、端口）
• 生产环境：docker compose -f docker-compose.yml -f docker-compose.prod.yml up
• 将密钥和环境特定配置保存在覆盖文件中，而非基础文件

可选服务的配置文件

services:
  mailhog:
    profiles: [dev]

• 带配置文件的服务默认不启动——更简洁docker compose up
• 启用方式：--profile dev
• 适用于：测试数据库、调试工具、模拟服务、管理界面

环境变量优先级

1. Shell环境变量（最高）
2. .envcompose目录中的文件
3. env_file：指令
4. 环境：在compose文件中（该变量的最低优先级）

• .env必须精确命名为.env—.env.local不会自动加载
• 调试使用docker compose config—显示解析后的值