DockOne微信分享（一三五）：求取一份極致的簡單：海量應用容器化改造之路

本文講的是DockOne微信分享（一三五）：求取一份極致的簡單：海量應用容器化改造之路【編者的話】公司內部近千個應用，從需求、開發、測試、釋出及後期運維都是各自為營，沒有一個統一的平臺來標準化應用的整個流程，由此，設計一個這樣的標準化平臺就極其迫切，同時為了享受當前容器化技術帶來的福利，我們決定完全基於容器技術來進行全面的應用容器化改造，以下就是我們團隊在平臺研發及應用容器化改造過程的一些經歷和思考向大家分享一下，思慮不周之處，望大家斧正。

【3 天燒腦式基於Docker的CI/CD實戰訓練營 | 北京站】本次培訓圍繞基於Docker的CI/CD實戰展開，具體內容包括：持續整合與持續交付（CI/CD）概覽；持續整合系統介紹；客戶端與服務端的 CI/CD 實踐；開發流程中引入 CI、CD；Gitlab 和 CI、CD 工具；Gitlab CI、Drone 的使用以及實踐經驗分享等。

平臺架構

1. Git Repository：管理應用原始碼；
2. Maven Repository：管理應用依賴的外部框架包及內部二方包；
3. Docker Registry：管理各業務映象依賴的基礎映象及業務映象；
4. Config Center：基於ZK做的實現，管理應用本身的配置檔案、Leader控制、分散式鎖等；
5. Rabbit MQ：用於解耦各應用之間的通訊；
6. DB：用於儲存應用的一些管理資料和配置資料等；
7. Kubernetes Cluster：供業務系統執行的一個統一的環境，所有環境的應用全部容器化；
8. Publish Service：用於管理公司應用，包括使用者許可權的管理、應用後設資料的管理、應用Kubernetes配置後設資料的管理、應用的釋出、自動擴縮容、手工擴縮容、手工回滾等；
9. Build Service：用於業務映象的構建及推送：收到Publish Service傳送的構建訊息後，從Git Repository拉取應用原始碼，經過編譯、打包、部署、映象構建及推送到Docker Registry。

構建服務

構建服務依賴的環境主要包括JDK、Git、Maven、Docker，主要功能包括應用原始碼檢出、編譯、打包、部署及Dockerfile生成、映象構建、推送幾個階段，整個過程我們編寫了一個sh指令碼，由這個指令碼來完成整個過程。

1. 原始碼檢出：接收到釋出傳送的構建訊息時，由JDK中的Process物件來啟動這個sh指令碼檔案，進行應用原始碼檢出，檢出來過程有任何異常，傳送失敗訊息給釋出服務；
2. 編譯：呼叫Maven的mvn compile命令進行編譯，編譯過程中有任務異常，傳送失敗訊息給釋出服務；
3. 打包：呼叫Maven的mvn package命令進行打包，打包過程中有任務異常，傳送失敗訊息給釋出服務；
4. 呼叫Maven的mvn deploy命令將打好的包部署到內部Maven倉庫，部署過程中有任務異常，傳送失敗訊息給釋出服務；如果是二方庫應用，流程到些就完成了，如果是非二方庫應用則繼續5、6、7三步；
5. Dockerfile生成：Dockerfile每次都是動態生成的，Dockerfile的內部結構基本上比較確定，包括FROM基礎映象、ADD第3步打好的包、EXPOSE埠、ENTRYPOINT java –jar、CMD一些引數；
6. 映象構建：呼叫”docker build –t 內部Docker倉庫/產品線名/應用名:標籤 .”進行映象構建，構建過程中有任務異常，傳送失敗訊息給釋出服務；
7. 映象推送：首先登入內部Docker倉庫，登入成功後呼叫”docker push 內部Docker倉庫/產品線名/應用名:標籤”進行映象推送。

釋出服務

釋出服務本身比較大一些，包括使用者許可權管理、需求管理、產品線管理、應用管理、線上文件管理、缺陷管理、變更管理、Kubernetes應用配置管理、釋出管理等，在這裡主要介紹一下應用管理、Kubernetes應用配置管理、應用釋出管理三個模組：

1. 應用管理：應用管理主要維護了應用本身的一些後設資料，還一些輔助配置，像編譯應用時使用的JDK版本、生成Dockerfile時使用的基本映象等；
2. Kubernetes應用配置管理：這部分的配置是和應用直接掛鉤的，最終儲存下來的是Kubernetes的REST介面能識別的一個物件JSON串。這部分主要維護了Kubernetes的Deployment、Service、HorizontalPodAutoscaler、Scale四個物件，對Service、HorizontalPodAutoscaler兩個物件都新增了啟用、停用開關，Service物件預設開啟，而HPA物件預設關閉，我們使用Scale物件主要用於對某些應用進行手工擴縮容，來解決一些特殊場景的需求；圖示如下：
   
   
   
