現代軟件開發對基礎設施的管理提出了更苛刻的要求：產品要適應瞬息萬變的市場，要求基礎設施有更快的響應速度。持續交付和DevOps的推行要求產品團隊對部署和運維要有更高的自主性。技術的快速進步和演化，也使得基礎設施的配置不得不頻繁變化。在這種快速變化的過程中，要求基礎設施既要靈活，也要安全、可靠。

而傳統的基礎設施運維管理具有以下幾個問題：

• 被動響應。產品團隊獲取服務器資源採用的是申請制，中間存在若干審批過程，以及需要等待運維團隊實施，響應不及時。

• 自動化缺乏串聯。雖然有一定的自動化，但不能做到無人值守，需要執行一些臨時命令介入。由於環境釋放和重建的成本高，因而傾向於不釋放，導致資源利用率低。

• 和產品團隊脫節。很難根據需求隨時動態增加環境。需要額外的文檔來描述環境，可能更新不及時。

產品團隊在實施持續交付的過程中，必須考慮將基礎設施的維護納入進來，作為支持產品運行的一部分。以下是產品團隊的持續交付流水線全景圖。

從上圖可以看出，產品團隊除了管理項目本身代碼外，還要管理環境定義腳本。環境定義腳本可以由基礎設施自動化工具執行，動態創建、銷燬和更新產品運行所需的環境（包括服務器、負載均衡器、防火牆配置、第三方依賴等）。

如果實現了這一點，就實現了基礎設施即代碼的雛形。Kief在《Infarftruce As Code》一書中對基礎設施即代碼定義如下：

“基礎設施即代碼是一種使用新的技術來構建和管理動態基礎設施的方式。它把基礎設施、工具和服務以及對基礎設施的管理本身作為一個軟件系統，採納軟件工程實踐以結構化的安全的方式來管理對系統的變更。”

基礎設施即代碼有四項關鍵原則:

• 再生性。環境中的任何元素可以輕鬆複製。

• 一致性。無論何時，創建的環境各個元素的配置是完全相同的。

• 快速反饋。能夠頻繁、容易地進行變更，並快速知道變更是否正確。

• 可見性。所有對環境的變更應該容易理解、可審計、受版本控制。

基礎設施即代碼的目標是：

標準化。 以代碼來定義環境，實現開發環境、測試環境、生產環境的標準化。

自動化。 以自動化工具來驅動代碼準備環境。包括創建環境、更新環境以及銷燬環境。

可視化。 以監控來可視化環境信息。環境當前狀態可視、環境變更歷史可視、可追溯。

基礎設施即代碼實踐會產生高成熟度的持續交付和DevOps。

在實施基礎設施即代碼時，要遵守以下實踐：

使用DSL描述環境

Ansible、Chef、SaltStack、Terraform等基礎設施自動化工具都有各自的描述性語言來實現對基礎設施的定義。使用DSL更容易通過描述性的語言定義基礎設施，也有助於代碼重用。團隊成員能建立起共同理解，從而維護腳本。

以下是Ansible的一個playbook示例。

自測試系統

在編寫環境代碼的配置時，也要編寫對環境的測試。確保所有服務器都進行了正確的配置，遵守了所有的安全規則，也對網絡連通性等進行了驗證。我們一般提倡將測試代碼和配置代碼放在一起維護。這樣配置代碼更新時，能保證測試代碼也被及時更新。

一些典型的基礎設施自動化測試工具有ServerSpec、Testinfra等。以下是一個ServerSpec的示例。

一切進行版本化

一旦採用了環境定義腳本實現對環境的控制後，需要將環境定義腳本納入到版本管理中。並且之後所有的環境變更都應該先修改環境定義腳本，由環境定義腳本觸發對環境的變更。登錄到服務器執行一些臨時性命令是被堅決禁止的。因為這極有可能會破壞環境的一致性。重建服務器時，也不能保證能應用所有需要的變更。

下圖是基礎設施即代碼的一個典型使用場景。

除此之外，如果想要在生產環境中創建可伸縮性的服務，也需要藉助“基礎設施即代碼”這一實踐。在高峰時期，系統可以根據定義的環境自動創建並加入新的節點來實現動態擴容，並在低峰時將其銷燬。當監控發現某節點失敗，系統可以根據定義的環境自動創建新的節點來替換失敗節點，實現自動災難恢復。

最後是我們在某團隊實施基礎設施即代碼的案例解析。這張圖是某團隊的基礎設施架構圖。

該團隊使用AWS作為基礎設施平臺。我們選用ansible作為基礎設施自動化工具，並結合AWS提供的cloudformation服務實現快速創建和銷燬資源。所有網元都有清晰的角色劃分，配套對應的配置腳本。從網絡配置到網元配置以及應用配置都實現了全自動化。所有的配置腳本都和源代碼一起託管在GitHub。團隊所有成員都可以查看並修改。

文／ThoughtWorks黃博文