版权声明:本文为博主原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。
本文链接:[https://blog.csdn.net/boling\_cavalry/article/details/102874052](https://blog.csdn.net/boling_cavalry/article/details/102874052)
在docker-compose编排多个容器时,需要按实际情况控制各容器的启动顺序,本文是《docker-compose下的java应用启动顺序两部曲》的第一篇,文中会分析启动顺序的重要性,以及启动顺序有问题时会有什么样的影响,再给出临时解决的和官方推荐的两种解决方案,为下一篇的实战做好铺垫。
本次实战的环境如下:
在分布式环境中,各服务之间可能存在依赖关系,例如SpringCloud环境中的应用在启动时都会先往注册中心Eurka发起请求,如下图(来自spring官方博客:https://spring.io/blog/2015/07/14/microservices-with-spring ):
从上图可知,如果Eureka的服务不可用,就会影响业务服务的功能;
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
另外您可能会说:没关系,service会自动重新注册,但是在真实环境中,不是每个服务都有能力去自己解决依赖不可用的问题,例如spring-cloud-config服务如果起不来,依赖它的服务可能会立即停止;
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容器;
如下图红框所示,docker官方推荐使用wait-for-it.sh脚本来解决问题,地址:https://docs.docker.com/compose/startup-order/ :
至此,本篇已经分析了docker-compose下容器启动顺序的问题,下一篇文章《docker-compose下的java应用启动顺序两部曲之二:实战》,我们用SpringCloud应用来做实战,将其做到在docker-compose下有序启动;
如果您对docker容器健康检查有兴趣,可以参考以下文章: