Alibaba Cloud Linux 4 服务器运维笔记--condition: service_healthy 的作用

# 如果没有健康检查，启动顺序可能是：
1. MySQL容器状态: running ✅
2. API应用启动并立即连接MySQL ❌
3. 但MySQL内部可能还在初始化，连接失败
4. 应用报错: "MySQL connection refused"

结果: 应用启动失败，需要手动重启

# 使用健康检查后：
1. MySQL容器状态: running ✅
2. MySQL健康状态: starting... (等待)
3. MySQL完成初始化，健康状态: healthy ✅  
4. API应用才开始启动并连接MySQL ✅
5. 连接成功，应用正常启动 ✅

结果: 应用一次性启动成功

检查过程：

MySQL启动 → 等待30秒(start_period) → 开始健康检查 → 
→ 第1次检查(10s间隔) → 失败? → 重试 →
→ 第2次检查(10s后) → 失败? → 重试 →
...
→ 第N次检查 → 成功 → 状态变为healthy

 完整的健康检查配置

healthcheck:
      # 检查命令：使用mysqladmin ping测试连接
      test: ["CMD", "mysqladmin", "ping", "-h", "localhost", "-uroot", "-p$$MYSQL_ROOT_PASSWORD"]
      timeout: 20s      # 每次检查超时时间
      interval: 10s     # 每10秒检查一次
      retries: 5        # 失败重试5次
      start_period: 30s # 容器启动后30秒开始检查

 健康状态类型 

# 可能的健康状态：
starting    # 容器启动中，还未开始健康检查
healthy     # 健康检查通过 ✅
unhealthy   # 健康检查失败 ❌
none        # 未配置健康检查

 depends_on的三种条件 

depends_on:
  service_name:
    condition: service_healthy    # 等待服务健康 ✅ (推荐)
    # 或者
    condition: service_started    # 等待服务启动（不关心健康）
    # 或者
    condition: service_completed_successfully  # 等待服务成功完成（一次性任务）

 区别：
service_healthy: 最严格，确保依赖服务完全就绪
service_started: 较宽松，容器启动就开始
service_completed_successfully: 用于初始化脚本等一次性任务

为什么要加 condition: service_healthy：

1. 避免启动竞争：防止应用在数据库完全就绪前尝试连接

2. 提高启动可靠性：确保依赖服务真正可用

3. 自动化运维：不需要手动控制启动顺序

4. 生产环境必备：保证服务高可用性

简单来说： 这个配置就是告诉 Docker："等 MySQL 完全准备好了，再启动我的应用"，这样可以避免很多莫名其妙的启动失败问题。

对于生产环境，强烈建议为所有有依赖关系的服务配置健康检查！