共計 4652 個字符，預計需要花費 12 分鐘才能閱讀完成。

自動寫代碼機器人，免費開通

這篇文章給大家分享的是有關基礎設施代碼化 IaC 如何實現自動化配置與編排的內容。丸趣 TV 小編覺得挺實用的，因此分享給大家做個參考，一起跟隨丸趣 TV 小編過來看看吧。

云上運維，那就是和云上資源和產品打交道，無疑會涉及到一系列的資源部署。比如簡單地使用一臺云服務器，就需要運維人員依次創建 VPC、VSwitch、安全組和云服務器實例，如果想創建一個集群，那還要進一步創建負載均衡、數據庫和多個云服務器實例。

隨著業務規模的不斷擴大，IT 系統和環境日益復雜，人工一個一個創建資源的方式顯然不可取，許多人正在轉向自動化資源部署和配置的工具。

本文將基于基礎設施即代碼 IaC 理念，分享如何借助自動化編排工具實現自動化部署，使得運上運維工作更為高效。

手動 / 半手動云上運維的五大痛點

對于云上資源的部署，如果你的云上運維還處于手動或是半手動運維階段，那么大部分工作是通過控制臺選擇特定資源規格參數進行創建，還有一部分是使用  CLI（如 aliyun-cli）或者 SDK   直接調用接口來創建資源。但隨著企業的云上業務規模不斷擴大，不論是哪種方式，或多或少都會遇到下述五個問題：

部署效率低。手動創建對于創建少量種類的資源來說倒是種很直觀的方式，但一旦涉及到大量不同資源時，尤其是資源之間還有依賴關系，這時候會發現需要在不同的產品控制臺之間來回切換，還要時刻關注創建進度，才能再去創建下一個依賴它的資源，整個過程所耗費的時間和精力可想而知，相信不少人有深有體會。

可復制性差。當手動創建好了一系列的資源后，如果需要針對不同的環境（如預發、測試和生產）或不同的地域（如北京和上海）創建完全相同的資源，則又需要花費很多時間一步步地進行操作，無法直接復制、做到一鍵部署。

一致性差。手動創建還有一個非常大的問題，那就是非常容易出現配置錯誤，很難保證兩套環境中各個資源配置是完全相同的。

管理困難。資源的創建只是開始，可能還需要針對這批資源做擴縮容、更新特定資源的規格等操作。但手動運維的方式就導致沒有統一管理這批資源的入口，仍需要分別到各產品控制臺上操作。隨著資源數越來越多，資源管理就愈發難以維護。

難以 DevOps。每次開發、測試或部署軟件應用程序時都可能需要手動部署基礎設施，既無法對基礎設施進行版本控制，也無法對其變動進行評審，更無法做到敏捷部署。 

其實，我們都知道這些問題的背后是因為資源的部署還未做到自動化。但這些問題也不斷促使著我們思考應該通過什么樣的方式來解決這些痛點，才能讓整個資源部署過程自動化。

引入基礎設施即代碼 IaC 理念，實現云上資源自動化部署

在真正做到自動化部署之前，不妨回頭看看所需要創建的云服務資源（如 VPC、VSwitch、ECS   實例等），它們相對于 Web 服務等應用程序來說都是云上的基礎設施，如果把這些基礎設施想象成一段“代碼”，在“代碼”中定義產品、規格、數量等信息，那么是不是就可以通過這段“代碼”來管理整個基礎設施了呢？

這就是基礎設施即代碼（Infrastructure as Code）（IaC）的理念，將基礎設施配置視為軟件編程。Kief Morris 在《Infarftruce as Code》一書中對基礎設施即代碼是這么定義的：

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

引入 IaC 的理念，運維人員可以將基礎設施的部署和管理過程變得敏捷：

在模板（寬泛意義上的代碼）中定義基礎設施，即各類云資源及其規格、數量等屬性、云資源之間的依賴；

使用版本控制（如 Git）管理模板，并提交評審；

通過評審后由自動化部署工具使用模板來創建 / 更新基礎設施； 

基礎設施的部署和管理變得便捷后，上述提到的手動運維 / 半手動運維的痛點問題就可以得到很好的解決：

