作者 徐桂林

1. 背景

在過去幾年里，社交、移動和云計算深刻改變了整個互聯(lián)網(wǎng)的格局。作為設(shè)計軟件領(lǐng)域的全球領(lǐng)導(dǎo)廠商，Autodesk也與2009年正式開始從傳統(tǒng)桌面設(shè)計軟件提供商向在線服務(wù)、協(xié)作和移動端設(shè)計轉(zhuǎn)型。在這次轉(zhuǎn)型中，公司充分利用現(xiàn)代云計算的巨大優(yōu)勢給客戶帶來了大大超過傳統(tǒng)桌面軟件的處理能力、用戶體驗和性價比。其中AWS是目前公司服務(wù)的主要運(yùn)行平臺，每年在此投入千萬美金級別。

1.1. 傳統(tǒng)軟件交付的挑戰(zhàn)

在過去的30多年里，Autodesk擁有了非常多的桌面設(shè)計軟件（如AutoCAD，Maya，3dsMax等）。由于設(shè)計軟件經(jīng)常需要處理超大的數(shù)據(jù)集合（如整個上海中心的設(shè)計模型）和極其復(fù)雜的運(yùn)算邏輯（如阿凡達(dá)電影畫面的繪制），其軟件尺寸一般都比較大（GB級別）。以前，客戶基本都是通過互聯(lián)網(wǎng)下載、快遞或者分銷商獲得軟件安裝包，整個過程比較耗時。另外，軟件的升級、安裝和維護(hù)也是一個非常大的工作量（一些大的設(shè)計公司要購買上千份軟件拷貝）。盡管公司軟件已經(jīng)支持基于應(yīng)用程序虛擬化的集中管理模式，但它還是有如前期基礎(chǔ)設(shè)施建設(shè)成本大，服務(wù)能力缺乏彈性，仍需要專職運(yùn)維人員等明顯的缺點(diǎn)。所以，提升軟件交付的用戶體驗成為我們必須要面對的一個問題。

如大多數(shù)人所猜測，SaaS成為我們的第一個嘗試方向。在2006年，Autodesk實驗室開始嘗試以SaaS提供設(shè)計軟件服務(wù)的可能性，并且取得了不錯的成績。但是，目前SaaS應(yīng)用仍然面臨著瀏覽器能力限制、大數(shù)據(jù)傳輸慢等諸多問題，無法給專業(yè)設(shè)計師提供傳統(tǒng)桌面軟件一樣的體驗和設(shè)計能力。

1.2. 云計算帶來的新可能

隨著云計算的興起，以AWS為代表的基礎(chǔ)設(shè)施云提供商讓我們有可能以一種全新的方法去解決這個問題。我們可以利用基礎(chǔ)設(shè)施云的強(qiáng)大后臺來幫助用戶運(yùn)行虛擬化的軟件實例。用戶無需下載、安裝和維護(hù)這些軟件，只需要鏈接到互聯(lián)網(wǎng)上就可以在線使用我們的軟件。而且按需付費(fèi)以降低使用成本?；诖耍珹utodesk實驗室在2009年開始這個嘗試（注：該服務(wù)已經(jīng)于2013年成為公司云平臺產(chǎn)品的一部分），并選擇了AWS做作為我們的后臺云服務(wù)提供商。選擇AWS有下面的幾個原因：

??需要基礎(chǔ)設(shè)施云（IaaS）?，F(xiàn)在的平臺云（PaaS）大部分都是為Web服務(wù)準(zhǔn)備的，并不適合我們運(yùn)行虛擬化實例的要求。

??需要強(qiáng)大的彈性運(yùn)算能力。Autodesk設(shè)計軟件對于計算的需求都很大，而計算能力的成本不低。所以，彈性計算能力能讓我們很好的控制成本。AWS EC2在這方面非常符合我們的需求。

