基於雲的基礎設施代碼化最佳實踐

什麼是基礎設施？

我們在這個話題中討論的基礎設施主要有三類：

雲服務器：雲存儲、DNS、CDN等都是基礎設施。應用程序具備真正的業務價值，但應用程序跑的基礎平臺都是基礎設施。雲服務器包括應用程序服務器、數據庫服務器和緩衝服務器，我們可以通過代碼化把這個配置出來。

這種傳統的基礎設施管理具體存在着哪些問題？

第一，諮詢審批流程長，響應不及時。 這個基礎設施從一個開發開始申請，逐級批准，然後運維總監批准，最後走採購的流程，這種審批流程不但項目組等待非常耗時，而且等待的信息反饋適應不了大家的需求。

第二，手工進行服務器的安裝和配置，可能速度比較慢，難於版本化。發佈前大家都要加班，並且在服務器上裝東西，登錄服務器去手工的部署，出問題很難追溯。

第三，易出錯，遺漏配項。忘了一步很可能服務器跑不起來，要加班處理。

基礎設施會遇到一些問題

一是無法根據業務需求，隨時動態增加環境；

二是雲資源利用率低；這種靜態的，手工的配置方式帶來的後果是項目組一開始在立項的時候把基礎設施申請好，而並不釋放資源，比如說現在有四臺服務器，不用也不會還給公司，爲什麼？之後要用再申請是非常麻煩的。現在雲服務器並沒有給我們帶來資源動態的好處，導致資源利用率低，成本增加；

三是手工部署的步驟有文檔，但是文檔維護起來很繁瑣，而且常常更新不及時。

所以靜態的基礎設施導致沒辦法用雲時代新的思維來解決問題，我們還是停留在舊的申請虛擬機的方式。

爲什麼傳統基礎設施管理會遇到問題？

一，在倡導敏捷開發的時代，我們的產品要適應瞬息萬變的市場，要求基礎設施有更快的響應速度；

二，我們可以用這種敏捷的基礎設施支撐持續的創新和實驗。有的時候產品經理有一個想法，沒有人知道推向市場會怎麼樣，因爲開發、運維，公司裏面的人員可能並不是這個產品的真正用戶。要快速的推向市場，快速的試錯，需要基礎設施跟得上步伐；

三，對持續交付、DevOps要求團隊對部署和運維有更高的自主性，構建一個APP，就負責運維這個APP；

四，技術的快速進步，使基礎設施的配置不得不頻繁變化，現在我們有更多的選擇了。在快速變化過程中，要求基礎設施既要靈活、也要安全，可靠。我們開發人員，一線的產品肯定是希望基礎設施越來越好，但是企業，尤其是大型的組織，他們對安全、可靠、可審計和合規性的要求也是非常強的。

如何解決這些問題？基礎設施即代碼，我們是怎麼應用的，有兩個原則：

一、代碼化基礎設施。用代碼的方式管理我們的基礎設施，並且維護管理它的全生命週期，包括審計的要求。代碼更自然的成了審計上面一個非常好的記錄，我認爲代碼的變更可以追溯到人，追溯到項目組。代碼化也解決了變本、追溯和變更歷史的問題；

二、動態基礎設施。動態的需求如果在快速變化，我們可以用動態的方式去快速的創建它。

剛剛引入自動化的時候，我們用的是Amazon，之前用這些東西做應用程序的發佈，我們在想基礎設施的管理是不是也可以用它來做？（更多相關信息）

首先定義軟件包，然後配置服務器，把配置文件和安全設置應用到服務器上面去，最後把應用程序的外包發佈到服務器上，我們用代碼的方式進行自動化實現。

我們在基礎設施創建的時候，可以寫一些簡單的代碼，比如說創建一臺虛擬的服務器，創建一個自帶的EC2，給它指定一些參數，操作系統的鏡像是什麼樣的等等，之後加在主機的集合裏面，等配置之後可以持續往下面的腳本去部署，現在看一下腳本是怎麼樣運行的。

此時在雲上創建一個雲服務器，整個過程都是一個自動化的過程。當時我們在客戶的組織內部做了一個培訓，我寫了一個完善的文檔教大家怎麼用這個程序，大家可以去看。

如何解決基礎設施代碼化的問題？

基礎設施的生命週期管理分兩個部分的，一個是構建，一個是配置。構建就是創建資源，但不配置。裝程序，導入用戶初始數據，我們認爲是配置。在基礎設施構建這一塊，可能就會用到formation。

怎麼樣用現代的基礎設施來構建現在的基礎架構？這個是非常簡單的演示，一個最簡單的功能，這裏面一個是創建，一個是更新基礎設施，然後如何銷燬基礎設施；我們把基礎設施分解成一個一個技術站，每一個項目組可能有一個或者更多的，一套基礎設施分組，一個組就是一個function。

我找到的是一個官方的例子，一個經典的技術站。爲了保證它的可用性，我們做了一個分區域的高可用部署，可以看到它現在調用API去實現，我相信所有的公有云都有這個API的接口，企業的私有云也有這樣的API接口。這裏面可以看到已經創建了一些安全組，然後逐漸創建我指定的所有的資源，創建之後會導入一些初始的數據，而且都是全部自動化的。

怎麼樣自動化？實際上代碼也非常簡單，首先定一些參數，比如數據庫的名字，數據庫裏面的用戶名，密碼，還有一些服務器的大小，可以設置默認程序機構有幾臺服務器，可以動態擴容，但需要一個初始的值，後面是一些固定的企業碼。

這裏有一個Resources，之後會配置它的的特性，比如接在80端口上，有什麼樣的協議，我們定義了一組服務器，用自動擴容架構去創建了一個服務器，然後設置了一些updatepolicy的滾動發佈的策略，還有一些具體服務器的配置。我們把代碼寫死在服務器裏面，但實際上可以不用寫死，可以指定在外部的文件裏面。

最後給應用者一個新創建文件的訪問地址，這樣創建完之後就可以直接用了，相當於一鍵把整個應用程序的架構創建好了，而且是高擴展的。

Terrafom這個公司的服務發現，本地虛擬機的啓動比較有意思。又拍雲有一個雲存儲的服務，我在API上寫一個拓展插件，非常容易，這樣我可以把所有基礎設施代碼通過又拍雲來創建。

爲了適應新時代下快速的基礎設施變更需求，基礎設施即代碼實踐 應運而生，如果大家有興趣的話，可以嘗試閱讀這本書（Infrastructure as Code）。

聲明：本文來自「又拍雲主辦的Open Talk——DevOps與持續交付實踐」的演講內容整理。PPT、速記和現場演講視頻等參見「UPYUN Open Talk」官網。
嘉賓：劉梓懿，ThoughtWorks諮詢師，專注於雲計算和ThoughtWorks。
責編：錢曙光，關注架構和算法領域，尋求報道或者投稿請發郵件[email protected]，另有「CSDN 高級架構師羣」，內有諸多知名互聯網公司的大牛架構師，歡迎架構師加微信qianshuguangarch申請入羣，備註姓名+公司+職位。