提升部署效率。使用自動化部署工具進行部署，相對于人工部署的效率將大大提升。

標準化和一致性。將基礎設施的內容通過模板的形式保存，對基礎設施的變更由對模板的變更來實現，實現了基礎設施管理的標準化。此外，使用相同的模板在不同地域部署，也能夠保證資源的一致性。

易于管理。對基礎設施的管理不再分散于各個產品控制臺，而統一到單個模板，使得管理成本大大降低。

敏捷化工作流程。通過基礎設施管理流程的規范化和標準化，資源部署的整個過程就變得敏捷。

審計和回滾。對模板進行版本管理，使得對基礎設施變動的審計和回退到某個特定版本成為了可能。

四個常見的 IaC 自動化配置與編排工具

當前，有很多 IaC 自動化部署工具，有第三方資源編排工具，也有云服務商提供的云原生的資源編排工具，這里介紹四個自動化配置與編排工具：

阿里云資源編排服務 ROS（Resource Orchestration  Service），這是云原生編排工具，通過編寫 JSON/YAML   格式的模板，在模板中定義所需的 ECS 實例、數據庫實例等云服務資源以及資源依賴關系等，然后再根據模板在 ROS 中創建資源棧，ROS   服務端將根據模板自動完成所有資源的創建和配置，實現自動化部署及運維。而資源棧則管理著模板中定義的所有資源，并可通過新模板來更新資源棧，包括資源的新增、更新或刪除等操作。

AWS CloudFormation，也是云原生的編排工具，運維人員也是通過 JSON/YAML 格式的模板定義云服務資源，通過資源棧管理這些資源。

HashiCorp Terraform，這是一個開源的自動化編排工具。以配置文件為驅動，可以在文件中定義所要管理的組件，即基礎設施資源，以此生成一個可執行的計劃，通過執行這個計劃來完成所定義組件的創建，增量式的變更和持續的管理。如果不可執行，會提示報錯。Terraform   不僅可以管理 IaaS 層的資源，如計算實例、網絡實例和存儲實例等，也可以管理更上層的服務，如 DNS 域名和解析記錄、SaaS 應用的功能等。

Pulumi，與 Terraform 一樣也是開源項目，但它與 Terraform 的重要區別在于：可以用熟悉的編程語言來編寫聲明式配置，而不需要額外學習云服務商特定的模板語言來寫配置。

對于自動化配置與編排工具的選擇，筆者的建議是：

如果你的業務部署在單一云平臺，就選擇云平臺提供的資源編排工具，在阿里云平臺就用 ROS、在 AWS 平臺就用  CloudFormation，原因很簡單：云平臺提供的工具是云原生，是免費的托管服務，在服務端就可以執行自動化部署；同時，它還實現了云原生的訪問控制、編排資源與實際資源差異檢測等功能，用起來比較省心。

如果你的業務是部署在多個云平臺，建議使用第三方的 Terraform 和 Pulumi，因為它不僅可以進行多云資源的部署和管理，還能管理除云以外的其他資源，如 Kubernetes。 

如何利用編排工具進行自動化部署和管理？

對于運維人員來說，使用 IaC 理念的自動化部署工具的門檻其實不高，使用步驟也非常簡單，主要來說就是編寫模板和使用模板。這里談談編寫模板和使用模板有哪些注意事項，如何才能更好地利用工具、更好地提升運維效率。

1、編寫模板的三個注意事項

確認好自動化部署工具，就可以根據不同工具的模板語言來編寫對應的模板文件。如果你選擇云服務商提供的云原生的編排工具，  編寫模板這里，有三點注意事項想重點提醒一下：

注意資源的依賴關系。不恰當的依賴或少了依賴都會導致資源創建出錯。

注意使用通用屬性作為參數。比如實例規格等就是比較通用的屬性，建議使用同一份模板，指定不同的參數來達到部署不同規格實例的目的。

使用有價值的屬性作為輸出。比如實例 ID、連接地址等內容就是有價值的屬性，它們都是在資源創建完成后才能獲取到，把這些屬性作為整個模板的輸出，可以方便后續的查看和管理。

