硬件虛擬化技術的全面普及催生出云基礎設施托管這波全新機遇。云托管服務商開始直接為客戶提供對于動態基礎設施即服務(IaaS)平臺的訪問通道。隨著這類平臺的快速發展以及基礎設施資產復雜性的不斷提升，傳統系統管理角色的工作內容也變得愈加繁復。大規模云基礎設施的快速配置與統籌管理，開始成為困擾管理人員的新難題。

[[413041]]

持續集成/持續部署(CI/CD)的成功激發了基礎設施即代碼(IaC)，即使用代碼對基礎設施進行建模的新思路。DevOps則證明只要將代碼提交至Git repo，再通過功能分支及pull請求即可建立極為高效的工作流。借助這類已經在軟件開發自動化領域大放異彩的全新工作流，相信云系統的管理復雜度問題也將迎刃而解。

基礎設施即代碼是什么?

基礎設施即代碼是一套IT基礎設施管理流程，強調將DevOps軟件開發最佳實踐引入云基礎設施的資源管理當中，包括虛擬機、網絡、負載均衡器、數據庫及其他聯網應用程序在內的各類基礎設施資源均適用于這種新流程。

IaC代表著一種配置管理形式，可以將企業組織的基礎設施資源編碼為文本文件，再將這些基礎設施文件提交至Git等版本控制系統。版本控制repo支持功能分支及pull請求等工作流，而這些正是建立CI/CD體系的基本要素。

基礎設施即代碼的實現，離不開云基礎設施托管平臺，特別是IaaS平臺的興起。IaaS允許我們通過遠程API按需供應并申請云資源，這些API在本質上屬于提交至基礎設施的配置文件的屬性設置模板。Iac的自動化功能則可獲取這些配置文件，并針對遠程IaaS API加以運行。

在團隊將基礎設施配置提交至版本控制repo后，即可將CI/CD實踐應用吾基礎設施變更。基礎設施的更新同樣可以遵循DevOps工作流程。如果團隊成員編輯了其中某一配置文本文件，則可以使用pull請求及代碼審查工作流對編輯結果的正確性進行審核與驗證。

基礎設施即代碼有何重要意義?

IaC的持續演進，是為了幫助用戶解決“環境漂移”的問題。云應用程序在其發布生命周期的各個階段中往往有著相互獨立的部署環境，具體包括開發、登臺、生產等環境類型，而不同環境又對應不同的網絡資源，例如應用程序服務器、負載均衡器與數據庫等。當這些特殊環境之間的基礎設施未能同步時，即引發所謂環境漂移。

如果沒有IaC的支持，基礎設施管理將是一個混亂且脆弱的過程。系統管理員只能手動接入遠程云服務商，并使用API或Web儀表板對新硬件及資源加以配置。這種手動工作流缺乏對應用程序基礎設施的整體視圖，管理員很可能在更改了一套環境后，卻忘記了對另一環境做出相應變更。正是因為這樣，環境漂移才會頻頻發生。

環境漂移是一種昂貴的商業浪費，錯誤與故障的根源永遠是團隊在登臺或開發環境中的構建成果未能與最終部署時的生產環境相同步，迫使成員不得不耗費大量時間調查原因并補全缺失內容。

沒有IaC，基礎設施的手動管理在速度方面同樣令人抓狂。受到環境漂移、流量峰值或者其他特定問題的影響，如果我們明確需要對基礎設施做出某些變更，則系統管理員的響應與適配時長根本無法預測或控制。由此引發的服務中斷會打擊客戶信心。而在IaC的幫助下，基礎設施能夠自動適應配置變化，并通過自動擴展功能對流量峰值做出反應。

基礎設施即代碼還為手動系統管理提供更理想的監督能力與可見性。在將基礎設施配置文件提交至中央版本控制repo之后，所有團隊成員都能查看并編輯基礎設施數據，由此實現強大的審計能力。例如，如果團隊需要接受PCI合規性審計，則應當明確基礎設施中的特定部分是否使用SSL進行了加密。在IaC的支持下，可以快速查看SSL的配置方式并執行相關代碼，確保當前基礎設施與配置文件完全相符，即正確啟用SSL。版本控制提交歷史也可作為日志記錄使用，用于審查各項變更何時添加、何時被移除。

基礎設施即代碼如何起效?

要全面實現基礎設施即代碼，我們需要準備一系列依賴項。

首先，也是最重要的依賴項，就是遠程訪問托管。配置管理工具需要接入并修改該遠程主機。如果遠程基礎設施具備自我管理能力，我們就要確保團隊能夠隨時訪問其配置管理工具。而IaaS云托管平臺則提供API，允許用戶根據需要自動創建、刪除及修改基礎設施資源。配置管理工具同樣可以訪問這些API，借此將相關操作任務轉為自動化形式。目前流行的IaaS平臺包括Digital Ocean、Amazon AWS以及微軟Azure。

實現IaC的下一項要求，則是接入IaaS API并負責自動執行常規任務的工具套件。團隊當然可以自主創建一組腳本及工具，但這會帶來大量的開發負擔與后續維護成本，投資回報也往往不高。目前市面上已經有多種開源配置管理平臺用于解決這類需求，包括Terraform、Ansible、Salt Stack以及Chef等。

最后是版本控制系統。配置管理平臺使用以YAMl等標記語言編寫的、人類及機器皆可讀取的文本文件對平臺將要執行的任務及序列做出聲明。這類文本文件作為應用代碼文件存在，并被存儲在版本控制系統repo當中。這套repo相當于集中指定來源，同時支持pull請求及代碼審查。目前最流行的版本控制系統當數Git。

有了以上依賴項，我們設想以下示例場景，其中開發人員希望向系統當中添加新的應用程序服務。下面來看IaC工作流演示：

(1) 開發人員在選定的配置管理平臺Terraform中編輯YAML配置文本文件，由此指定所需的新托管服務器。

(2) 開發人員將編輯結果提交至Git repo中的功能分支。由于項目的Git repo托管在Bitbucket上，因此開發者會開啟一項pull請求。其他團隊成員負責審查這項pull請求，并發現其中包含基礎設施變更。后者批準此項pull請求，而后由之前的開發人員將提交結合提交并合并至repo的主分支當中。

(3) 到這里，我們需要使用配置平臺以執行更新。這項更新可以由開發人員手動觸發。本場景中的團隊使用的是Bitbucket，因此可以訪問Bitbucket Pipelines以使用管道自動執行此步驟。

(4) 執行完成后，Terraform將與團隊的IaaS進行交互。Terraform將針對IaaS API執行一系列命令，確保IaaS與預期的基礎設施配置保持同步。

小結

IaC是一種高效的配置管理形式，專注于實現云IT基礎設施的自動化管理。在IaC部署到位之后，即可用于實現CI/CD層級的自動化功能，高效調整項目的基礎設施。IaC還針對基礎設施變更當中的溝通及透明度因素提供多種有益見解。至于IaC在實現當中所需要的托管平臺及自動化工具等依賴項，目前市面上已經有眾多托管廠商提供廣泛的解決方案以供選擇。