??需要豐富的服務(wù)。除了運(yùn)算能力，我們還需要給用戶提供海量設(shè)計數(shù)據(jù)的存儲，快速的數(shù)據(jù)訪問，安全的訪問控制等。AWS云服務(wù)在這方便服務(wù)非常完備，而且相互集成很容易。

??需要穩(wěn)定的服務(wù)。AWS EC2能夠提供超過99.5%的彈性計算可用率，能為我們建立可靠服務(wù)提供堅實的基礎(chǔ)設(shè)施。

??需要全球化部署。Autodesk是一個在全球提供軟件、服務(wù)的公司，所以我們希望基礎(chǔ)設(shè)施提供商也能全球布局。而AWS已經(jīng)在全球建立多個數(shù)據(jù)中心。

2. 自動化部署

在完成服務(wù)的基本實現(xiàn)并上線服務(wù)后，整個后臺的維護(hù)和部署成本在不斷加大。尤其考慮到我們需要高頻（每個月更新一次）、多地（多個AWS數(shù)據(jù)中心）部署服務(wù)并同時需要維持高的服務(wù)可用性，構(gòu)建一個自動化的部署系統(tǒng)成為必須要做的事情。

2.1. 設(shè)定目標(biāo)

作為一個運(yùn)行在AWS上的服務(wù)，我們在設(shè)計之初就開始思考AWS給自動化部署帶來的新可能和挑戰(zhàn)。在我們看來，針對AWS上服務(wù)的自動化部署需要特別關(guān)注到下面的一些特點(diǎn)：

??基礎(chǔ)設(shè)施的服務(wù)化。在AWS中，你可以利用類似Cloud Formation服務(wù)在很短時間（幾分鐘）獲取你所要的所有基礎(chǔ)設(shè)施（包括運(yùn)算、存儲、網(wǎng)絡(luò)、IO等），而這些基礎(chǔ)設(shè)施已經(jīng)按照你的要求自動配置、連接好。所以，我們可以讓自動化部署把基礎(chǔ)設(shè)施的管理也包括進(jìn)來，而這在傳統(tǒng)的數(shù)據(jù)中心模式下很難實現(xiàn)。

??支持彈性資源。因為需要支持彈性，整個服務(wù)要在運(yùn)行時動態(tài)加入新的基礎(chǔ)設(shè)施，如計算單元等。自動化部署系統(tǒng)需要能讓新加入的基礎(chǔ)設(shè)施立馬投入服務(wù)。

??保護(hù)數(shù)據(jù)更為重要。在傳統(tǒng)的數(shù)據(jù)中心，我們可以讓部署完全在內(nèi)部網(wǎng)絡(luò)完成，在確認(rèn)好所有的安全配置后再上線。但是AWS是一個公有云服務(wù)，你的所有部署其實是在公有網(wǎng)絡(luò)上完成的。所以，我們必須在自動化部署中充分考慮到數(shù)據(jù)安全的問題。

結(jié)合上面的特點(diǎn)、DevOps的普遍實踐和項目的實際情況，我們給整個自動化部署系統(tǒng)定下了下面的目標(biāo)：

1. 一鍵式部署：必須盡可能的自動化所有部署過程，包括基礎(chǔ)設(shè)施的創(chuàng)建和部署。

2. 多環(huán)境支撐：必須能夠適應(yīng)于Production、Staging和Development環(huán)境。

3. 無服務(wù)中斷：必須能夠無縫的進(jìn)行服務(wù)升級、切換。

4. 隨時可回滾：必須可以很容易的回滾到前面的版本以處理意外問題。

5. 安全性檢測：必須在確認(rèn)部署環(huán)境的安全設(shè)置已經(jīng)滿足條件后才開始做部署工作。

2.2. 整體架構(gòu)

在確定目標(biāo)后，我們進(jìn)行了技術(shù)選型，希望能夠找到既很好支持AWS相關(guān)自動化操作，又能集成DevOps優(yōu)秀實踐的方案（注：那時AWS還沒有推出OpsWorks服務(wù)）。但最后并沒有找到合適的方案，于是決定自己來實現(xiàn)整個自動化部署系統(tǒng)。經(jīng)過幾輪的改進(jìn)和實現(xiàn)，現(xiàn)在的自動化部署系統(tǒng)整體結(jié)構(gòu)如下：

