系统重启时docker-compose.yml定义的容器启动顺序是怎样的？

核心结论：Docker Daemon 不会读取原有docker-compose.yml文件来控制系统重启后的容器启动顺序，depends_on是Docker Compose客户端层面的配置，不会持久化到Docker Daemon的容器元数据中。

具体运行逻辑 #

• depends_on仅在你执行docker compose up、docker compose start等Compose原生命令时生效，仅由Docker Compose客户端解析控制启动顺序，容器创建完成后该配置不会同步到Docker Daemon侧。
• 系统重启、Docker Daemon重启时，对配置了restart: always的容器，Daemon的启动规则如下：
  • 默认按照容器停止时的倒序进行启动，最后停止的容器最先启动
  • 如果容器配置了restart_priority（Docker 19.03+支持），则按照优先级从高到低（数值越小优先级越高）启动
  • 整个过程Docker Daemon不会关联容器所属的Compose项目，也不会读取任何Compose配置文件

实现系统重启后仍保证服务启动顺序的解决方案 #

• 方案1：配置重启优先级
  在docker-compose.yml中为服务添加restart_priority配置，示例：

  services:
    database:
      restart: always
      restart_priority: 1 # 优先级更高，优先启动
      # 其余配置省略
    web-service:
      restart: always
      restart_priority: 2
      depends_on:
        - database
      # 其余配置省略
  

  该方案仅保证启动顺序，不保证database服务完全就绪后再启动web-service。
• 方案2：使用systemd等系统服务管理Compose项目
  不依赖单个容器的restart: always，而是将整个docker compose up -d命令配置为开机自启的系统服务，系统重启后由Docker Compose客户端拉起服务，会完全遵守depends_on的配置规则。
• 方案3：web-service添加数据库连接重试逻辑（最稳妥）
  不管启动顺序如何，在web服务启动逻辑中添加数据库连接重试机制，连接失败时间隔几秒重试，最多重试N次，完全避免启动顺序或数据库初始化延迟导致的启动失败。

补充说明：原生depends_on默认仅等待依赖容器进入running状态，不会等待容器内服务进程完全就绪，如需等待服务就绪，可配合健康检查和depends_on: { condition: service_healthy }配置使用。

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