一、作者介紹

　　徐桂林：阿里云日志服務技術專家，碩士畢業，曾任職AutoDesk等公司，擅長云計算，DevOps等。

[[145962]]

　　二、引言

　　我在自動化部署，特別是公有云的自動化部署上工作多年，因此本文主要就這方面進行展開。

　　注意：這里提到的云主要指基礎設施服務層，即IaaS，且泛指包括公有云、私有云或者混合云在內的所有IaaS層形態。

　　三、基本背景

　　由于工作關系，我在上一家公司(Autodesk)時從2008年底開始使用某國外公有云。當時參與項目中很重要的一部分工作就是幫助用戶在我們的平臺上(注：我們的平臺運行在該云上)完成自動化部署。

　　由于整個部署非常重，涉及到平臺自身部署、基礎軟件部署和用戶傳統軟件部署。每次部署需要數個小時的時間，非常影響整個團隊的工作效率。所以，我們花費了比較多的時間在構建自己的云自動化部署系統?！　?/p>

　　進入現在公司后，個人也推進了所在項目的部分自動化部署流程。盡管這個項目并不直接運行在云上，但在原來項目中總結出的辦法還是有一定通用性。其中的部分經驗也得以落實，最終效果也不錯(整個系統的部署時間有了數量級的縮短)。

　　經歷上面兩個完全不同的項目，個人意識到，系統自身的可部署性，是能否落實自動化部署的關鍵所在(當然，這個結論的前提是團隊已經認同自動化部署是團隊效率和質量的基礎性制度保證)。

　　而系統的可部署性是從架構設計到最終運維整個流程都需要考慮的因素。所以需要整個工程團隊(開發、測試和運維)在系統可部署性上要達成一致，制定相關準則，整個自動化部署才能順利推進。

　　所以，這里我從系統的“可部署實踐準則”角度來分析如何保證自動化部署的成功實施：

　　盡管這里提到的很多準則不僅僅是針對云上系統，但是由于個人經驗主要在云上系統的部署，同時個人相信未來絕大部分IT系統也都會運行在云上，所以會以云上系統的自動化部署為主來分享我的具體做法。

#p#

　　四、持續交付

　　在討論自動化部署時，一定會涉及到持續交付。從邏輯的角度上看，自動化部署是持續交付的一個階段。但是，自動化部署流程和系統仍然是可以獨立于整個持續交付流程而獨立運行。下圖描述常見的持續交付流程以及自動化部署在其中的位置。　

　　如上圖所示，整個自動化部署流程會涉及到IT系統生命周期中的所有環境(開發、測試，預發和生產)。在這其中，由于生產系統的敏感性以及發布流程上的一些要求(如發布窗口期)，需要人工審批并觸發部署流程。其他環境更推薦持續部署來加快迭代周期，盡早發現問題。

　　五、可部署實踐準則

　　系統的可部署性一定是一個產品技術團隊共同的職責：

• 　　云上IT系統應該遵循的準則有部分是流程上的，可能需要運維人員做標準化；
• 　　有些部分則是系統開發設計時的，需要開發人員考慮；
• 　　當然，測試工作也要考慮可部署性。

　　Rule 0、用版本管理系統(VCS)管理要發布的所有東西

　　這條規則比較容易理解，絕大部分團隊也應該都在實際項目中很好得落實了這點。

　　需要注意的是，VCS系統不僅僅是用來管理你的代碼，所有要發布的東西(包括代碼、文檔、視頻等等)都可以(也應該)由統一的VCS來管理。至于VCS系統的選擇，主流的軟件(SVN、Git或者Perforce等)都能夠很好支持整個持續交付和自動化部署流程。

　　Rule 1、統一管理構建出來的Artifacts

　　這條規則是很多團隊容易忽視，但對自動化部署落實又非常重要的基礎性準則。

　　什么是Artifacts?

　　Artifacts是指構建系統產生的任何需要部署的輸出，如代碼包、文檔、靜態資源等。

　　參考上面的持續集成流程圖，可以看出Artifacts是所有自動部署流程的輸入，它的管理質量直接會影響到部署流程的順利程度和效率。關于Artifacts管理，現實工程中經常出現的幾種情況如下：