圖1：自動化部署系統(tǒng)整體架構(gòu)

類似于傳統(tǒng)的自動化部署，我們也同樣有開發(fā)分支和發(fā)布分支，并與持續(xù)構(gòu)建系統(tǒng)對接。當(dāng)開發(fā)人員提交代碼后，相應(yīng)的構(gòu)建就會在代碼所在的分支自動觸發(fā)。在完成代碼編譯和集成的自動化測試（目前主要是單元測試）后，將產(chǎn)生相應(yīng)部署組件并存放在構(gòu)建系統(tǒng)中（目前，每個構(gòu)建會產(chǎn)生所有的系統(tǒng)組件并擁有同樣的版本號）。至此，整個構(gòu)建過程完成。

為了支持多環(huán)境部署和安全隔離，我們使用兩個獨(dú)立的AWS賬號來運(yùn)行不同的環(huán)境。其中開發(fā)環(huán)境在一個ＡＷＳ賬戶內(nèi)，只部署開發(fā)分支的構(gòu)建。而生產(chǎn)系統(tǒng)則在另外一個AWS賬戶中，其下運(yùn)行Prod/Staging兩組環(huán)境。發(fā)布分支永遠(yuǎn)只會向Staging環(huán)境部署并在完成最后驗證測試后與當(dāng)前Prod環(huán)境進(jìn)行熱切換，從而達(dá)到無服務(wù)中斷的目的。

2.3. 一鍵部署流程

在完成自動化持續(xù)構(gòu)建后，我們就可以部署其中的任意版本。當(dāng)部署某一構(gòu)建版本時（無論開發(fā)分支還是發(fā)布分支），整個流程如下：

圖2：一鍵式部署流程

??觸發(fā)“一鍵部署”命令：在構(gòu)建系統(tǒng)中選擇好要部署的分支和版本，直接一鍵點(diǎn)擊觸發(fā)命令。

??上傳部署文件到S3：如圖1所示，部署組件是在運(yùn)行時動態(tài)下載安裝。AWS S3提供在線存儲并能夠方便的下載到EC2實例中，所以把部署組件上傳到S3中最合適不過。為了支持多版本并存和部署回滾，所有上傳到S3的部署組件都按版本號分文件夾存儲。

??獲取當(dāng)前部署環(huán)境的配置文件：部署環(huán)境配置文件存在相應(yīng)AWS賬戶下的S3中。它定義了當(dāng)前AWS賬戶下面的部署配置，包括需要部署的數(shù)據(jù)中心列表，每個數(shù)據(jù)中心下面的基礎(chǔ)設(shè)施描述（Cloud Formation Stack）。由于Prod/Staging環(huán)境都在同一個AWS賬戶下，每個數(shù)據(jù)中心都會有兩組Cloud Formation Stack配置（分別用于Prod和Staging環(huán)境）。部署系統(tǒng)會選擇當(dāng)前Staging環(huán)境的Cloud Formation Stack作為下一步的部署目標(biāo)。

??初始化部署目標(biāo)基礎(chǔ)設(shè)施：根據(jù)當(dāng)前選中的Cloud Formation Stack初始化整個基礎(chǔ)設(shè)施，包括啟動相應(yīng)的EC2實例，綁定Elastic IPs等。

??運(yùn)行部署環(huán)境：在整個基礎(chǔ)設(shè)施運(yùn)行起來后，EC2實例第一步就是自動做運(yùn)行時部署（利用操作系統(tǒng)的啟動腳本實現(xiàn)）。具體運(yùn)行時部署細(xì)節(jié)如下：

圖3：運(yùn)行時部署

