### 歡迎訪問我的GitHub
> 這裡分類和彙總了欣宸的全部原創(含配套原始碼)：[https://github.com/zq2599/blog_demos](https://github.com/zq2599/blog_demos)

- 在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 ）：
![在這裡插入圖片描述](https://img-blog.csdnimg.cn/20191102185033868.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly94aW5jaGVuLmJsb2cuY3Nkbi5uZXQ=,size_16,color_FFFFFF,t_70)
- 從上圖可知，如果Eureka的服務不可用，就會影響業務服務的功能；
### Docker環境中的依賴關係
- 上述服務如果用docker-compose編排在一起，也面依賴著問題：Eureka容器啟動完畢並且能提供http服務以後，業務服務的容器才能在Eureka註冊成功並取得服務列表，通常我們都使用 **depends_on** 引數來設定依賴關係；
- 以下是個docker-compose.yml檔案，裡面有兩個容器：eureka和service，eureka是註冊中心，service是業務服務，service啟動後要去eureka註冊，為了確保啟動順序，service配置了 **depends_on** 引數：
```yml
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失敗了，請注意圖中的文字分析：
![在這裡插入圖片描述](https://img-blog.csdnimg.cn/2019110220011566.jpg?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly94aW5jaGVuLmJsb2cuY3Nkbi5uZXQ=,size_16,color_FFFFFF,t_70)
- 為何會註冊失敗呢？繼續看後面的日誌，如下圖，service註冊失敗後eureka才初始化完成，所以前面的service註冊會失敗：
![在這裡插入圖片描述](https://img-blog.csdnimg.cn/20191102201320784.jpg?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly94aW5jaGVuLmJsb2cuY3Nkbi5uZXQ=,size_16,color_FFFFFF,t_70)
- 至此可以確定： **depends_on** 引數可以確保eureka容器啟動後再啟動service容器，但我們真正想要的，是eureka容器啟動後，並且eureka服務初始化完畢進入可用狀態後，再啟動service容器，顯然 **depends_on** 引數達不到我們的要求；
- docker官方文件也證實了這一點，如下圖紅框所示：
![在這裡插入圖片描述](https://img-blog.csdnimg.cn/20191102213318266.jpg?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly94aW5jaGVuLmJsb2cuY3Nkbi5uZXQ=,size_16,color_FFFFFF,t_70)
- 看來 **depends_on** 引數解決不了我們的問題，需要去尋找其他方法；

- 另外您可能會說：沒關係，service會自動重新註冊，但是在真實環境中，不是每個服務都有能力去自己解決依賴不可用的問題，例如spring-cloud-config服務如果起不來，依賴它的服務可能會立即停止；
### 有一種臨時方法(此方法V3版語法不再支援)
- 如果eureka容器配置了健康檢查，那麼service容器可以配置健康檢查依賴來控制啟動時機，具體的做法可以參考官方示例，如下所示，地址是：https://docs.docker.com/compose/compose-file/compose-file-v2/ ：
```yml
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/ ，如下圖紅框所示：
![在這裡插入圖片描述](https://img-blog.csdnimg.cn/20191102205345834.jpg?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly94aW5jaGVuLmJsb2cuY3Nkbi5uZXQ=,size_16,color_FFFFFF,t_70)
- 因此，condition引數看似好用，但是從V3版開始的docker-compose.yml已經不再支援該引數，不能作為標準的解決方案；
### 官方推薦的方案
- 如下圖紅框所示，docker官方推薦使用 **wait-for-it.sh** 指令碼來解決問題，地址：https://docs.docker.com/compose/startup-order/ ：
![在這裡插入圖片描述](https://img-blog.csdnimg.cn/20191102213543983.jpg?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly94aW5jaGVuLmJsb2cuY3Nkbi5uZXQ=,size_16,color_FFFFFF,t_70)
- 至此，本篇已經分析了docker-compose下容器啟動順序的問題，下一篇文章[《docker-compose下的java應用啟動順序兩部曲之二：實戰》](https://blog.csdn.net/boling_cavalry/article/details/102880881)，我們用SpringCloud應用來做實戰，將其做到在docker-compose下有序啟動；
### 參考文章
- 如果您對docker容器健康檢查有興趣，可以參考以下文章：
1. [《極速體驗docker容器健康》](https://blog.csdn.net/boling_cavalry/article/details/102641942)；
2. [《Java應用在docker環境配置容器健康檢查》](https://blog.csdn.net/boling_cavalry/article/details/102649435)；

### 歡迎關注ITpub：程式設計師欣宸
> [學習路上，你不孤單，欣宸原創一路相伴...](http://blog.itpub.net/70017844/)

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

相關文章