導讀：中國五礦和阿里巴巴聯手打造的鋼鐵服務專業平臺五阿哥，通過集結阿里巴巴在大資料、電商平臺和網際網路產品技術上的優勢，為終端使用者帶來一站式採購體驗。本文是五阿哥運維技術團隊針對Docker容器技術在如何在持續交付過程中探索和實踐，目前已經將釋出部署許可權開放給應用開發的owner，實現7*24小時“一站式”的持續交付，整體提高了公司研發過程的交付能力。

前言

作為創業公司和推行DevOps工程師們來說，都遇到過這樣的問題：

1. 硬體資源利用率的問題，造成部分成本的浪費 
   在網站功能中不同的業務場景有計算型的、有IO讀寫型的、有網路型、有記憶體型的，集中部署應用就會導致資源利用率不合理的問題。比如，一個機器上部署的服務都是記憶體密集型，那麼CPU資源就都很容易浪費了。
2. 單物理機多應用無法對無法進行有效的隔離，導致應用對資源的搶佔和相互影響 
   一個物理機器跑多個應用，無法進行所使用的CPU、記憶體、程序進行限制，如果一個應用出現對資源的搶佔問題，就會引起連鎖反應，最終導致網站部分功能不可用。
3. 環境、版本管理複雜，上線部署流程缺乏，增加問題排查的複雜度 
   由於內部開發流程的不規範，程式碼在測試或者上線過程中，對一些配置項和系統引數進行隨意的調整，在釋出時進行增量釋出，一旦出現問題，就會導致測試的程式碼和線上執行的程式碼是不一致的，增加了服務上線的風險，也增加了線上服務故障排查的難度。
4. 環境不穩定，遷移成本高，增加上線風險 
   在開發過程中存在多個專案並行開發和服務的依賴問題，由於環境和版本的複雜性很高，不能快速搭建和遷移一個環境，導致無法在測試環境中無法模擬出線上的流程進行測試，很多同學在線上環境進行測試，這裡有很高的潛在風險，同時導致開發效率降低。
5. 傳統虛擬機器和物理機佔用空間大，啟動慢，管理複雜等問題 
   傳統虛擬機器和物理機在啟動過程進行載入核心，執行核心和init進行，導致在啟動過程佔用很長時間，而且在管理過程中會遇到各種各樣的管理問題。

基於Docker容器技術，運維技術團隊開發了五阿哥網站的容器雲平臺。通過容器雲平臺95%的應用服務已經實現容器化部署。這些應用支援業務按需拓展，秒級伸縮，提供與使用者友好的互動過程，規範了測試和生產的釋出流程，讓開發和測試同學從基礎的環境配置和釋出解放出來，使其更聚焦自己的專案開發和測試。 

結合五阿哥容器雲平臺和Docker容器技術的實踐，本文先介紹如何實現7*24小時“一站式”的持續交付，實現產品的上線。關於容器雲平臺的介紹，請關注：

Docker映象標準化

眾所周知，Docker的映象是分層的。對映象分層進行約定：

• 第一層是作業系統層，由CentOS/Alpine等基礎映象構成，安裝一些通用的基礎元件；
• 第二層是中介軟體層，根據不同的應用程式，安裝它們執行時需要使用到的各種中介軟體和依賴軟體包，如，nginx、tomcat等；
• 第三層是應用層，這層僅包含已經打好包的各應用程式程式碼。 
  
  圖2：Docker映象分層約定

經驗總結：如何讓自己的映象變的更小，PUSH的更快？ 

• dockerfile構建應用映象，在中介軟體層遇到一些需要安裝的軟體包時，儘可能的使用包管理工具（如yum）或以git clone方式下載原始碼包進行安裝，目的是將軟體包的copy和安裝控制在同一層，軟體部署成功後清除一些無用的rpm包或原始碼包，讓基礎映象的尺寸更小。
• Java應用映象中並沒有將jdk軟體包打入映象，將jdk部署在每臺宿主上，在執行映象時，通過掛載目錄的方式將宿主機上的java家目錄掛載至容器指定目錄下。因為它會把基礎映象撐得非常大；
• 在構建應用映象時，docker會對這兩層進行快取並直接使用，僅會重新建立程式碼出現變動的應用層，這樣就提高了應用映象的構建速度和構建成功後向映象倉庫推送的速度，從整體流程上提升了應用的部署效率。

容器的編排管理

編排工具的選型：

Rancher圖形化管理介面，部署簡單、方便， 可以與AD、LDAP、GITHUB整合，基於使用者或使用者組進行訪問控制，快速將系統的編排工具升級至Kubernetes或者Swarm，同時有專業的技術團隊進行支援，降低容器技術入門的難度。 

