docker-compose下的java应用启动顺序两部曲之一：问题分析

在docker-compose编排多个容器时，须要按实际状况控制各容器的启动顺序，本文是《docker-compose下的java应用启动顺序两部曲》的第一篇，文中会分析启动顺序的重要性，以及启动顺序有问题时会有什么样的影响，再给出临时解决的和官方推荐的两种解决方案，为下一篇的实战作好铺垫。

环境信息

本次实战的环境以下：

1. 操做系统：CentOS Linux release 7.7.1908
2. docker：1.13.1
3. docker-compose：1.24.1
4. spring cloud：Finchley.RELEASE

分布式环境中的依赖关系

在分布式环境中，各服务之间可能存在依赖关系，例如SpringCloud环境中的应用在启动时都会先往注册中心Eurka发起请求，以下图（来自spring官方博客：https://spring.io/blog/2015/07/14/microservices-with-spring ）： 从上图可知，若是Eureka的服务不可用，就会影响业务服务的功能；

Docker环境中的依赖关系

1. 上述服务若是用docker-compose编排在一块儿，也面依赖着问题：Eureka容器启动完毕而且能提供http服务之后，业务服务的容器才能在Eureka注册成功并取得服务列表，一般咱们都使用<font color="blue">depends_on</font>参数来设定依赖关系；
2. 如下是个docker-compose.yml文件，里面有两个容器：eureka和service，eureka是注册中心，service是业务服务，service启动后要去eureka注册，为了确保启动顺序，service配置了<font color="blue">depends_on</font>参数：

version: '3'
services:
  eureka:
    image: bolingcavalry/eureka:0.0.1-SNAPSHOT
    container_name: eureka
    restart: unless-stopped
  service:
    image: bolingcavalry/service:0.0.1-SNAPSHOT
    container_name: service
    restart: unless-stopped
    command: sh -c 'java -Xms1g -Xmx1g -cp /app/resources:/app/classes:/app/libs/* com.bolingcavalry.waitforitdemo.ServiceApplication'
    depends_on:
    - eureka

3. 上述yml文件能解决依赖问题吗？service服务启动时可否成功在eureka注册？来试试吧，在Linux电脑上建立docker-compose.yml文件，内容如上所示；
4. 在docker-compose.yml所在目录执行<font color="blue">docker-compose up</font>，docker服务会先去hub.docker.com下载镜像，而后依次建立容器，控制台会同时打印eureka和service的日志，以下图所示，service注册eureka失败了，请注意图中的文字分析：
5. 为什么会注册失败呢？继续看后面的日志，以下图，service注册失败后eureka才初始化完成，因此前面的service注册会失败：
6. 至此能够肯定：<font color="blue">depends_on</font>参数能够确保eureka容器启动后再启动service容器，但咱们真正想要的，是eureka容器启动后，而且eureka服务初始化完毕进入可用状态后，再启动service容器，显然<font color="blue">depends_on</font>参数达不到咱们的要求；
7. docker官方文档也证明了这一点，以下图红框所示：
8. 看来<font color="blue">depends_on</font>参数解决不了咱们的问题，须要去寻找其余方法；

另外您可能会说：不要紧，service会自动从新注册，可是在真实环境中，不是每一个服务都有能力去本身解决依赖不可用的问题，例如spring-cloud-config服务若是起不来，依赖它的服务可能会当即中止；

有一种临时方法(此方法V3版语法再也不支持)

1. 若是eureka容器配置了健康检查，那么service容器能够配置健康检查依赖来控制启动时机，具体的作法能够参考官方示例，以下所示，地址是：https://docs.docker.com/compose/compose-file/compose-file-v2/ ：

version: "2.4"
services:
  web:
    build: .
    depends_on:
      db:
        condition: service_healthy
      redis:
        condition: service_started
  redis:
    image: redis
  db:
    image: redis
    healthcheck:
      test: "exit 0"

从上述编排内容可见：db容器有健康检查，能够肯定db容器的服务是否可用，web容器的<font color="blue">depends_on</font>参数内能够配置<font color="blue">condition</font>，这样就作到了只有redis已经启动而且db的健康检查经过，才会启动web容器； 2. 上述配置看起来彷佛是个不错的方案，在咱们这里，只要给eureka配置要健康检查，再让service容器的<font color="blue">depends_on</font>参数内配置<font color="blue">condition: service_healthy</font>就能够了； 3. 不幸的是：<font color="red">在docker-compose的第三版语法中，取消了condition参数！</font>文档地址是：https://docs.docker.com/compose/compose-file/ ，以下图红框所示： 4. 所以，condition参数看似好用，可是从V3版开始的docker-compose.yml已经再也不支持该参数，不能做为标准的解决方案；

官方推荐的方案

以下图红框所示，docker官方推荐使用<font color="blue">wait-for-it.sh</font>脚原本解决问题，地址：https://docs.docker.com/compose/startup-order/ ： 至此，本篇已经分析了docker-compose下容器启动顺序的问题，下一篇文章，咱们用SpringCloud应用来作实战，将其作到在docker-compose下有序启动；

参考文章

若是您对docker容器健康检查有兴趣，能够参考如下文章：

1. 《极速体验docker容器健康》；
2. 《Java应用在docker环境配置容器健康检查》；

欢迎关注公众号：程序员欣宸