2、自動解析依賴關系，自動化部署基礎設施

編寫完模板后，就可以通過對應的自動化部署工具將模板轉化為真正的資源。上述提到的編排工具都能解析資源的依賴關系，并能先后創建這些資源。同時，對于互不依賴的資源也能夠并行創建。

對于阿里云 ROS 和 AWS CloudFormation 來說，可使用模板來創建一個資源棧。一個資源棧即一組云上資源，也就是在模板中定義的基礎設施。后續當需要增 / 刪 / 改一些資源時，也是通過使用模板來更新資源棧來達到目的。

對于 Terraform 來說，可使用配置文件生成一個可執行的計劃，通過執行這個計劃來完成所定義資源 / 組件的創建，增量式的變更和持續的管理。

對于 Pulumi 來說，則是直接執行代碼來進行部署。

這樣的部署方式既能使得資源能按照合理的順序創建出來，又能夠提升部署效率，在遇到異常情況時也會進行一定程度的重試，真正讓整個自動化部署過程變得穩定和高效。

以基礎設施代碼化為基礎，進一步高效運維

當運維工作完成整個基礎設施模板化后，DevOps 就變得更加容易。我們可以使用版本管理工具（如  Git）管理描述當前基礎設施的模板，使用阿里云云效 /AWS CodePipline/Jenkins   創建一個從代碼提交觸發到人工卡點再到資源棧部署的流水線，這樣整個基礎設施的管理就會變得更加敏捷和自動化。

圖 1：基礎設施變更的流程圖

鴻蒙官方戰略合作共建——HarmonyOS 技術社區

在每次變更模板后，將本地倉庫的分支內容推送到遠程倉庫，并發起評審；

若評審不通過，則修改模板后重新發起評審；若評審通過，則自動觸發流水線；

流水線觸發人工卡點，通知上級管理員檢查此次變更。若不同意，則終止；若同意，則進入下一個步驟；

若是首次提交模板，則創建資源棧（即創建基礎設施）；反之，則更新資源棧（即更新基礎設施）。

基礎設施變更及預覽

IT 基礎設施并非一成不變，隨著業務的變化，我們可能面臨擴縮容場景，也可能面臨整個架構的變化。好在基于 IaC   的理念，我們只需要描述基礎設施最新配置，而不用擔心如何進行變更。但即使如此，我們需要在變更前知道究竟會發生哪些變化。阿里云 ROS 和 AWS  CloudFormation 的更改集功能，Terraform 的執行計劃均能讓我們提前了解到變更內容。

例如，由于業務變化，在基于圖 1 的架構基礎上，在阿里云平臺上新增一臺 ECS 實例，并使用 SLB 實例為兩臺 ECS 實例做負載均衡。在編寫好新的模板后，就可以使用更改集功能來感知變化，下圖是 阿里云 ROS 的一個變更示例：

在確認無誤后，便可以執行變更。隨后，自動化編排工具便會對整個基礎設施進行更新，根據模板發生的變化來決定新增、更改或刪除哪些資源。

基礎設施偏差檢測和糾正

盡管使用了自動化編排工具部署資源，仍可能有部分人員會通過非標準化的方式（比如通過控制臺或  API）修改了基礎設施中部分資源的屬性，使得資源實際情況和模板中定義的資源產生了差異。好的自動化編排工具不僅具備檢測基礎設施實際屬性和模板中定義的屬性之間差異的能力；還能基于差異結果糾正模板或實際資源，使得模板和基礎設施保持一致。

當前，通過 阿里云 ROS 和 AWS CloudFormation 的偏差檢測能力，就可以輕松地發現實際資源和模板中定義的資源之間的差異，并可通過偏差糾正功能使模板內容和實際資源保持一致。

感謝各位的閱讀！關于“基礎設施代碼化 IaC 如何實現自動化配置與編排”這篇文章就分享到這里了，希望以上內容可以對大家有一定的幫助，讓大家可以學到更多知識，如果覺得文章不錯，可以把它分享出去讓更多的人看到吧！

向 AI 問一下細節

丸趣 TV 網 – 提供最優質的資源集合！