基於以上優點我們選擇Rancher作為我們容器雲平臺的編排工具，在對應用的容器例項進行統一的編排排程時，配合Docker-Compose元件，可以在同一時間對多臺宿主機執行排程操作。同時，在服務訪問出現峰值和低谷時，利用特有的rancher-compose.yml檔案呼叫“SCALE”特性，對應用叢集執行動態擴容和縮容，讓應用按需求處理不同的請求。https:/zhuanlan.zhihu.com/p/29093407

容器網路模型選型：

由於後端開發基於阿里的HSF框架，生產者和消費者之間需要網路可達，對網路要求比較高，需要以真實IP地址進行註冊和拉取服務。所以在選擇容器網路時，我們使用了Host模式，在容器啟動過程中會執行指令碼檢查宿主機並分配給容器一個獨立的埠，來避免衝突的問題。

持續整合與持續部署

• 持續整合， 監測程式碼提交狀態，對程式碼進行持續整合，在整合過程中執行單元測試，程式碼Sonar和安全工具進行靜態掃描，將結果通知給開發同學同時部署整合環境，部署成功後觸發自動化測試（自動化測試部分後續會更新https://zhuanlan.zhihu.com/idevops）。 
  
  圖7:持續整合示意圖

靜態掃描結果： 

• 持續部署，是一種能力，這種能力非常重要，把一個包快速部署在你想要的地方。平臺採用分散式構建、部署，master管理多個slave節點，每個slave節點分屬不同的環境。在master上安裝並更新外掛、建立job、管理各開發團隊許可權。slave用於執行job。 
  
  圖9: 持續部署架構圖

基於上述圖9架構，我們定義了持續部署規範的流程：

（1）開發同學向gitlab提交程式碼； 
（2）拉取專案程式碼和配置項檔案，執行編譯任務； 
（3）拉取基礎映象，將編譯好的應用包打入生成最新的應用映象，推送到映象倉庫； 
（4）根據當前應用及所屬環境定製化生成docker-compose.yml檔案，基於這個檔案執行rancher-compose命令，將應用映象部署到預發環境（釋出生產前的測試環境，相關配置、服務依賴關係和生產環境一致）。 
（6）預發環境測試通過後將應用映象部署至線上環境，測試結果通知後端測試同學。

容器的執行管理

應用容器現在已經部署到線上環境，那麼在整個容器的生命週期中，還需要解決下面兩個問題：

（1） 如何儲存應用程式產生的執行日誌和其它業務日誌； 
（2） 如何在後端服務出現變化後nginx能夠自動發現並完成配置更新。

日誌管理

容器在執行時會在只讀層之上建立讀寫層，所有對應用程式的寫操作都在這層進行。當容器重啟後，讀寫層中的資料（包含日誌）也會一併被清除。雖然可以通過將容器中日誌目錄掛載到宿主機解決此類問題，但當容器在多個宿主機間頻繁漂移時，每個宿主機上都會有留存應用名的部分日誌，增加了開發同學檢視、排查問題的難度。

綜上所屬，日誌服務平臺作為五阿哥網站日誌倉庫，將應用執行過程中產生的日誌統一儲存，並且支援多種方式的查詢操作。 

通過在日誌服務的管理介面配置日誌採集路徑，在容器中部署agent把應用日誌統一投遞到logstore中，再在logstore中配置全文索引和分詞符，以便開發同學能夠通過關鍵字搜尋、查詢想要的日誌內容。

經驗總結：如何避免日誌的重複採集問題？

• 日誌服務agent需要在配置檔案“ilogtail_config.json”中增加配置引數“check_point_filename”，指定checkpoint檔案生成的絕對路徑，並且將此路徑掛載至宿主機目錄下，確保容器在重啟時不會丟失checkpoint檔案，不會出現重複採集問題。

服務的註冊

etcd是一個具備高可用性和強一致性的鍵值儲存倉庫，它使用類似於檔案系統的樹形結構，資料全部以“/”開頭。etcd的資料分為兩種型別：key和directories，其中key下儲存單獨的字串值，directories下則存放key的集合或者其他子目錄。

在五阿哥環境中，每個向etcd註冊的應用服務，它們的根目錄都以

”/${APP_NAME}_${ENVIRONMENT}”

命名。根目錄下儲存每個應用例項的Key資訊，它們都以“IP−{PORT}”的方式命名。

下圖是使用上述約定，儲存在etcd上某應用例項的資料結構：

可以看到我是使用get方法向etcd傳送請求的，請求的是部署在預發環境（PRE）的搜尋服務（search）；在它的根目錄“/search_PRE”下，僅儲存了一個應用例項的資訊，這個例項的key是“172.18.100.31-86”；對應的value是“172.18.100.31:86‘’，整個註冊過程是這樣的：