??EC2實例在完成整個自動化部署中要及時進(jìn)行有效性檢測，如檢測下載組件包是否完整正確，組件安裝是否成功，期望的服務(wù)是否可以正確訪問等。在完成所有部署和有效性檢測后方加入的正式服務(wù)系統(tǒng)并處理用戶請求，否則及時報告運(yùn)維團(tuán)隊進(jìn)行處理。

2.4. 為什么選擇運(yùn)行時部署

看到上面部署流程，相信很多人會問一個問題：AWS不是可以通過虛擬機(jī)鏡像（AMI）來啟動EC2實例，為什么不把上面的部署組件直接燒入AMI？這樣在EC2實例啟動后就直接使用而無需做運(yùn)行時部署。其實，我們的最初解決方案就是把部署組件直接燒入AMI，但很快就發(fā)現(xiàn)了這種方案的局限：

部署組件的變化是非常頻繁的，尤其是在發(fā)布前，一天都能夠產(chǎn)生上十次的變化。這就意味著自動部署系統(tǒng)可能需要頻繁產(chǎn)生AMI。而AMI的創(chuàng)建過程并不快（10分鐘~1小時），并且過多的AMI也會造成管理問題和額外的存儲成本。

作為一個平臺項目，各個產(chǎn)品會在我們的平臺上運(yùn)行。我們希望提供給各個產(chǎn)品部門的基本AMI是平臺版本無關(guān)的。這樣產(chǎn)品部門在基本AMI基礎(chǔ)上部署它們產(chǎn)品并重新生成的產(chǎn)品AMI也是平臺版本無關(guān)的。于是產(chǎn)品AMI可以不做任何修改就能夠快速采用最新的平臺版本。具體如下圖所示：

圖4：自動化部署中的AMIs

為了保證圖4中的基本AMI和產(chǎn)品AMI是平臺版本無關(guān)，我們就需要保證燒入AMI的所有部分都是能夠獨(dú)立于平臺版本的。但是，啟動腳本需要做平臺組件的運(yùn)行時部署，顯然這個運(yùn)行時部署腳本也會隨著平臺更新不斷變化，所以我們無法直接把整個運(yùn)行時部署腳本放到啟動腳本中。針對這個問題，我們的解決方案就是把整個運(yùn)行時部署腳本分成兩部分。一部分做平臺組件的安裝、檢測工作，并隨安裝組件存到S3中，而另外一部分只做基本不會改變的事情（下載平臺組件包并調(diào)用自動化部署腳本）并設(shè)置為操作系統(tǒng)的啟動腳本。這也是圖3中啟動腳本和自動化部署分開兩部分的原因。

正是因為采取了上面的AMI生成、管理策略，我們的產(chǎn)品部門基本上不用太頻繁的更新它們產(chǎn)品的AMIs（除非產(chǎn)品自身有更新），真正做到平臺版本和產(chǎn)品版本的去耦合，極大的降低了運(yùn)維成本。

2.5. 運(yùn)行時版本選擇與回滾

由于產(chǎn)品AMI是平臺版本獨(dú)立的，以它為鏡像運(yùn)行起來的EC2實例無法知道應(yīng)該去下載哪一個版本的平臺組件。幸運(yùn)的是AWS的EC2服務(wù)提供了“User Data”機(jī)制。簡單來說，就是在啟動EC2實例的時候可以傳入一段用戶自定義數(shù)據(jù)給AWS。當(dāng)這個實例運(yùn)行起來后，實例內(nèi)部程序可以通過調(diào)用AWS EC2的元數(shù)據(jù)服務(wù)取得先前傳入的用戶自定義數(shù)據(jù)。于是，我們可以把當(dāng)前需要運(yùn)行的平臺版本號以“User Data”的方式傳給EC2實例，然后讓啟動腳本讀取相應(yīng)版本號并下載相應(yīng)版本組件來部署。

