基礎設施代碼化（IaC）的自動化配置與編排

雲上運維，那就是和雲上資源和產品打交道，無疑會涉及到一系列的資源部署。比如簡單地使用一台雲伺服器，就需要運維人員依次創建 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 自動化部署工具，有第三方資源編排工具，也有雲服務商提供的雲原生的資源編排工具，這裡介紹四個自動化配置與編排工具：

1. 阿里雲資源編排服務 ROS（Resource Orchestration Service），這是雲原生編排工具，通過編寫 JSON/YAML 格式的模板，在模板中定義所需的ECS實例、資料庫實例等雲服務資源以及資源依賴關係等，然後再根據模板在 ROS 中創建資源棧，ROS 服務端將根據模板自動完成所有資源的創建和配置，實現自動化部署及運維。而資源棧則管理著模板中定義的所有資源，並可通過新模板來更新資源棧，包括資源的新增、更新或刪除等操作。
2. AWS CloudFormation，也是雲原生的編排工具，運維人員也是通過 JSON/YAML 格式的模板定義雲服務資源，通過資源棧管理這些資源。
3. HashiCorp Terraform，這是一個開源的自動化編排工具。以配置文件為驅動，可以在文件中定義所要管理的組件，即基礎設施資源，以此生成一個可執行的計劃，通過執行這個計劃來完成所定義組件的創建，增量式的變更和持續的管理。如果不可執行，會提示報錯。Terraform 不僅可以管理 IaaS 層的資源，如計算實例、網路實例和存儲實例等，也可以管理更上層的服務，如DNS 域名和解析記錄、SaaS 應用的功能等。
4. Pulumi，與 Terraform 一樣也是開源項目，但它與 Terraform 的重要區別在於：可以用熟悉的編程語言來編寫聲明式配置，而不需要額外學習雲服務商特定的模板語言來寫配置。

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

1. 如果你的業務部署在單一雲平台，就選擇雲平台提供的資源編排工具，在阿里雲平台就用 ROS、在 AWS 平台就用 CloudFormation，原因很簡單：雲平台提供的工具是雲原生，是免費的託管服務，在服務端就可以執行自動化部署；同時，它還實現了雲原生的訪問控制、編排資源與實際資源差異檢測等功能，用起來比較省心。
2. 如果你的業務是部署在多個雲平台，建議使用第三方的 Terraform 和 Pulumi，因為它不僅可以進行多雲資源的部署和管理，還能管理除雲以外的其他資源，如 Kubernetes。

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

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

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

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

1. 注意資源的依賴關係。不恰當的依賴或少了依賴都會導致資源創建出錯。
2. 注意使用通用屬性作為參數。比如實例規格等就是比較通用的屬性，建議使用同一份模板，指定不同的參數來達到部署不同規格實例的目的。
3. 使用有價值的屬性作為輸出。比如實例 ID、連接地址等內容就是有價值的屬性，它們都是在資源創建完成後才能獲取到，把這些屬性作為整個模板的輸出，可以方便後續的查看和管理。

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

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

• 對於阿里雲 ROS 和 AWS CloudFormation 來說，可使用模板來創建一個資源棧。一個資源棧即一組雲上資源，也就是在模板中定義的基礎設施。後續當需要增/刪/改一些資源時，也是通過使用模板來更新資源棧來達到目的。
• 對於 Terraform 來說，可使用配置文件生成一個可執行的計劃，通過執行這個計劃來完成所定義資源/組件的創建，增量式的變更和持續的管理。
• 對於 Pulumi 來說，則是直接執行代碼來進行部署。

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

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

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

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

1. 在每次變更模板後，將本地倉庫的分支內容推送到遠程倉庫，並發起評審；
2. 若評審不通過，則修改模板後重新發起評審；若評審通過，則自動觸發流水線；
3. 流水線觸發人工卡點，通知上級管理員檢查此次變更。若不同意，則終止；若同意，則進入下一個步驟；
4. 若是首次提交模板，則創建資源棧（即創建基礎設施）；反之，則更新資源棧（即更新基礎設施）。

基礎設施變更及預覽

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

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

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

基礎設施偏差檢測和糾正

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

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

總結

在 IT 基礎設施全面上雲的趨勢下，雲上手工運維的方式已難以為繼，出現了部署效率低、可複製性差、一致性差、管理困難、難以 DevOps 等痛點。阿里雲 ROS/AWS CloudFormation/Terraform/Pulumi 等自動化編排工具都是基於基礎設施即代碼（IaC）的理念，可以通過模板來定義基礎設施，同時標準化和自動化整個部署過程，配合更改集、偏差檢測等能力，再結合流水線，真正實現了 IT 基礎設施管理的 DevOps。建議運維人員可以重點關注和巧用工具，將幫助你更好的提升運維效率，解放生產力。

作者介紹：

王斌鑫，從事阿里雲彈性計算資源編排工具的研發工作，熱愛開源和寫作。阿里雲凌雲時刻出品人、PyCon China出品人。

本文轉載來自 Linux 中國: https://github.com/Linux-CN/archive