作者 徐桂林

1. 背景

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

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

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

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

1.2. 云計算帶來的新可能

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

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

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

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

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

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

2. 自動化部署

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

2.1. 設定目標

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

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

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

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

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

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

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

3. 無服務中斷：必須能夠無縫的進行服務升級、切換。

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

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

2.2. 整體架構(gòu)

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

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

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

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

2.3. 一鍵部署流程

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

圖2：一鍵式部署流程

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

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

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

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

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

圖3：運行時部署

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

2.4. 為什么選擇運行時部署

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

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

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

圖4：自動化部署中的AMIs

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

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

2.5. 運行時版本選擇與回滾

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

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

2.6. 關于安全

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

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

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

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

2.7. 為什么不是AWS OpsWorks

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

圖5：AWS中的應用程序管理服務

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

表1：Cloud Formation與OpsWorks的比較

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

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

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

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

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

3. 總結(jié)

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

1. 解決各個平臺組件之間的兼容問題。我們希望讓自動化部署系統(tǒng)能夠根據(jù)設置的規(guī)則自動檢測各個組件內(nèi)的兼容問題并選擇合適版本自動化部署，這樣，各個組件可以按照自動的節(jié)奏（和版本號）獨立發(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ā)和維護成本。盡管如前所述，目前還沒有辦法向該系統(tǒng)遷移，但我們?nèi)匀粫芮嘘P注OpsWorks自身的發(fā)展，并會在平衡收益與成本的前提下積極嘗試和AWS OpsWorks的結(jié)合。

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