docker-compose restart时depends_on失效如何配置容器启动顺序

• docker-compose restart 命令本身默认不会解析服务间的depends_on依赖关系，执行时仅会按照compose文件里声明的服务条目顺序逐个重启，这是配置不生效的核心原因。
• Compose 3.x 版本的特性变更：在3.0~3.3版本中，移除了2.x版本里depends_on自带的拓扑顺序校验、服务就绪等待能力；从3.4版本开始，才重新支持depends_on的条件配置，但这部分规则仅在执行docker-compose up、docker-compose start这类全量拉起操作时生效，对restart操作无约束作用。

方案1：拆分执行重启步骤，实现可控顺序 #

完全绕开单条restart命令的顺序缺陷，按目标顺序手动执行：

• 先执行A服务的重启命令：docker-compose restart A
• 等待A服务完全进入正常运行状态，可配合简单的状态探测逻辑校验容器健康度
• 再执行B服务的重启命令：docker-compose restart B

这种方式不依赖CLI版本特性，可控性最高，也是生产环境常用的操作方式。

方案2：利用旧版CLI的--deps参数触发依赖顺序重启 #

如果使用的是Python实现的V1版本docker-compose独立客户端（版本1.29.x及更早），可以在restart命令中追加--deps参数，强制命令解析依赖拓扑：

docker-compose restart --deps B

该命令会自动先把B依赖的上游服务（即服务A）按依赖顺序完成重启，再重启B服务，完全匹配先A后B的执行要求。如果使用的是V2版本的docker compose插件（即集成在docker CLI里的docker compose命令，无连字符），该参数已被移除，无法使用此方案。

方案3：优化Compose配置，适配全量场景下的顺序要求 #

借助3.4版本支持的健康检查+依赖条件配置，保证全量拉起场景下的顺序正确性：

services:
  A:
    # 原有A服务配置
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:服务健康检查路径"]
      interval: 10s
      timeout: 5s
      retries: 3
  B:
    # 原有B服务配置
    depends_on:
      A:
        condition: service_healthy

该配置生效后，执行全量docker-compose up操作时，会严格等待A服务进入健康状态后，才会启动B服务，避免启动顺序混乱。

• 无需为了实现顺序控制刻意将Compose文件版本降级到2.x，会损失3.x版本的网络、资源配额等特性支持，性价比极低。
• 生产环境中不建议依赖单条docker-compose restart命令处理跨服务的启动顺序，该命令的设计定位是快速重启指定单个服务，本身没有做严格的依赖顺序校验，拆分操作的稳定性更高。

内容的提问来源于stack exchange，提问作者Robert Sinclair