同樣，基于“User Data”機(jī)制和平臺版本無關(guān)的AMI，我們非常容易得實現(xiàn)版本的回滾。只需要修改傳入給“User Data”中的版本號并保證要回滾到的平臺組件版本仍然存在于S3中即可。即使是從零開始回滾到以前版本也可以在幾分鐘內(nèi)完成（主要時間花費(fèi)在啟動EC2實例上）。在實際運(yùn)營中，因為已經(jīng)有了Prod/Staging的熱切換，我們一般會在切換上新的版本后保持原來的版本運(yùn)行一段時間（這段時間一般是問題的高發(fā)期）以便做到秒級的回滾。

2.6. 關(guān)于安全

如前面所說，我們需要格外關(guān)心在AWS上自動化部署的安全問題。在我們的實踐中，時刻會遵循最小授權(quán)原則并利用AWS中的IAM服務(wù)實施，具體體現(xiàn)在下面的兩個原則上：

1. 不要讓管理員之外的任何人直接使用AWS根賬戶（包括它的Access Key和Access Security）。取而代之的是創(chuàng)建專門的IAM User并給于其必須的權(quán)限

2. 不要在公司防火墻之外使用任何賬號的Access Key和Access Security。取而代之的是使用IAM Role來獲取EC2實例運(yùn)行時需要的資源訪問權(quán)限。

例如，我們的構(gòu)建系統(tǒng)需要訪問多項AWS服務(wù)資源（如S3、EC2、Cloud Formation等），而構(gòu)建系統(tǒng)又在防火墻內(nèi)部，所以我們創(chuàng)建專用的 IAM User來做自動化部署并給予構(gòu)建系統(tǒng)需要的資源訪問權(quán)限。另外，EC2實例需要訪問S3并下載部署組件，所以EC2應(yīng)該以專用的IAM Role來運(yùn)行并在IAM Role中給予相應(yīng)的S3桶只讀屬性。

2.7. 為什么不是AWS OpsWorks

熟悉AWS服務(wù)的人可能都知道Amazon已經(jīng)在2013年發(fā)布了它的DevOps服務(wù)： OpsWorks。我們的自動化部署系統(tǒng)為什么沒有選擇這個服務(wù)呢？最直接的原因就是我們開始構(gòu)建自動化部署系統(tǒng)時候，AWS還沒有發(fā)布OpsWorks。在AWS發(fā)布OpsWorks后，我們對此做了仔細(xì)調(diào)研，并決定繼續(xù)使用目前的系統(tǒng)。要了解其背后原因，就要完整理解AWS提供的一系列應(yīng)用程序管理服務(wù)（Application Management Services）之間的關(guān)系。這里，讓我們首先看看AWS文檔中這張示意圖：

圖5：AWS中的應(yīng)用程序管理服務(wù)

就如上圖所示，AWS為各種應(yīng)用場景提供了不同的解決方案。由于針對的應(yīng)用場景不同，這些服務(wù)的關(guān)注點(diǎn)也就不同。例如，AWS Elastic Beanstalk主要是為Web應(yīng)用程序提供快速部署服務(wù)（有點(diǎn)類似國內(nèi)SAE、BAE等服務(wù)），它幫助開發(fā)和運(yùn)維人員隱藏了大量的底層細(xì)節(jié)，非常方便上手部署應(yīng)用。但是，該服務(wù)在管理底層基礎(chǔ)設(shè)施架構(gòu)上就基本沒有多少靈活性，無法適應(yīng)項目的個性化需求。就我們的服務(wù)而言，它開始于最右邊的完全自己定制方案。在AWS推出Cloud Formation后，為了提高系統(tǒng)的效率和自動化程度，我們遷移到以Cloud Formation為基礎(chǔ)的新方案。但是我們沒有繼續(xù)向AWS OpsWorks遷移。究其緣由，讓我們先多方面比較一下AWS OpsWorks和AWS Cloud Formation：

表1：Cloud Formation與OpsWorks的比較

參考上面的比較和我們目前的自動化部署系統(tǒng)，OpsWorks對于我們?nèi)匀挥幸恍┫拗疲?/p>