• 　　團隊完全無Artifacts管理。需要部署時直接從構建系統拷貝出來，通過郵件或者其他文件分享工具在團隊內部傳輸。這種情況會導致整個部署流程完全失控，并且無法跟蹤部署記錄。
• 　　團隊僅關注生產環境下的Artifacts管理。對于開發、測試或者預發環境的Artifacts管理沒有任何規劃和標準。這種情況會無法保證整個生命周期的部署一致性，極大影響團隊的迭代效率。
• 　　對于Artifacts的管理完全等同于對于文件的管理，沒有對Artifacts的metadata信息進行任何有效管理。由于缺乏Artifacts的metadata信息，導致部署流程和系統不容易獲取當前Artifacts的元數據并以此采取相關操作。會讓部署流程實現困難，部署質量無法保證。

　　在實際工程中，團隊越早在Artifacts管理上達成統一標準，團隊在推進自動化部署落地的難度就越小。個人認為，一個好的Artifacts管理方式需要有下面幾個原則：

• 　　統一管理所有需要部署的Artifacts，包括開發、測試、預發和生產環境。只有這樣，才能夠為未來自動化部署流程和系統提供統一的輸入。
• 　　統一的Artifacts元數據格式，包括當前Artifacts的構建信息、版本信息、可部署的環境等。
• 　　提供對接構建系統和部署系統的API接口。只有API接口才能夠保證未來自動化的落地。

　　目前，市面上已經有很多Artifacts管理工具(如開源的Nexus)，可以幫助大家快速搭建整個Artifacts管理系統。如果你的系統是在云上部署，云供應商提供的對象存儲服務也是不錯的選擇。

　　Rule 2、讓部署系統管理你的云上基礎設施

　　之所以把這一點放在前面，是因為它太重要了，而且也是和傳統IT環境下自動化部署流程非常不同的地方。

　　在云上，一個非常重要的變化就是：所有的基礎設施都可編程。

　　今天，所有的云供應商都必須提供基礎設施的編程接口(如虛機啟停API，存儲接口，網絡配置接口)。而有些更成熟的云供應商已經提供如CloudFormation服務，讓你的IT系統基礎設施能夠完全可精確描述。

　　正因為如此，云上自動化部署系統可以完全管理起來自己的基礎設施，并且通過API或者如CloudFormation服務快速、精確構建一致的IT運行基礎設施。

　　當系統的自動化部署流程完全包括基礎設施管理后，有如下幾個明顯好處：

• 　　任何時刻都可以獲取環境完全一致的IT基礎設施來運行系統(包括資源申請，環境搭建和軟件部署)。這樣，可以做到真正從零開始快速部署系統，而無需依賴任何其他部門(如IT部門)。
• 　　IT基礎設施的任何變化都能夠被部署系統自動感知并采取相應的行動，保證IT系統的穩定性。
• 　　IT系統可以根據系統當前情況隨時向部署系統要求調整IT基礎設施(如彈性伸縮)。

　　這里需要提到的一點就是，以Docker為代表的容器技術讓運行時標準化和可編程化變得極其容易和輕量級。

　　但是，整個IT系統基礎設施不僅僅包括系統的運行時環境，還包括網絡規劃、存儲管理、計算資源管理等等。

　　而這些基礎設施的程序化目前還只能通過云上IaaS層API或者類似CloudFormation來完成。所以，從這個角度看，Docker和IaaS并不是相互沖突，而是非常好的搭檔，一同把整個IT系統的運維、管理成本大幅降低。

　　Rule 3、使用相同的部署流程管理你的開發、測試、預發和生產環境

　　這是一條在傳統IT和云上都應該遵循的原則。在現實中，很多團隊都喜歡把部署系統這個事情拖到上線前的***一刻才開始。而且，即使有自動化部署流程，也是和生產環境硬耦合，只能用于生產系統的部署。

　　1.這種做法雖然短時間來得快，但是在長期IT系統部署管理中會帶來不少麻煩，個人覺得至少會包括如下兩點：

