自動構建系統是從美團的自動部署系統發展出來的一個新功能。每當開發人員提交代碼到倉庫後，系統會自動根據開發人員定制的構建配置，啟動新的 Docker容器，在其中對源代碼進行構建（build），包括編譯（如Java、C++和Go）、預處理（如JavaScript和CSS）、壓縮（如 圖片）等操作，生成最終需要上線的程序包。
背景和問題
美團的代碼自動部署系統承載著美團所有業務的代碼上線工作。代碼部署系統一開始基於簡單的Bash腳本，從一個中央主機上通過Rsync和SSH進行文件傳輸和命令執行。
圖1 代碼部署系統架構圖
代碼發布系統經過多番演進，增加了很多功能，但原來的中心式架構仍然保留了下來，見圖1。發布者通過Web界面或者REST API控制中控機，中控機負責從Git服務拉取代碼，構建應用程序包，然後通過Rsync上傳程序包到應用集群，並用SSH執行遠程命令。
圖2 過去15個月的發布次數
自 動部署系統為美團業務的快速發展提供了有力的支撐。由於我們采用了開發人員自助上線的方式，發布操作頻繁，工作日每日上線達上千次。圖2是過去15個月每 個月的發布次數。為了持續優化發布速度，給發布人員提供良好的體驗，我們把單次發布平均時間作為發布系統的一項重要的KPI。
然而，隨著美團業務的迅速擴張，服務增多，發布應用數目也增多，中心化的架構的問題也凸顯了出來。
多個構建任務同時進行，競爭中控機的資源，影響發布速度。有一次一個應用受到同時進行的某Java類應用發布的影響，通常兩分鐘的發布變成了十多分鐘，嚴重影響發布體驗。如果出現事故需要回滾，就是更嚴重的問題了。
不同應用的構建依賴環境在一台發布機上，需要考慮環境沖突和隔離的問題。例如，Java 1.6/1.7共存，應用需要通過JAVA_HOME變量指定使用的Java版本，Maven 2/3也存在同樣的問題。npm的global包也需要兼容多個應用的構建。
應用的構建腳本運行在公共發布機上，腳本的Bug可能會影響到發布機的正常運行。例如某次一個構建腳本裡面的sudo service nginx reload命令，本應是在應用服務器上執行的，但開發人員錯誤配置到了在發布機上執行的構建腳本裡面。
解決方案
解決上述三個問題，我們首先想到的方案自然是重構為多台中控機的可橫向擴展的方式。但由於某些應用的特殊性，改動比較麻煩，所以開始並沒有走這個方向（現在已實現多中控機）。
那麼另外一個思路：能不能把構建過程從中控機分離出來？這個思路受到了Travis CI（https://travis-ci.org）的啟發。我們借鑒Travis CI，在代碼提交時自動在一個新的環境中觸發應用的構建。
因此，我們的解決方案可以概括為如下三點：
使用前配置如下：
使用過程比較簡單，主要有如下幾個步驟：
每次提交代碼時會觸發自動構建API。構建任務放進隊列裡，任務在Docker服務器執行。當發布時就不用再去編譯，直接拉取軟件包進行發布。從圖6、圖7兩幅圖中可以看到在發布過程中直接使用了已自動構建好的文件進行部署。
圖3 自動構建的配置
圖4 發布系統的配置界面
圖5 自動構建架構圖
圖6 自動構建的日志
圖7 嵌入了自動構建日志的發布日志
為什麼沒有用虛擬機？
美 團的虛擬化比較徹底，自動構建也可以用虛擬機而非容器實現。但虛擬機都和業務相關，會長時間保留。其次，虛擬機和CMDB深度結合，創建後會上報基本信 息，部署Agent，配置監控項等。此外，虛擬機的創建是比較慢的。綜合考慮以上幾點，我們使用了Docker而不是虛擬機作為自動構建的基本單元。
效果和收益
基 於Docker容器的自動構建很好地解決了之前提到的三個問題：資源競爭、環境沖突和安全隱患。構建任務移出發布機，構建用Docker服務器可橫向擴 展，解決了資源競爭問題。每個構建都是獨立的鏡像，環境沖突問題不復存在。構建腳本運行在獨立於發布機的Docker服務器上，對發布機造成的安全隱患自 然就消除了。
除解決了以上三個問題外，自動構建還顯著改善了發布速度。經統計，自動構建任務的平均執行時間是197s，而使用自動構建應用 的平均發布時間是99s。如果不使用自動構建，那麼這些應用的發布時間就是197s + 99s，大約是三百秒。可以看到，自動構建把應用的發布時間縮短了三分之二。
總結
自動構建是美團對 Docker的首次應用。這個應用不是為了用Docker而用Docker的，而是在解決代碼部署系統中的問題時，利用Docker很好地解決了我們遇到 的問題。該應用只利用了Docker最核心的容器功能，並沒有使用Docker集群管理、調度、自動擴容等高級的功能。自動構建的場景非常適合使用 Docker。希望本文能夠對計劃開始使用Docker的公司有所啟發。
原文：http://www.csdn.net/article/2015-05-18/2824699
