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下有序启动;
参考文章
假如您对docker容器康健检查有兴致,能够参考以下文章:
- 《极速体验docker容器康健》;
《Java运用在docker环境设置容器康健检查》;
迎接关注民众号:程序员欣宸