Docker Compose中服务依赖关系在extend场景下的失效问题分析

在Docker Compose 2.32.1版本中，用户发现了一个影响服务启动顺序的关键问题：当服务通过extends继承其他配置时，其depends_on依赖声明会完全失效。这个问题在容器编排场景下可能导致严重的启动顺序错乱，特别是在需要确保数据库等基础服务健康后才启动应用服务的场景中。

问题现象

典型的故障表现为：在组合使用extends和depends_on的配置中，虽然明确定义了服务间的健康依赖条件，但Compose在实际执行时会忽略这些约束。例如以下配置片段：

service_a:
  extends:
    file: "base-config.yml"
    service: template
  depends_on:
    dns:
      condition: service_healthy

这种情况下，Compose会直接启动service_a而不等待dns服务达到健康状态，违背了编排的预期顺序。

技术背景

Docker Compose的extends机制原本用于实现配置复用，允许服务继承另一个服务或外部文件中定义的配置。而depends_on则是控制服务启动顺序的核心指令，特别是配合service_healthy条件可以精确控制服务依赖关系。

这两个功能的组合使用在早期版本中工作正常，但在2.32.1版本中出现了兼容性问题。其根本原因在于配置合并逻辑的变更——在解析阶段，扩展配置的合并操作意外覆盖了依赖关系声明。

影响范围

该问题具有以下特征：

1. 仅影响同时使用extends和depends_on的配置
2. 所有类型的依赖条件（包括service_healthy）均会失效
3. 从2.32.0升级到2.32.1时会出现行为变化

解决方案

开发团队已通过底层库compose-go的修复解决了这个问题。用户可通过以下方式应对：

1. 临时降级到2.32.0版本
2. 等待包含修复的新版本发布
3. 重构配置，将关键依赖关系移至基础模板中（不推荐，会降低配置灵活性）

最佳实践建议

为避免类似问题，建议：

1. 在复杂编排场景中，始终通过docker compose config验证最终生成的配置
2. 对关键业务服务考虑使用启动探针作为额外保障
3. 跨服务依赖最好通过应用层重试机制作为补充

这个问题提醒我们，在容器编排中，启动顺序控制是需要特别关注的领域，任何配置变更都应通过完整的集成测试验证。