雲上運維，那就是和雲上資源和産品打交道，無疑會涉及到一系列的資源部署。比如簡單地使用一台雲伺服器，就需要運維人員依次建立 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 理念的自動化部署工具的門檻其實不高，使用步驟也非常簡單，主要來說就是編寫模闆和使用模闆。這裡談談編寫模闆和使用模闆有哪些注意事項，如何才能更好地利用工具、更好地提升運維效率。
編寫模闆的三個注意事項
确認好自動化部署工具，就可以根據不同工具的模闆語言來編寫對應的模闆檔案。如果你選擇雲服務商提供的雲原生的編排工具，比如阿裡雲 ROS，就遵循 ROS 文法編寫 JSON/YAML 格式的模闆；選了 Terrafrom，那就遵循 Terrafrom 文法編寫基于其領域特定語言 HCL 的配置檔案；如果用了 Pulumi，就遵循通用程式設計語言（TypeScript/JavaScript/Python/Go/C#）文法使用 Pulumi SDK 編寫代碼。編寫模闆這裡，有三點注意事項想重點提醒一下：
注意資源的依賴關系。不恰當的依賴或少了依賴都會導緻資源建立出錯。
注意使用通用屬性作為參數。比如執行個體規格等就是比較通用的屬性，建議使用同一份模闆，指定不同的參數來達到部署不同規格執行個體的目的。
使用有價值的屬性作為輸出。比如執行個體 ID、連接配接位址等内容就是有價值的屬性，它們都是在資源建立完成後才能擷取到，把這些屬性作為整個模闆的輸出，可以友善後續的檢視和管理。
自動解析依賴關系，自動化部署基礎設施
編寫完模闆後，就可以通過對應的自動化部署工具将模闆轉化為真正的資源。上述提到的編排工具都能解析資源的依賴關系，并能先後建立這些資源。同時，對于互不依賴的資源也能夠并行建立。
•對于阿裡雲 ROS 和 AWS CloudFormation 來說，可使用模闆來建立一個資源棧。一個資源棧即一組雲上資源，也就是在模闆中定義的基礎設施。後續當需要增/删/改一些資源時，也是通過使用模闆來更新資源棧來達到目的。
•對于 Terraform 來說，可使用配置檔案生成一個可執行的計劃，通過執行這個計劃來完成所定義資源/元件的建立，增量式的變更和持續的管理。
•對于 Pulumi 來說，則是直接執行代碼來進行部署。這樣的部署方式既能使得資源能按照合理的順序建立出來，又能夠提升部署效率，在遇到異常情況時也會進行一定程度的重試，真正讓整個自動化部署過程變得穩定和高效。
以基礎設施代碼化為基礎，進一步高效運維
當運維工作完成整個基礎設施模闆化後，DevOps 就變得更加容易。我們可以使用版本管理工具（如 Git）管理描述目前基礎設施的模闆，使用阿裡雲雲效/AWS CodePipline/Jenkins 建立一個從代碼送出觸發到人工卡點再到資源棧部署的流水線，這樣整個基礎設施的管理就會變得更加靈活和自動化。
圖1：基礎設施變更的流程圖
在每次變更模闆後，将本地倉庫的分支内容推送到遠端倉庫，并發起評審；
若評審不通過，則修改模闆後重新發起評審；若評審通過，則自動觸發流水線；
流水線觸發人工卡點，通知上級管理者檢查此次變更。若不同意，則終止；若同意，則進入下一個步驟；
若是首次送出模闆，則建立資源棧（即建立基礎設施）；反之，則更新資源棧（即更新基礎設施）。
基礎設施變更及預覽
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出品人。