　　2.這種部署方式導致不同環境的不一致性成為一個必然發生的事情，而這個問題最終會給你的生產環境帶來致命故障。

　　這種部署方式導致開發、測試和上線過程極為低效。其實，在不同環境中，生產環境的部署頻率是***的，而開發、測試部署幾乎是工程團隊每天都要做的事情。通過完全自動化的部署流程來管理所有環境將極大提高日常開發、測試效率。

　　所以，對于一個新項目，***在項目啟動之初就能夠把整個IT系統的自動化部署流程搭建成功，而且包括所有的環境。

　　而對于已經運行的項目，也要積極推動部署流程和部署環境的解耦。具體來說，常見的解決思路包括下面幾個點：

• 　　使用不同的代碼分支對應不同的環境，方便進行代碼管理;
• 　　抽象、提出所有和環境相關的配置，并以配置服務的方式提供訪問;
• 　　所有部署階段都需要接受環境參數輸入(可以是環境變量，也可以是參數)，并按照不同環境做相應部署操作;
• 　　給不同環境設置不同的部署頻率和時間窗口;
• 　　給不同環境設置不同的部署操作和訪問權限，以控制部署風險。

　　***，可能很多團隊根本不可能有完整開發、測試和生產環境(或者這幾個環境的差異性太大)，讓同一套部署流程很難適配不同的環境。但是，因為云的出現，讓我們獲取不同環境的IT基礎設施變得容易很多。

　　正因為如此，落實這條準則的難度在大幅下降(其實，開發測試已經成為很多企業用戶開始嘗試云的***站)，而這條規則帶來的開發效率提升會讓團隊收益匪淺。

#p#

　　Rule 4、使用相同的部署流程管理全球各地的同一個IT系統

　　這是一條看起來對很多團隊沒什么用的準則。但是，云的出現讓全球化部署變得非常容易，很多非常小的團隊都可以做全球部署和運營。在云上，全球部署就是在云服務供應商的全球不同Region部署你的IT系統。

　　當然，即使在國內，為提供更好的系統訪問速度，云供應商也會提供多個Region。由于云供應商不同的Region提供的服務都已經標準化，訪問接口也都統一，這讓使用相同部署流程管理全國(乃至全球)各地服務容易很多。為此，你的部署系統需要注意幾點：

• 　　抽象、提出任何和部署Region相關的配置，并以配置服務的方式提供訪問(配置服務有可能是集中化服務)；
• 　　所有部署階段都需要接受Region相關信息輸入(可以是環境變量，也可以是參數)；
• 　　需要提供不同Region的部署協調機制(例如，不同Region可能會在不同時區，這是處理和時間相關的部署任務需要特別小心的地方)。

　　一旦能夠統一不同Region的部署流程，將會使得業務擴展時的IT部署變得容易很多，這也是整個系統可擴展性的重要體現。

　　現在，IT系統擴展性很多時候被局限在同一套系統在同一個地方能否快速伸縮，而忽略了IT系統在不同地點的快速復制能力。而這種快速復制能力不僅僅是業務全球化的需求，有時候也是解決系統自身容量擴展性的重要途徑。

　　Rule 5、部署流程要優先滿足熱升級、熱切換需求

　　在傳統IT工程中，由于熱升級和熱切換實現起來可能比較困難，而系統升級、切換的頻率也不一定高，很多時候這種功能性需求就會被當成“二等公民”看待。但這條準則恰恰相反，著重在強調“優先滿足”。究其原因，個人認為有如下幾點：

　　1.“一直在線”已經成為新的剛需。

　　隨著IT系統從后臺支撐逐步轉向前臺直接服務客戶。那種定期停機升級系統的方式已經不再可以接受。

　　尤其是互聯網和移動互聯網的普及，用戶對于在線服務的默認期待已經是“任何時候，任何地點都可以訪問”。在這種情況下，無論是架構設計還是部署流程都需要考慮“一直在線”這個目標。

　　2.熱升級、熱切換是持續交付的基礎，是最終支撐業務快速發展的關鍵所在。實際工程中，產品團隊的所有工作最終都得到生產環境接受檢驗。

