Docker Compose 2.32版本依赖服务启动异常问题深度解析

问题背景

在Docker生态中，Compose作为多容器编排工具，其服务依赖关系通过depends_on指令实现。近期用户升级至2.32版本后，发现docker-compose run命令出现严重行为变更：当通过extends继承基础服务的测试服务运行时，依赖链中的中间服务（middleware）及其下级服务（nginx_a/nginx_b）未能按预期启动。

技术现象还原

典型场景包含四级服务依赖：

1. 测试服务（test）继承基础配置（base）
2. 显式声明依赖中间服务（middleware）
3. 中间服务自身依赖两个nginx实例
4. 旧版（2.31.0）能正确启动完整依赖链，而新版（≥2.32.0）仅运行测试容器

底层机制分析

该问题涉及Compose核心机制：

1. 服务继承体系：extends指令本应完整继承基础服务配置，包括依赖关系
2. 依赖解析逻辑：depends_on应触发拓扑排序，确保依赖服务优先启动
3. 运行时控制流：run命令需特殊处理依赖服务启动顺序

影响范围评估

该缺陷导致：

• 测试环境无法模拟完整服务拓扑
• 依赖服务健康检查失效
• 继承体系中的隐含依赖丢失
• 需要人工干预启动依赖服务

临时解决方案

建议采取以下措施：

1. 降级至2.31.0稳定版本
2. 显式声明所有依赖（包括继承链中的隐含依赖）
3. 改用up命令配合服务筛选
4. 实现自定义启动脚本控制服务顺序

技术启示

该案例揭示了容器编排工具的复杂行为：

1. 版本升级可能破坏隐式约定
2. 继承机制与依赖解析需要协同设计
3. 编排工具的行为一致性至关重要
4. 完善的测试用例应覆盖多级依赖场景

最佳实践建议

1. 重要环境保留版本回滚能力
2. 显式声明所有关键依赖
3. 建立编排配置的版本管控机制
4. 复杂依赖关系考虑引入服务网格