1. 無法支持Windows操作系統(tǒng)。我們的很多服務(wù)仍然是運(yùn)行在Windows系統(tǒng)上。

2. 無法提供自定義的彈性策略。我們的系統(tǒng)實現(xiàn)了自己的調(diào)度算法，目前把該調(diào)度算法映射到現(xiàn)在OpsWorks中還比較困難。

隨著OpsWorks的發(fā)展，這些限制未來都可能會被解決。但是，作為一個已經(jīng)運(yùn)行的系統(tǒng)，我們?nèi)匀恍枰屑?xì)評估OpsWorks帶來的收益和成本以確定是否遷移。如果需要在AWS上面部署一個新的應(yīng)用，推薦的實踐就是如圖5從左向右依次選擇，并且在確認(rèn)左面的方案有明確限制的情況下再考慮下一個選擇。如果圖5中左邊服務(wù)已經(jīng)能夠解決問題，就不建議自己開發(fā)相應(yīng)的系統(tǒng)。畢竟整個部署系統(tǒng)的開發(fā)和維護(hù)還是需要一個不小的成本，而AWS提供的這些應(yīng)用程序管理服務(wù)都免費(fèi)的。另外，在絕大多數(shù)情況下，Cloud Formation已經(jīng)足夠靈活以滿足你在AWS上部署服務(wù)。但是，在某些情況下（例如，同時支持在多個云服務(wù)提供商上部署服務(wù)），你可能還得選擇完全自己開發(fā)或采用第三方供應(yīng)商的方案。

在過去的一年里，我們利用上面的自動化部署系統(tǒng)讓整個部署過程的耗時從最初的幾天快速下降到幾分鐘之內(nèi)，大大降低了的開發(fā)、運(yùn)維人員的負(fù)擔(dān)。如此同時，自動化部署還把部署出錯的可能性降到了一個極低的水平，提高了系統(tǒng)的整體可用性。

3. 總結(jié)

在上面的文章中，我仔細(xì)介紹了整個自動化部署系統(tǒng)，并討論了怎樣充分利用AWS服務(wù)的特點(diǎn)來提高自動化部署的效率。該系統(tǒng)運(yùn)行高效、穩(wěn)定，而且極大程度的降低了平臺自身和運(yùn)行于平臺上產(chǎn)品的運(yùn)維成本。接下來，我們?nèi)匀粫掷m(xù)改進(jìn)整個系統(tǒng)，其中關(guān)注的重點(diǎn)有：

1. 解決各個平臺組件之間的兼容問題。我們希望讓自動化部署系統(tǒng)能夠根據(jù)設(shè)置的規(guī)則自動檢測各個組件內(nèi)的兼容問題并選擇合適版本自動化部署，這樣，各個組件可以按照自動的節(jié)奏（和版本號）獨(dú)立發(fā)布（而不是像現(xiàn)在所有的組件必須以一個版本一塊部署）。

2. 開發(fā)整個自動化部署系統(tǒng)的控制臺界面（Dashboard）。該界面可以讓我們自己和產(chǎn)品部門看到系統(tǒng)的目前部署狀態(tài)及部署歷史，并且可以讓一鍵部署在該控制臺觸發(fā)，從而讓平臺內(nèi)部的構(gòu)建系統(tǒng)徹底隱藏在背后。

3. 嘗試和AWS OpsWorks的結(jié)合。OpsWorks的一個優(yōu)勢就是集成了大量DevOps實踐精髓并提供了豐富的內(nèi)建部署腳本，可以降低自動化部署系統(tǒng)自身的開發(fā)和維護(hù)成本。盡管如前所述，目前還沒有辦法向該系統(tǒng)遷移，但我們?nèi)匀粫芮嘘P(guān)注OpsWorks自身的發(fā)展，并會在平衡收益與成本的前提下積極嘗試和AWS OpsWorks的結(jié)合。

查看原文：基于AWS的自動化部署實踐