基礎設施程式碼化（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 自動化部署工具，有第三方資源編排工具，也有云服務商提供的雲原生的資源編排工具，這裡介紹四個自動化配置與編排工具：

阿里雲資源編排服務 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： 基礎設施變更的流程圖

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

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

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

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

基礎設施變更及預覽

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出品人。