docker-compose下的java應用啟動順序兩部曲之一：問題分析

歡迎訪問我的GitHub

這里分類和匯總了欣宸的全部原創(含配套源碼)：https://github.com/zq2599/blog_demos

本篇概覽

在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下容器啟動順序的問題，下一篇文章《docker-compose下的java應用啟動順序兩部曲之二：實戰》，我們用SpringCloud應用來做實戰，將其做到在docker-compose下有序啟動；

歡迎關注華為云博客：程序員欣宸

學習路上，你不孤單，欣宸原創一路相伴…

Docker Java

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。