基于AWS的自動(dòng)化部署實(shí)踐

作者 徐桂林

1. 背景

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

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

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

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

1.2. 云計(jì)算帶來(lái)的新可能

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

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

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

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

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

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

2. 自動(dòng)化部署

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

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

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

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

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

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

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

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

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

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

4. 隨時(shí)可回滾：必須可以很容易的回滾到前面的版本以處理意外問(wèn)題。

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

2.2. 整體架構(gòu)

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

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

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

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

2.3. 一鍵部署流程

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

圖2：一鍵式部署流程

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

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

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

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

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

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

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

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

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

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

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

圖4：自動(dòng)化部署中的AMIs

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

正是因?yàn)椴扇×松厦娴腁MI生成、管理策略，我們的產(chǎn)品部門(mén)基本上不用太頻繁的更新它們產(chǎn)品的AMIs（除非產(chǎn)品自身有更新），真正做到平臺(tái)版本和產(chǎn)品版本的去耦合，極大的降低了運(yùn)維成本。

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

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

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

2.6. 關(guān)于安全

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

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

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

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

2.7. 為什么不是AWS OpsWorks

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

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

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

表1：Cloud Formation與OpsWorks的比較

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

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

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

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

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

3. 總結(jié)

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

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

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

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

查看原文：基于AWS的自動(dòng)化部署實(shí)踐