自動(dòng)構(gòu)建系統(tǒng)是從美團(tuán)的自動(dòng)部署系統(tǒng)發(fā)展出來(lái)的一個(gè)新功能。每當(dāng)開(kāi)發(fā)人員提交代碼到倉(cāng)庫(kù)后，系統(tǒng)會(huì)自動(dòng)根據(jù)開(kāi)發(fā)人員定制的構(gòu)建配置，啟動(dòng)新的Docker容器，在其中對(duì)源代碼進(jìn)行構(gòu)建（build），包括編譯（如Java、C++和Go）、預(yù)處理（如JavaScript和CSS）、壓縮（如圖片）等操作，生成最終需要上線的程序包。

背景和問(wèn)題

美團(tuán)的代碼自動(dòng)部署系統(tǒng)承載著美團(tuán)所有業(yè)務(wù)的代碼上線工作。代碼部署系統(tǒng)一開(kāi)始基于簡(jiǎn)單的Bash腳本，從一個(gè)中央主機(jī)上通過(guò)Rsync和SSH進(jìn)行文件傳輸和命令執(zhí)行。

圖1  代碼部署系統(tǒng)架構(gòu)圖

代碼發(fā)布系統(tǒng)經(jīng)過(guò)多番演進(jìn)，增加了很多功能，但原來(lái)的中心式架構(gòu)仍然保留了下來(lái)，見(jiàn)圖1。發(fā)布者通過(guò)Web界面或者REST API控制中控機(jī)，中控機(jī)負(fù)責(zé)從Git服務(wù)拉取代碼，構(gòu)建應(yīng)用程序包，然后通過(guò)Rsync上傳程序包到應(yīng)用集群，并用SSH執(zhí)行遠(yuǎn)程命令。

自動(dòng)部署系統(tǒng)為美團(tuán)業(yè)務(wù)的快速發(fā)展提供了有力的支撐。由于我們采用了開(kāi)發(fā)人員自助上線的方式，發(fā)布操作頻繁，工作日每日上線達(dá)上千次。圖2是過(guò)去15個(gè)月每個(gè)月的發(fā)布次數(shù)。為了持續(xù)優(yōu)化發(fā)布速度，給發(fā)布人員提供良好的體驗(yàn)，我們把單次發(fā)布平均時(shí)間作為發(fā)布系統(tǒng)的一項(xiàng)重要的KPI。

然而，隨著美團(tuán)業(yè)務(wù)的迅速擴(kuò)張，服務(wù)增多，發(fā)布應(yīng)用數(shù)目也增多，中心化的架構(gòu)的問(wèn)題也凸顯了出來(lái)。

問(wèn)題1：資源競(jìng)爭(zhēng)
多個(gè)構(gòu)建任務(wù)同時(shí)進(jìn)行，競(jìng)爭(zhēng)中控機(jī)的資源，影響發(fā)布速度。有一次一個(gè)應(yīng)用受到同時(shí)進(jìn)行的某Java類應(yīng)用發(fā)布的影響，通常兩分鐘的發(fā)布變成了十多分鐘，嚴(yán)重影響發(fā)布體驗(yàn)。如果出現(xiàn)事故需要回滾，就是更嚴(yán)重的問(wèn)題了。

問(wèn)題2：環(huán)境沖突
不同應(yīng)用的構(gòu)建依賴環(huán)境在一臺(tái)發(fā)布機(jī)上，需要考慮環(huán)境沖突和隔離的問(wèn)題。例如，Java 1.6/1.7共存，應(yīng)用需要通過(guò)JAVA_HOME變量指定使用的Java版本，Maven 2/3也存在同樣的問(wèn)題。npm的global包也需要兼容多個(gè)應(yīng)用的構(gòu)建。

問(wèn)題3：安全隱患
應(yīng)用的構(gòu)建腳本運(yùn)行在公共發(fā)布機(jī)上，腳本的Bug可能會(huì)影響到發(fā)布機(jī)的正常運(yùn)行。例如某次一個(gè)構(gòu)建腳本里面的sudo service nginx reload命令，本應(yīng)是在應(yīng)用服務(wù)器上執(zhí)行的，但開(kāi)發(fā)人員錯(cuò)誤配置到了在發(fā)布機(jī)上執(zhí)行的構(gòu)建腳本里面。

解決方案

解決上述三個(gè)問(wèn)題，我們首先想到的方案自然是重構(gòu)為多臺(tái)中控機(jī)的可橫向擴(kuò)展的方式。但由于某些應(yīng)用的特殊性，改動(dòng)比較麻煩，所以開(kāi)始并沒(méi)有走這個(gè)方向（現(xiàn)在已實(shí)現(xiàn)多中控機(jī)）。

那么另外一個(gè)思路：能不能把構(gòu)建過(guò)程從中控機(jī)分離出來(lái)？這個(gè)思路受到了Travis CI（https://travis-ci.org）的啟發(fā)。我們借鑒Travis CI，在代碼提交時(shí)自動(dòng)在一個(gè)新的環(huán)境中觸發(fā)應(yīng)用的構(gòu)建。