　　只有整個部署流程完全支持熱升級、熱切換，產品的任何改進或需求確認才能夠快速推到生產環境進行驗證。如果部署流程無法支持熱升級、熱切換，那持續部署就必然造成頻繁中斷服務，進而影響業務。

　　正因為上面的原因，在整個架構和部署流程的設計過程中就需要優先考慮熱升級、熱切換，并堅持走下去。否則搭建的整個持續交付或者自動化部署流程都會事倍功半，最終走向失敗。

　　在云上，由于基礎設施資源的獲取非常容易，在升級過程中讓不同版本完全獨立運行并逐步切換流量已經是一個成本不高的實踐方式。所以，云上系統的熱升級及熱切換實現難度也有一定程度上的降低。

　　Rule 6、自動化、自動化還是自動化

　　就如“自動化部署”的名字所表述，自動化是其核心訴求，也是能夠最終成功實踐的技術保障。關于自動化的好處，相信不用展開說大家也都明白。但在現實過程中，大家面臨的問題常常是如何實現平滑的實現自動化。個人推薦下面幾個實踐經驗：

　　1.不要在自動化技術和工具上猶豫太久。

　　選擇什么樣的自動化部署工具對于還沒有自動化流程的團隊來說不是***要務。重要的是團隊有決心、花時間去開始行動。

　　如果在選擇技術和工具上真有什么建議的話，那就選團隊最熟悉的技術和工具，這樣對于快速出結果最為有利。而讓團隊盡快看到自動化部署的優勢，從而堅定在這條路上走下去比選擇什么樣的工具要重要得多。

　　2.盡早建立“one-click”部署流程。這樣可以讓團隊在“one-click”上有更早的約束，而不是在推進過程中不斷妥協，***完全無法自動化。

　　3.在有“one-click”部署流程的前提下分步推進各個組件達到自動化部署的要求。

　　在分步驟推進過程中，一個好的策略是區分模塊中的“常量”和“變量”。

　　這里的“常量”指系統部署中不經常變化的部分(如基礎操作系統，基礎軟件等等)。對于這些部分，開始可以使用“預制模式”(如系統鏡像)加入部署系統。而部署過程中經常變的“變量”部分，則需要在部署系統中重點考慮。當然，“常量”和“變量”的劃分也不是絕對的。一般來說，部署系統都是從自動化最頻繁變化的“變量”部分開始，逐步覆蓋較少變化的“常量”部分。因為這樣可以盡早***化自動化流程帶來的價值。

　　Rule 7、讓模塊有自啟動、自發現和自部署能力

　　在實施自動化部署的過程中，估計最容易讓團隊沮喪的就是不同模塊之間的部署依賴關系。很多傳統部署軟件也試圖通過各種方式(如可視化依賴關系)來降低維護部署依賴的難度，但很多時候最終效果并不好。

　　究其原因，個人覺得在業務場景的頻繁變化中，讓模塊之間的緊耦合依賴關系很難長期保持穩定，部署系統也就很難高效維護這種多變的部署依賴關系。隨著微服務概念的流行，更多人開始相信每個微服務模塊都應該是獨立部署、運維并提供服務。

　　這點體現在部署上，就是讓每個模塊有自啟動、自發現和自部署的能力。具體來說，其包括下面幾個方面：

• 　　每個模塊在部署到系統中，都能夠在無外接主動觸發的前提下自我啟動；
• 　　每個模塊在啟動后，都能夠在無需外接主動告知的前提下發現自己承擔的角色是什么；
• 　　每個模塊在發現自我角色后，都能夠在無需外接主動推送的前提下完成對自我角色的部署、配置、依賴檢查并啟動對外服務。

　　基于上面幾點要求，個人在實踐過程中采取的常見方法包括：

• 　　優先選擇“運行時部署”，而不是“預定義模式”(最常見的預定義模式就是鏡像交付);
• 　　每個模塊需要自我描述如何完成自己的部署流程(如某大云的CodeDeploy服務，其中的appspec.yaml文件其實就是其對應模塊自我部署的描述文件);
• 　　讓每個模塊獨立進行部署，不要求必須有前置或者后置的模塊部署。而模塊之間的依賴則優先使用動態發現的模式進行。

