docker-compose下的java运用启动递次两部曲之一：题目剖析

2019-11-18杂谈搜奇网40°c

A⁺ A^-

在docker-compose编排多个容器时，需要按实际情况掌握各容器的启动递次，本文是《docker-compose下的java运用启动递次两部曲》的第一篇，文中会剖析启动递次的重要性，以及启动递次有题目时会有什么样的影响，再给出暂时处理的和官方引荐的两种处理计划，为下一篇的实战做好铺垫。

环境信息

本次实战的环境以下：

操作系统：CentOS Linux release 7.7.1908
docker：1.13.1
docker-compose：1.24.1
spring cloud：Finchley.RELEASE

分布式环境中的依靠关联

在分布式环境中，各效劳之间能够存在依靠关联，比方SpringCloud环境中的运用在启动时都邑先往注册中间Eurka提议请求，以下图（来自spring官方博客：https://spring.io/blog/2015/07/14/microservices-with-spring ）：

从上图可知，假如Eureka的效劳不可用，就会影响营业效劳的功用；

Docker环境中的依靠关联

上述效劳假如用docker-compose编排在一起，也面依靠着题目：Eureka容器启动终了而且能供应http效劳今后，营业效劳的容器才能在Eureka注册胜利并获得效劳列表，一般我们都运用depends_on参数来设定依靠关联；
以下是个docker-compose.yml文件，内里有两个容器：eureka和service，eureka是注册中间，service是营业效劳，service启动后要去eureka注册，为了确保启动递次，service设置了depends_on参数：

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

上述yml文件能处理依靠题目吗？service效劳启动时可否胜利在eureka注册？来尝尝吧，在Linux电脑上建立docker-compose.yml文件，内容如上所示；
在docker-compose.yml地点目次实行docker-compose up，docker效劳会先去hub.docker.com下载镜像，然后顺次建立容器，掌握台会同时打印eureka和service的日记，以下图所示，service注册eureka失利了，请注意图中的笔墨剖析：
为什么会注册失利呢？继承看后面的日记，以下图，service注册失利后eureka才初始化完成，所以前面的service注册会失利：
至此能够肯定：depends_on参数能够确保eureka容器启动后再启动service容器，但我们真正想要的，是eureka容器启动后，而且eureka效劳初始化终了进入可用状况后，再启动service容器，明显depends_on参数达不到我们的请求；
docker官方文档也证明了这一点，以下图红框所示：
看来depends_on参数处理不了我们的题目，需要去寻觅其他要领；

别的您能够会说：没紧要，service会自动从新注册，然则在实在环境中，不是每一个效劳都有才能去本身处理依靠不可用的题目，比方spring-cloud-config效劳假如起不来，依靠它的效劳能够会马上住手；

有一种暂时要领(此要领V3版语法不再支撑)

假如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容器的depends_on参数内能够设置condition，如许就做到了只要redis已启动而且db的康健检查经由过程，才会启动web容器；

上述设置看起来似乎是个不错的计划，在我们这里，只要给eureka设置要康健检查，再让service容器的depends_on参数内设置condition: service_healthy就能够了；
不幸的是：在docker-compose的第三版语法中，取消了condition参数！文档地点是：https://docs.docker.com/compose/compose-file/ ，以下图红框所示：
因而，condition参数看似好用，然则从V3版最先的docker-compose.yml已不再支撑该参数，不能作为规范的处理计划；

官方引荐的计划

以下图红框所示，docker官方引荐运用wait-for-it.sh脚原本处理题目，地点：https://docs.docker.com/compose/startup-order/ ：

至此，本篇已剖析了docker-compose下容器启动递次的题目，下一篇文章，我们用SpringCloud运用来做实战，将其做到在docker-compose下有序启动；