① 通過程式碼為容器應用程式生成隨機埠，和宿主機正在使用的埠進行比對，確保埠沒有衝突後寫入程式配置檔案； 
② 把通過python和etcd模組編寫的服務註冊工具整合在指令碼中，將IP地址和上一步獲取的隨機埠以引數的方式傳遞給服務註冊工具； 
③ 待應用程式完全啟動後，由服務註冊工具以約定好的資料結構將應用例項的寫入etcd叢集，完成服務註冊工作； 
④ 容器定時向etcd傳送心跳，報告存活並重新整理ttl時間； 
⑤ 容器指令碼捕獲rancher傳送至應用例項的singnal terminal訊號，在接收到訊號後向etcd傳送delete請求刪除例項的資料。

注：在ttl基礎上增加主動清除功能，在服務正常釋放時，可以立刻清除etcd上註冊資訊，不必等待ttl時間。

經驗總結：容器在重啟或者意外銷燬時，讓我們一起看一下這個過程中容器和註冊中心都做了什麼事情？

應用在註冊是攜帶key 和value時攜帶了ttl超時屬性，就是考慮到當服務叢集中的例項宕機後，它在etcd中註冊的資訊也隨之失效，若不予清除，失效的資訊將會成為垃圾資料被一直儲存，而且配置管理工具還會把它當做正常資料讀取出來，寫入web server的配置檔案中。要保證儲存在etcd中的資料始終有效，就需要讓etcd主動釋放無效的例項資訊，來看一下注冊中心重新整理的機制，程式碼直接奉上：

#!/usr/bin/env python
import etcd
import sys
arg_l=sys.argv[1:]
etcd_clt=etcd.Client(host='172.18.0.7')
def set_key(key,value,ttl=10):
        try:
                return etcd_clt.write(key,value,ttl)
        except TypeError:
                print 'key or vlaue is null'
def refresh_key(key,ttl=10):
        try:
                return etcd_clt.refresh(key,ttl)
        except TypeError:
                print 'key is null'
def del_key(key):
        try:
                return etcd_clt.delete(key)
        except TypeError:
                print 'key is null'
if arg_l:
        if len(arg_l) == 3:
                key,value,ttl=arg_l
                set_key(key,value,ttl)
        elif len(arg_l) == 2:
                key,ttl=arg_l
                refresh_key(key,ttl)
        elif len(arg_l) == 1:
                key=arg_l[0]
                del_key(key)
        else:
                raise TypeError,'Only three parameters are needed here'
else:
        raise Exception('args is null')

服務的發現

confd是一個輕量級的配置管理工具，支援etcd作為後端資料來源，通過讀取資料來源資料，保證本地配置檔案為最新；不僅如此 ，它還可以在配置檔案更新後，檢查配置檔案語法有效性，以重新載入應用程式使配置生效。這裡需要說明的是，confd雖然支援rancher作為資料來源，但考慮易用性和擴充套件性等原因，最終我們還是選擇了etcd。

和大多數部署方式一樣，我們把confd部署在web server所在的ECS上，便於confd在監測到資料變化後及時更新配置檔案和重啟程式。confd的相關配置檔案和模板檔案部署在預設路徑/etc/confd下，目錄結構如下：

/etc/confd/
├── conf.d
├── confd.toml
└── templates

confd.toml是confd的主配置檔案，使用TOML格式編寫，因為我們etcd是叢集部署，有多個節點，而我又不想把confd的指令搞的又臭又長，所以將interval、nodes等選項寫到了這個配置檔案裡。

cond.d目錄存放web server的模板配置原始檔，也使用TOML格式編寫。該檔案用於指定應用模板配置檔案路徑（src）、應用配置檔案路徑（dest）、資料來源的key資訊（keys）等。

templates目錄存放web server下每個應用的模板配置檔案。它使用Go支援的text/template語言格式進行編寫。在confd從etcd中讀取到最新應用註冊資訊後，通過下面的語句寫入模板配置檔案中：

{{range getvs "/${APP_NAME}/*"}}
        server {{.}};
{{end}}

通過supervisor管理confd程序。confd在執行後會每隔5秒對etcd進行輪詢，當某個應用服務的K/V更新後，confd會讀取該應用儲存在etcd中的資料，寫入到模板配置檔案中，生成這個應用配置檔案，最後由confd將配置檔案寫入到目標路徑下，重新載入nginx程式使配置生效。（程式碼請參考：https://zhuanlan.zhihu.com/idevops）

總結

本文是五阿哥運維技術團隊針對Docker容器技術在如何在持續交付過程中探索和實踐，目前已經將釋出部署許可權開放給應用開發的owner，實現7*24小時“一站式”的持續交付，整體提高了公司的研發過程的交付能力。

接下來會不斷優化持續交付過程中遇到的各種場景，逐漸完善容器雲平臺，同時會將容器雲平臺各種功能，總結的經驗和教訓不斷分享給大家，給大家在工作中一些參考，避免走重複的“彎路”。