　　#p#

Rule 8、讓部署變成服務

　　當團隊完成了整個自動化部署流程，記得在往前一步，把你的部署工具變成一個對內的部署服務，讓團隊每個人(包括非技術人員或者新來的同事)也能夠快速完成部署。

　　為讓部署成為服務，你可能需要實現一個Portal，或者再添加一個郵件通知服務。當然，你也可以把整個部署服務做得更好，甚至服務于其他團隊。無論如何，這都會給團隊帶來很大的好處，因為它降低了整個系統的使用門檻，讓更多的人從中獲益。

　　Rule 9、用戶全面監控保障自動化部署

　　這是***一條準則，但是可能也是很多開始嘗試自動化部署的團隊最擔心的問題：如果自動化部署出問題了咋辦?

　　人工部署時候還可以一步步觀察結果，由人來把關部署流程，避免不良后果快速擴大。其實，在回答這個問題之前，如果大家仔細回顧人肉部署帶來的各種故障，一定會發現人為失誤引起的故障比例會大得驚人。

　　而自動化部署的一個目標恰恰就是為了減少人為失誤導致的故障。當然，為了避免自動化部署的負面影響，你需要注意下面幾個方面：

• 　　請為你的服務提供全面的監控。這不僅僅是日常運維的需要，也是自動化部署的需要。而且，這里的監控需要包括很多應用級別的監控，而不僅僅是類似CPU、Memory這些基礎性監控。這樣，可以方便團隊及時發現自動部署引起的系統服務問題。
• 　　在部署流程中提供快速回滾(Rollback)方案。可靠的回滾方案會讓你推進自動化部署的時候有更多的信心。
• 　　對每個模塊每個部署階段做更多的pre-check和post-check。想想如果你人肉做部署的時候是怎樣check每一個部署階段是否成功，如何判斷是否問題，然后盡量把這些判斷邏輯都自動化起來。

　　***，如果你是團隊內希望推動自動化部署的同學，下面兩點經驗或許在你推進過程中能幫助到你：

• 　　痛點原則。在推進自動化部署過程中，一個常見的問題就是時間問題。團隊總是會被不同的業務需求推著往前走，而自動化部署這種非功能性需求經常無法得到資源保障。這時候，你需要不斷問自己的一個問題是“如果我現在只能在自動化部署方面做一見事情，那我需要做什么”。記得找到痛點***的唯一一件事情作為突破口，盡快讓團隊感受到自動化部署帶來的優勢，才能夠得到團隊更多的支持。
• 　　不回頭原則。在推進自動化部署過程中，團結經常會因為自動化部署帶來的問題或者自動化部署流程不完善而放棄嘗試。這時候，作為主動推進的人，一定要及時跟進發現系統問題，而不是讓團隊輕易走回頭路。

　　當然，你肯定會說搞定老板才是最核心的保障。如果你能夠有一個完全支持你的老板，那你是幸運的。

　　更多時候，老板會是一種半信半疑的態度對待自動化部署。這時候，找到突破點，快速見效并能堅持下去可能就是你能說服老板的***策略。

　　http://blog.xuguilin.me/2014/01/22/autodeploy-on-aws.html

　　如何一起愉快地發展

　　“高效運維”公眾號(如下二維碼)值得您的關注，作為高效運維系列微信群的唯一官方公眾號，每周發表多篇干貨滿滿的原創好文：來自于系列群的討論精華、運維講壇線上精彩分享及群友原創。“高效運維”也是互聯網專欄《高效運維***實踐》及運維2.0官方公眾號。

　　提示：目前高效運維兩個微信主群僅有少量珍貴席位，如您愿意，可添加蕭田國個人微信號 xiaotianguo 為好友，進行申請;或申請加入我們技術交流群(技術討論為主，沒有主群那么多規矩，更熱鬧)。

　　重要提示：除非事先獲得授權，請在本公眾號發布2天后，才能轉載本文。尊重知識，請必須全文轉載，并包括本行及如下二維碼。