隨著運維流程變得越來越靈活，IT團隊面臨著越來越大的復雜度。當應用動態改變時，可以使用敏捷或者持續應用開發。但是當IT資源本身動態變化的時候怎么辦呢?

　　多云和混合云是這一新的、動態的IT大格局的一部分——并且帶來了新的風險。要解決這里的問題，一些企業使用了基礎架構即代碼方案。

[[170724]]

　　配置管理(CM)在大規模IT基礎架構里一直是必需配置。有一些CM工具，來自于云供應商，比如Amazon Web Services或者Microsoft Azure，或者來自于虛擬化或私有云軟件供應商，比如OpenStack或者VMware。

　　基礎架構即代碼通過為應用程序創建虛擬托管模型來擴展了CM。這樣虛擬的托管模型散布在多個云環境和數據中心平臺里。

　　雖然基礎架構即代碼是CM的一種擴展，它其實是作為DevOps的擴展才開始流行起來。用戶無法在還沒有搭建好的服務器或者云服務上部署應用程序。因此，DevOps工具和腳本必須包含這些配置任務。這使得DevOps腳本和工具是和配置綁定的;如果從一個云平臺改變到另一個平臺，用戶就必須更改腳本。基礎架構即服務提供了一種方式，將應用程序的虛擬世界和底層資源，包括云，隔離開。有更多的托管方案存在，基礎架構即代碼就會更加有價值。

　　基礎架構即代碼模型為部署描述創建了中間層;用戶將應用程序部署到基礎架構即代碼所創建的抽象的托管模型里，基礎架構即代碼隨后將其適配到當前使用的任意云，多云或者混合配置環境里。基礎架構的變動在應用程序和運維層是不可見的，并且添加新的云供應商僅需要在基礎架構即代碼里完成其定義即可。

　　但是，基礎架構即代碼的用戶需要注意如下三大重要步驟：

　　1.將基礎架構即代碼從DevOps中隔離

　　IT團隊能夠將基礎架構即代碼部署到定義了配置腳本的任何環境里，并且使得應用程序能夠適配幾乎所有公有云服務或者數據中心平臺。

　　IT團隊需要基于哪種基礎架構即代碼將部署配置，來定義IT資源的抽象模型。基礎架構即代碼工具和實踐變化很大。一些用戶為每個應用程序都構建了基礎架構即代碼，而另外的用戶為每種類型的云托管環境，比如基礎架構即服務，平臺即服務或者Docker，構建通用的模型。

　　總的來說，***減少創建出的抽象托管模型的數量，因為當添加新的托管選擇時，你必須調試每個模型。工具允許的情況下，考慮層級構建模型，這樣部署應用組件——或者某個應用的一部分——的基礎架構即代碼模型，可以在部署整個應用程序的模型里直接引用。

　　2.為使用的所有云或者數據中心環境保護對基礎架構即代碼的支持

　　一旦你理解了所需模型，要確保它們能夠支持計劃使用的特定的云供應商和數據中心的配置。幾乎所有基礎架構即代碼工具，比如Chef和Puppet，都讓用戶為任何環境定義自己的配置規則，但是流行的公有云，私有云和平臺方案——比如hypervisor，容器系統和服務器操作系統——都作為基礎架構即代碼工具集的一部分提供。還可能有社區的支持，其他用戶將他們的配置規則貢獻出來。從已經能夠工作的配置上開始開發，比從頭開始構建自己的要更加容易。

　　3.將事件流從基礎架構推廣到部署工具

　　完成基礎架構即代碼方案中最微妙，困難和重要的事情是，處理基礎架構即代碼和其他工具集成的事件流;大多數情況下，這意味著使用DevOps工具。應用程序生命周期運營管理需要根據情況選擇合適的軟件——這些條件就是基礎架構即代碼里的事件。這些事件，通過托管資源生成，充當干什么事情的信號。他們通常激活一個自動化流程，比如通過在別的地方托管來替換發生故障的應用程序組件。

　　基礎架構即代碼事件和流程緊密鏈接，這也是為什么大多數計劃使用混合或者多云部署的企業會研究其DevOps工具對基礎架構即代碼的支持，而并不使用單獨的工具。基礎架構即代碼和DevOps的集成確保事件觸發流程的正確設計和實現。

　　將基礎架構即代碼集成進DevOps還能夠幫助用戶避免常識性錯誤。如果已經有了特定的工具，并且如果基礎架構即代碼集成進了DevOps的話，使用基礎架構即代碼計劃托管資源就會更為容易。這是因為虛擬化整個部署流程以及基礎架構即代碼的資源角色會更加容易一些。DevOps工具和包會公布其支持的公有云服務，如果DevOps工具包含基礎架構即代碼組件，用戶就知道該工具能夠和列出的公有云一起工作。

　　要更加高效，基礎架構即代碼必須和DevOps緊密合作，但是同時又保持自己的特性。如果不仔細的話，就會開發出界線模糊的配置和部署實踐，并且逐漸侵蝕資源的獨立性——這其實是基礎架構即代碼的***優勢所在。在多云和混合云的部署里，維護敏捷基礎架構至關重要，因此這應該成為特定的目標。