Docker容器配置启动顺序的三种方式

如果对你有帮助希望点赞收藏~

转载请注明出处~

欢迎批评、指点、讨论~

https://blog.csdn.net/L_Open2021/article/details/129901741

目录

1.问题描述

2.问题解决

方法1：通过 depends_on 结合 healthcheck 实现容器顺序启动（强烈推荐！）

 方案2：shell脚本弹窗被依赖（较复杂）

方案3：通过Docker file 设置延时启动（不推荐，伪顺序）

---

1.问题描述

在微服务项目中，多容器之间存在相关依赖的关系。

B容器启动时会调用A容器部分接口，所以存在B容器会由于A容器而启动失败的情况

2.问题解决

方法1：通过 depends_on 结合 healthcheck 实现容器顺序启动（强烈推荐！）

例：webB容器依赖了webA容器

先来看docker-compose

services：  
  webA:
    restart: always
    environment:
    MYSQL_PWD: 123456
    container_name: webA
    image: webA

    healthcheck:
	 # http://localhost:4000/health 为webA容器指定的健康检查接口
      test: ["CMD", "curl", "-f", "http://localhost:4000/health"]
     # 健康检查的间隔，默认为 30 秒，单位(h/m/s)；
      interval: 30s 
	 # 健康检查命令运行超时时间，如果超过这个时间，本次健康检查就被视为失败，单位(h/m/s)；
      timeout: 20s
	 # 当连续失败指定次数后，则将容器状态视为 unhealthy。
      retries: 5

  webB:
    restart: always
    environment:
      MYSQL_PWD: 123456
    container_name: webB
    image: webB
	# webA容器之后启动，并且webA容器的健康状态为healthy
    depends_on:
      webA: 
	    condition: service_healthy

webB容器启动前会根据webA容器的健康状态来判断是否启动，而webA容器的健康状态根据设定的healthcheck中指定的心跳监测接口来确定

服务调用关系是 webA -> webB，我们的服务由于存在token校验机制，就算服务启动成功了，直接调用 [ip：端口]还是会失败【curl: (22) The requested URL returned error: 424】

所以在webA服务中增加了一个开放的可以绕过token校验的接口用于服务心跳监测，从而判断健康状态

当webA服务启动时会自动监测健康状态，直到确认为unhealthy时，bgi服务会启动失败

实际案例（顺序 upms -> bgi -> thingsboard）：

失败时： 

 等待状态：

成功状态：

 方案2：shell脚本弹窗被依赖（较复杂）

        思路：在容器启动命令执行之前，跑一个shell脚本，通过shell nc 端口探测被依赖容器来确定被依赖的容器是否ready，随后再去启动后者。

        1. 直接手写shell脚本，通过 nc 端口探测。

https://blog.51cto.com/topic/docker-rongqiqidongshunxu.html

        2. github上的一个开源项目 wait-for-it，拆箱即用

https://www.jianshu.com/p/c54899d50d05

方案3：通过Docker file 设置延时启动（不推荐，伪顺序）

思路：根据服务实际启动时间，对每个服务进行合理的延时时间分配