摘要：自動構(gòu)建是美團對Docker的首次應(yīng)用草姻。解決方案可以概括為三點：把構(gòu)建過程放到Docker容器鹃骂；提交代碼時自動觸發(fā)構(gòu)建璧南；發(fā)布時直接使用構(gòu)建好的應(yīng)用包逸贾。方案很好地解決了三個問題：資源競爭、環(huán)境沖突和安全隱患舔痪。
自動構(gòu)建系統(tǒng)是從美團的自動部署系統(tǒng)發(fā)展出來的一個新功能寓调。每當(dāng)開發(fā)人員提交代碼到倉庫后，系統(tǒng)會自動根據(jù)開發(fā)人員定制的構(gòu)建配置辙喂，啟動新的Docker容器捶牢，在其中對源代碼進行構(gòu)建（build），包括編譯（如Java巍耗、C++和Go）秋麸、預(yù)處理（如JavaScript和CSS）、壓縮（如圖片）等操作炬太，生成最終需要上線的程序包灸蟆。
背景和問題
美團的代碼自動部署系統(tǒng)承載著美團所有業(yè)務(wù)的代碼上線工作。代碼部署系統(tǒng)一開始基于簡單的Bash腳本亲族，從一個中央主機上通過Rsync和SSH進行文件傳輸和命令執(zhí)行炒考。
圖1 代碼部署系統(tǒng)架構(gòu)圖
代碼發(fā)布系統(tǒng)經(jīng)過多番演進，增加了很多功能霎迫，但原來的中心式架構(gòu)仍然保留了下來斋枢，見圖1。發(fā)布者通過Web界面或者REST API控制中控機知给，中控機負責(zé)從Git服務(wù)拉取代碼瓤帚，構(gòu)建應(yīng)用程序包，然后通過Rsync上傳程序包到應(yīng)用集群涩赢，并用SSH執(zhí)行遠程命令戈次。
圖2 過去15個月的發(fā)布次數(shù)
自動部署系統(tǒng)為美團業(yè)務(wù)的快速發(fā)展提供了有力的支撐。由于我們采用了開發(fā)人員自助上線的方式筒扒，發(fā)布操作頻繁怯邪，工作日每日上線達上千次。圖2是過去15個月每個月的發(fā)布次數(shù)花墩。為了持續(xù)優(yōu)化發(fā)布速度悬秉，給發(fā)布人員提供良好的體驗澄步，我們把單次發(fā)布平均時間作為發(fā)布系統(tǒng)的一項重要的KPI。
然而搂捧，隨著美團業(yè)務(wù)的迅速擴張驮俗，服務(wù)增多懂缕，發(fā)布應(yīng)用數(shù)目也增多允跑，中心化的架構(gòu)的問題也凸顯了出來。
- 問題1：資源競爭
多個構(gòu)建任務(wù)同時進行搪柑，競爭中控機的資源聋丝，影響發(fā)布速度。有一次一個應(yīng)用受到同時進行的某Java類應(yīng)用發(fā)布的影響工碾，通常兩分鐘的發(fā)布變成了十多分鐘弱睦，嚴(yán)重影響發(fā)布體驗。如果出現(xiàn)事故需要回滾渊额，就是更嚴(yán)重的問題了况木。
- 問題2：環(huán)境沖突
不同應(yīng)用的構(gòu)建依賴環(huán)境在一臺發(fā)布機上，需要考慮環(huán)境沖突和隔離的問題旬迹。例如火惊，Java 1.6/1.7共存，應(yīng)用需要通過JAVA_HOME變量指定使用的Java版本奔垦，Maven 2/3也存在同樣的問題屹耐。npm的global包也需要兼容多個應(yīng)用的構(gòu)建。
- 問題3：安全隱患
應(yīng)用的構(gòu)建腳本運行在公共發(fā)布機上椿猎，腳本的Bug可能會影響到發(fā)布機的正常運行惶岭。例如某次一個構(gòu)建腳本里面的sudo service nginx reload命令，本應(yīng)是在應(yīng)用服務(wù)器上執(zhí)行的犯眠，但開發(fā)人員錯誤配置到了在發(fā)布機上執(zhí)行的構(gòu)建腳本里面按灶。
解決方案
解決上述三個問題，我們首先想到的方案自然是重構(gòu)為多臺中控機的可橫向擴展的方式筐咧。但由于某些應(yīng)用的特殊性鸯旁，改動比較麻煩，所以開始并沒有走這個方向（現(xiàn)在已實現(xiàn)多中控機）嗜浮。
那么另外一個思路：能不能把構(gòu)建過程從中控機分離出來羡亩？這個思路受到了Travis CI（https://travis-ci.org）的啟發(fā)。我們借鑒Travis CI危融，在代碼提交時自動在一個新的環(huán)境中觸發(fā)應(yīng)用的構(gòu)建畏铆。
因此，我們的解決方案可以概括為如下三點：
- 把構(gòu)建過程放到Docker容器吉殃；
- 提交代碼時自動觸發(fā)構(gòu)建辞居；
- 發(fā)布時直接使用構(gòu)建好的應(yīng)用包楷怒。
使用前配置如下：
- 在發(fā)布系統(tǒng)配置發(fā)布項（build.yml）；
- 在Stash配置自動構(gòu)建服務(wù)的URL瓦灶；
- 在私有Docker registry上傳定制鏡像（可選）鸠删。
使用過程比較簡單，主要有如下幾個步驟：
- 開發(fā)人員提交代碼到Stash贼陶；
- 觸發(fā)自動構(gòu)建刃泡；
- 自動構(gòu)建根據(jù)配置生成任務(wù)；
- 在Docker服務(wù)器上啟動容器完成構(gòu)建碉怔；
- 將構(gòu)建好的包上傳到美團云對象存儲服務(wù)（MSS）烘贴；
- 發(fā)布時從MSS拉取軟件包并發(fā)布。
每次提交代碼時會觸發(fā)自動構(gòu)建API撮胧。構(gòu)建任務(wù)放進隊列里桨踪，任務(wù)在Docker服務(wù)器執(zhí)行。當(dāng)發(fā)布時就不用再去編譯芹啥，直接拉取軟件包進行發(fā)布锻离。從圖6、圖7兩幅圖中可以看到在發(fā)布過程中直接使用了已自動構(gòu)建好的文件進行部署墓怀。
圖3 自動構(gòu)建的配置
圖4 發(fā)布系統(tǒng)的配置界面
圖5 自動構(gòu)建架構(gòu)圖
圖6 自動構(gòu)建的日志
圖7 嵌入了自動構(gòu)建日志的發(fā)布日志
為什么沒有用虛擬機汽纠？
美團的虛擬化比較徹底，自動構(gòu)建也可以用虛擬機而非容器實現(xiàn)捺疼。但虛擬機都和業(yè)務(wù)相關(guān)疏虫，會長時間保留。其次啤呼，虛擬機和CMDB深度結(jié)合卧秘，創(chuàng)建后會上報基本信息，部署Agent官扣，配置監(jiān)控項等翅敌。此外，虛擬機的創(chuàng)建是比較慢的惕蹄。綜合考慮以上幾點蚯涮，我們使用了Docker而不是虛擬機作為自動構(gòu)建的基本單元。
效果和收益
基于Docker容器的自動構(gòu)建很好地解決了之前提到的三個問題：資源競爭卖陵、環(huán)境沖突和安全隱患遭顶。構(gòu)建任務(wù)移出發(fā)布機，構(gòu)建用Docker服務(wù)器可橫向擴展泪蔫，解決了資源競爭問題棒旗。每個構(gòu)建都是獨立的鏡像，環(huán)境沖突問題不復(fù)存在撩荣。構(gòu)建腳本運行在獨立于發(fā)布機的Docker服務(wù)器上铣揉，對發(fā)布機造成的安全隱患自然就消除了饶深。
除解決了以上三個問題外，自動構(gòu)建還顯著改善了發(fā)布速度逛拱。經(jīng)統(tǒng)計敌厘，自動構(gòu)建任務(wù)的平均執(zhí)行時間是197s，而使用自動構(gòu)建應(yīng)用的平均發(fā)布時間是99s朽合。如果不使用自動構(gòu)建俱两，那么這些應(yīng)用的發(fā)布時間就是197s + 99s，大約是三百秒旁舰》婊可以看到嗡官，自動構(gòu)建把應(yīng)用的發(fā)布時間縮短了三分之二箭窜。
總結(jié)
自動構(gòu)建是美團對Docker的首次應(yīng)用。這個應(yīng)用不是為了用Docker而用Docker的衍腥，而是在解決代碼部署系統(tǒng)中的問題時磺樱，利用Docker很好地解決了我們遇到的問題。該應(yīng)用只利用了Docker最核心的容器功能婆咸，并沒有使用Docker集群管理竹捉、調(diào)度、自動擴容等高級的功能尚骄。自動構(gòu)建的場景非常適合使用Docker块差。希望本文能夠?qū)τ媱濋_始使用Docker的公司有所啟發(fā)。