因此，我們的解決方案可以概括為如下三點(diǎn)：

把構(gòu)建過(guò)程放到Docker容器；
提交代碼時(shí)自動(dòng)觸發(fā)構(gòu)建；
發(fā)布時(shí)直接使用構(gòu)建好的應(yīng)用包。
使用前配置如下：

在發(fā)布系統(tǒng)配置發(fā)布項(xiàng)（build.yml）；
在Stash配置自動(dòng)構(gòu)建服務(wù)的URL；
在私有Docker registry上傳定制鏡像（可選）。
使用過(guò)程比較簡(jiǎn)單，主要有如下幾個(gè)步驟：

開(kāi)發(fā)人員提交代碼到Stash；
觸發(fā)自動(dòng)構(gòu)建；
自動(dòng)構(gòu)建根據(jù)配置生成任務(wù)；
在Docker服務(wù)器上啟動(dòng)容器完成構(gòu)建；
將構(gòu)建好的包上傳到美團(tuán)云對(duì)象存儲(chǔ)服務(wù)（MSS）；
發(fā)布時(shí)從MSS拉取軟件包并發(fā)布。
每次提交代碼時(shí)會(huì)觸發(fā)自動(dòng)構(gòu)建API。構(gòu)建任務(wù)放進(jìn)隊(duì)列里，任務(wù)在Docker服務(wù)器執(zhí)行。當(dāng)發(fā)布時(shí)就不用再去編譯，直接拉取軟件包進(jìn)行發(fā)布。從圖6、圖7兩幅圖中可以看到在發(fā)布過(guò)程中直接使用了已自動(dòng)構(gòu)建好的文件進(jìn)行部署。

圖3  自動(dòng)構(gòu)建的配置

圖4  發(fā)布系統(tǒng)的配置界面

圖5  自動(dòng)構(gòu)建架構(gòu)圖

圖6  自動(dòng)構(gòu)建的日志

圖7  嵌入了自動(dòng)構(gòu)建日志的發(fā)布日志
為什么沒(méi)有用虛擬機(jī)？

美團(tuán)的虛擬化比較徹底，自動(dòng)構(gòu)建也可以用虛擬機(jī)而非容器實(shí)現(xiàn)。但虛擬機(jī)都和業(yè)務(wù)相關(guān)，會(huì)長(zhǎng)時(shí)間保留。其次，虛擬機(jī)和CMDB深度結(jié)合，創(chuàng)建后會(huì)上報(bào)基本信息，部署Agent，配置監(jiān)控項(xiàng)等。此外，虛擬機(jī)的創(chuàng)建是比較慢的。綜合考慮以上幾點(diǎn)，我們使用了Docker而不是虛擬機(jī)作為自動(dòng)構(gòu)建的基本單元。

效果和收益

基于Docker容器的自動(dòng)構(gòu)建很好地解決了之前提到的三個(gè)問(wèn)題：資源競(jìng)爭(zhēng)、環(huán)境沖突和安全隱患。構(gòu)建任務(wù)移出發(fā)布機(jī)，構(gòu)建用Docker服務(wù)器可橫向擴(kuò)展，解決了資源競(jìng)爭(zhēng)問(wèn)題。每個(gè)構(gòu)建都是獨(dú)立的鏡像，環(huán)境沖突問(wèn)題不復(fù)存在。構(gòu)建腳本運(yùn)行在獨(dú)立于發(fā)布機(jī)的Docker服務(wù)器上，對(duì)發(fā)布機(jī)造成的安全隱患自然就消除了。

除解決了以上三個(gè)問(wèn)題外，自動(dòng)構(gòu)建還顯著改善了發(fā)布速度。經(jīng)統(tǒng)計(jì)，自動(dòng)構(gòu)建任務(wù)的平均執(zhí)行時(shí)間是197s，而使用自動(dòng)構(gòu)建應(yīng)用的平均發(fā)布時(shí)間是99s。如果不使用自動(dòng)構(gòu)建，那么這些應(yīng)用的發(fā)布時(shí)間就是197s + 99s，大約是三百秒。可以看到，自動(dòng)構(gòu)建把應(yīng)用的發(fā)布時(shí)間縮短了三分之二。

總結(jié)

自動(dòng)構(gòu)建是美團(tuán)對(duì)Docker的首次應(yīng)用。這個(gè)應(yīng)用不是為了用Docker而用Docker的，而是在解決代碼部署系統(tǒng)中的問(wèn)題時(shí)，利用Docker很好地解決了我們遇到的問(wèn)題。該應(yīng)用只利用了Docker最核心的容器功能，并沒(méi)有使用Docker集群管理、調(diào)度、自動(dòng)擴(kuò)容等高級(jí)的功能。自動(dòng)構(gòu)建的場(chǎng)景非常適合使用Docker。希望本文能夠?qū)τ?jì)劃開(kāi)始使用Docker的公司有所啟發(fā)。