3. 應用釋出管理：每次釋出是針對某個應用的程式碼分支進行釋出，首先由構建服務將對應分支的映象構建並推送完成，對應應用還要提前做Kubernetes相關的配置，然後呼叫我們進行一次薄封裝後的Kubernetes的REST介面：pulish（k8s-master:port，Kubernetes應用配置生成的JSON串）進行應用的釋出，釋出之後還要進行釋出狀態的監控，要讓每個應用的應用負責人清楚看到這次釋出的結果。

改造過程中的問題

在這次改造過程遇到了很多千奇百怪的問題，在這裡介紹幾個印象比較深的問題及解決辦法：

1. 在每次重新發布，更新Kubernetes的Service物件時，報無法更新的錯誤，查官方文件獲知更新Service物件時，還要通過GET請求獲取resourceVersion、clusterIP兩個值put進來才可以；
2. 在使用Logstash將採集的日誌輸出到HDFS時，開始使用WebHDFS外掛，配置是完全按照官方文件的配置，可是一直報一個Error錯誤，最後我們改用HttpFS外掛解決的；
3. 最初構建服務使用JDK7進行編譯打包的，後來發現別的很多應用是在JDK 8下開發的，所以這就要求構建服務要能提供JDK多版本編譯環境，我們當時是用Maven的toolchains外掛解決的；
4. 在Kubernetes環境，有些時候會出現某些pod刪除不掉，到現在為止沒想到太好的辦法，我們暫時是靠到殺掉Node上的程式解決的。

Q&A

Q：構建映象用的什麼技術？

A：我們使用的是Docker自身提供的docker build命令進行映象構建的。

Q：Config Center能否詳細說一下？

A：我們使用Config Center主要來管理應用自身的配置檔案，應該在啟動前首先拽下自己的配置檔案；還有就是對應用進行Leader控制，因為應用可能會跑多個例項的，像定時任務類的功能，在同一個時間點只能其中一個例項生效。

Q： 如何動態生成Dockerfile，如何在Docker映象裡配置JVM引數？

A：Dockerfile檔案：我們是使用sh指令碼生成的，將內容>>Dockerfile中；JVM引數是在應用中配置的，傳送構建訊息時，作為訊息內容送過去。

Q： Deployment 滾動更新如何設定間隔時間呢？

A：Deployment物件有個minReadySeconds屬性就是來解決這個問題的。

Q： Logstash的日誌為啥是傳送到HDFS而不是ES？有什麼考慮麼？

A：我們將Logstash採集到的日誌輸出到兩個地方：ES、HDFS，輸出到ES直接在Kibana上搜尋到，而輸出到HDFS便於在Kibana上面將日誌檔案進行下載下來。

Q：Docker Registry的在garbage collect時怎麼保證高可用？

A：我們使用的由VMware公司中國團隊開源的Harbor，無論安全、效率、可用性方面都提供了很強的保障了。

Q：kubectl set image的時候 能不能限制 每變更一個容器，再保證http訪問正常的前提下，再變更下一個容器 。畢竟有的服務啟動時間超過30秒，對外的服務忍受不了信麼久的不可訪問時間的？

A：這個可以直接藉助Kubernetes的RollingUpdate功能就可以做了。

Q：Dockerfile動態生成怎麼做的，用的是什麼生成工具？

A：使用sh指令碼生成,將內容>>Dockerfile中去可以了。

Q：統一的流程給實際的生產帶來了怎樣的好處能否介紹一下？

A：流程統一後，像原始碼管理、日誌採集及搜尋、應用釋出，應用滾動升級等就不需要應用本身來管了，這樣各業務系統本身就會更加專注於自身的業務功能了。

以上內容根據2017年08月01日晚微信群分享內容整理。分享人楊新倫，上海鋼聯產品研發中心高階工程師，現主要負責公司內部應用的容器化改造等相關的後臺研發工作。 DockOne每週都會組織定向的技術分享，歡迎感興趣的同學加微信：liyingjiesa，進群參與，您有想聽的話題或者想分享的話題都可以給我們留言。

原文釋出時間為：2017-08-06

本文作者：楊新倫

本文來自雲棲社群合作伙伴Dockerone.io，瞭解相關資訊可以關注Dockerone.io。

原文標題：DockOne微信分享（一三五）：求取一份極致的簡單：海量應用容器化改造之路