定義多雲環境下的自動化工具與流程

雲端環境的主要優勢之一是可以自動化幾乎所有事情。 在雲端環境中執行許多手動作業是最無效率最笨的事情。 所以我們應該在雲端基礎設施管理方面盡可能地實現自動化。 我們如何將我們的自動化能夠跨越多個雲端，我們需要有哪些流程，以及誰將負責管理自動化模板？

本文將介紹抽象環境中自動化的核心原理。 我們將討論與主要雲端業者(以下簡稱CSP，如AWS、Azure 和 GCP)整合的自動化工具。 接下來，我們將研究如何設計自動化流程，首先將代碼存儲在單一個存儲庫中，然後將版控應用於這個代碼。 也會簡要討論定義自動化時的主要缺陷。

在本文中我們將會介紹以下幾個議題：

• 跨雲端的基礎設施自動化
• 使用單一儲存庫與工作流程建立自動化流程
• 自動化工具的使用
• 對多雲環境設計自動化

跨雲端的基礎設施自動化

在我們開始考慮自動化本身之前，我們需要對 IT 中的所有組件進行虛擬化。如果我們必須將實體設備放入資料中心，那麼自動化根本不起作用 — — 除非我們有機器人來幫我們做。因此，它從虛擬化開始，這正是 VMware 仍然在雲端領域發揮如此重要作用的原因。 他們的SDDC(Software-defined data center) 概念基本上是構建雲端的藍圖。我們必須虛擬化整個堆疊：運算、存儲和網路。

只有虛擬化的entities可以存儲在儲存庫中，並從那裡以寫程式的方式按我們需要的來提供。如果我們希望這是真正的多雲環境，這些虛擬化組件的互通性是自動化的關鍵。

虛擬化是起點，但它是真正的跨平台的。然後我們會發現很多系統仍然非常依賴底層實體基礎設施中的設置，即使在主要 CSP 的超大規模公有雲中也是如此。讓我們以VM為例：我們可以告訴實體主機它可以通過使用hypervisor在多個虛擬機之間共享其 CPU 和 RAM，但所有這些虛擬機仍然需要自己的guest OS。

解決這個問題的一種方法是使用容器。 正如我們在多雲環境的雲端服務設計中看到的，容器沒有自己的OS。 他們使用實體或虛擬主機的OS。 然而，容器確實需要一個可以託管和編排這些容器的平台。 這就是需要K8S這一類的容器平台的地方。主要CSP都有K8S服務（GKE/EKS/AKS），但對於容器的使用，我們需要構建和配置基礎設施。 使用容器並不意味著我們可以跳過基礎設施的構建。

本質上，它歸結為抽象層。 我們必須確保application layer不依賴於infrastructure layer：Application layer不用知道它跑在什麼樣的infrastructure layer。 我們先來看看這些layer的邏輯視圖：

• Access layer:
  包括網路和介面。 我們需要網路來獲得從雲端外部到託管在雲平台上的環境的網路連接以及平台內的網路連接，以便應用程式可以相互通訊或與 DB的通訊。 Access layer還包含到 Service Layer的互連； 這可以是一個portal或任何我們可以用來在 Service Layer中訂購和配置服務的command interface。
• Application layer:
  這個layer包含應用程式的 應用程式代碼和配置代碼(Configuration code)。 它與所有其他layer完全分開。
• Service layer:
  這是定位IaaS、PaaS、SaaS。 IaaS 包含用於伺服器或存儲的服務。 PaaS 用於託管服務，例如 GCP的GKE 或 Redhat Openshift。 SaaS 包含一站式的業務服務，例如辦公自動化 — — 如 MS-O365。
• Resource layer:
  這是建構區塊用於service layer中。 在這一層，我們有一個用於 CPU、disk、NIC 等的實體資源池。 這些是構建伺服器並使其可以通過網路連接存取所需的資源。 這個layer還包含一個邏輯資源池，例如 OS 和 Runtime。

下圖呈現了抽像的資料中心以將其虛擬化並提供在雲端平台上部署環境的邏輯視圖的概念：

在之前(地端機房的時代)，部署 IT 環境曾經是一個非常人力密集且成本高昂的過程，在我們還沒有類似IaC的方法之前，需要花費大量的精力和時間。 除了定義架構之外，我們確實需要對資料中心所需的實體機器進行適當的調整。 機器的大小或訂購錯誤的機器的錯誤都可能會導致容量不足或過多的情況。 訂購機器後，我們需要將它們安裝到資料中心，然後才能真正開始部署工作負載 — — 這個過程很容易占用整整幾個月的工作時間。

現在，我們擁有虛擬化整個資料中心的技術，甚至更好：我們使用 AWS、Azure 和 GCP 提供的現有資料中心。 他們已經從reslurce、service和access layer中找出了很多我們可以使用的建構區塊來組成我們的環境。 這些建構區塊是代碼。 將建構區塊放在一起是唯一剩下要做的事情。 雲端自動化正是將它們組合在一起的步驟。 如果我們找到了一種將不同layer的建構區塊放在一起的方法，並且我們想要經常重複這個過程，那麼自動化形成這個過程的步驟是有意義的。 這將節省我們的時間和成本； 而且，通過自動化，出錯的風險將低於人工作業。

使用單一儲存庫與工作流程建立自動化流程

在多雲環境的雲端服務設計中，我們簡單的討論了 CI/CD流水線。 在本節中，我們將進一步探討這一點，因為 CI/CD流水線是我們自動化的關鍵部分。 下圖呈現流水線的high-level view：

流水線是從版控和實際的應用程式代碼開始。要啟動版控，我們需要 source code 。source code通常存儲在 source code repo中。獨立存儲庫的一個範例是 Git，例如 GitHub、Gitlab 或 BitBucket。但是，每個雲端都有自己的repo服務，而企業甚至可以在地端機房有自己的存儲庫。Automation pipeline configuration從變更代碼或分支代碼的請求開始。通過分支，我們正在建立一個新分支，我們可以在其中進一步開發代碼。這個分叉的代碼可以在經過驗證和測試後提交回主分支。

在任何情況下，該請求都會觸發 CI流水線中的一個流程，該流程將為下一階段準備代碼。這是構建階段，代碼被封裝成可以部署到我們環境中的組件。這封裝的package不僅包含應用程式代碼，還包含用於部署代碼的所需資源的package。資源可以是 VM、storage block或容器。最後，在我們開始部署之前，所有這些package都需要根據所需的狀態和策略進行測試和驗證，之後整個部署過程就完成了。

在雲端環境中自動化其基礎設施的常見流程如下：

• VM的自動產生
• 對基礎設施組件部署DSC(Desired State Configuration)
• 部署備份排程
• 擴展(scaling)和故障轉移(failover)場景的工作流程自動化

最重要的自動化任務是建立IaC 並將其存儲在repo中。 使用自動化工具，我們可以從repo中分叉項目。 這就是為什麼abstraction in Layer至關重要的原因。 每個item或component都在代碼中定義：VM、storage block、網路參數和容器。 根據應用程式代碼和為運行此應用程式代碼而定義的package，自動化工具將知道它應該如何組裝component，然後將它們部署到我們的環境中。 例如，如果應用程式需要多個容器，該工具可以建立這些容器並將它們配置為運作K8S node內、連接存儲、配置負載平衡和應用網路政策。 整個workflow可以變成自動化中的流程。

但是除了環境的自動化部署之外，自動化工具還可以做更多的事情並且有其效益。自動化也可用於管理整個環境。當應用程式的效能下降時，我們可以使用自動化來執行資源擴展或修復等作業。這就是為什麼自動化工具需要與監控相結合的原因。如果此監控偵測到環境正在經歷高負載或效能下降，它可以觸發自動化執行預先定義的回應：例如，添加額外的VM、增加存儲容量和添加負載平衡。另一方面，如果偵測到環境或組件處於idle狀態，則可以觸發自動化以刪除不再需要的這些組件，從而節省成本。

配置、管理和刪除組件與一個流程相關聯 — — 一個需要仔細定義的workflow。例如，如果VM與環境中的其他組件有連接，則僅刪除VM可能會導致故障。自動化需要了解這些連接和其他交互(interactions)。

如果我們將新的工作負載自動部署到我們的環境中，這同樣適用：這些工作負載應該與哪些其他組件對接？ 自動化不是我們只要打開然後等待像魔術一樣發生的事情。 我們需要在自動化工具中定義和設計workflow。 下圖呈現了自動部署VM的workflow範例：

自動化工具的使用

談到雲端自動化， 市場上有一大堆的工具或解決方案。 CSP本身也提供原生工具。

Azure Automation

Azure 自動化提供了多種解決方案來自動執行 Azure 中部署基礎設施的重複性作業。 使用 DSC 有助於使基礎架構保持標準、一致和合規。 所以我們需要review一下 DSC，因為它是雲端自動化的一個重要面向。

進行自動化的主要原因有兩個：降低運營成本，這樣做可以防止雲端管理員因為執行過多的手動和重複性作業而造成的人為錯誤。 DSC 是開始自動化的一種方式。 如果我們運行一個server farm，我們可能會發現隨著時間的推移，這些伺服器上的設定已經改變並且實際上每一台都可能不太一樣。 如果有充分的理由允許這些差異，那麼這不一定是問題，應該使用新版的 DSC 進行記錄。

在較大的server farm中，檢查和手動更新伺服器是一項繁瑣、耗時的作業。 我們希望通過一種工具來自動化這個過程，該工具可以監控伺服器是否仍然套用了正確的設定和政策，如果不是這樣，則自動修復這些設定和政策。 新部署的伺服器也將自動套用這些設定和政策。 這是 DSC 提供的標準化的效益。

Azure Automation是管理 DSC 的工具：它處理configuration和update management。但 Azure Automation最有趣的部分是流程自動化。 Azure 為此使用 Runbook Automation。這意味著我們可以在 使用PowerShell 或Python 以圖形方式建立runbooks。 Runbook 讓我們可以在 Azure 中部署和管理工作負載，也可以在我們在地端機房或其他雲端（例如 AWS）中託管的系統上部署和管理工作負載。我們甚至可以將帶有 webhook 的runbook整合到監控系統中。這可以是 ITSM 平台，例如 ServiceNow。當然，Azure Automation與 Azure DevOps 是高度整合的，我們可以在其中定義完整的 DevOps projects，包括 CI/CD 流水線。

Runbook 中的關鍵概念是執行我們建立的指定作業的作業順序。 Worker 可以在 Azure 中的不同資源之間共享，但一次只能分配給一個job。從 CI/CD 或監控中的trigger開始，這個job會分配了一個worker。接下來，它完成了實際的runbooks — — 例如，將政策套用在VM上。

雲端中的一切基本上都是一個identity：在這種情況下，identity是分配給要進行該項job的worker。這個worker將需要存取執行job所需的資源。這意味著我們必須確保worker擁有正確的權限並針對 AD進行身份驗證。否則，job就會失敗。

AWS OpsWorks

與 AWS 中的許多工具一樣，OpsWorks 與第三方工具整合。 OpsWorks 的功能可與 DSC 的PowerShell 和 Azure Automation相比，但 OpsWorks 與 Chef Automate 或 Puppet Enterprise 整合。 OpsWorks 還有一個名為 OpsWorks Stacks 的原生服務。

Stacks與Layer是結合在一起作業的。 一個layer可以是一組VM，從 AWS 中的EC2部署。 這個layer將部署 Web server或DB server。 接下來，Stacks 可以在基礎架構上部署Application layer。 儘管 Stacks 是一項原生服務，但它確實使用 Chef 作為其底層技術。 事實上，它使用 Chef 的recipes來自動部署layer，以及安裝應用程式和腳本。 如果需要，它還會套用autoscaling，並在stacks上安裝監控。

CHEF automate加上OpsWorks 則更進一步。 這個服務需要在我們的環境中有保存cookbook的 CHEF server。 它不僅部署server stack，還應用配置策略，實施基於 LDAP 或 SAML 的存取控制，將其整合起來。 我們可以為完整部署定義workflows — — 也可以使用一些安全框架（例如 CIS 的安全框架）用於容器化環境、合規性和安全檢查。

同樣，CHEF 也能用在Layer。這些layer的主要部分是attributes和resources。attributes包含我們要安裝的系統的詳細資訊：節點(node)。 CHEF 評估node的當前狀態和應該要的狀態。為了達到應該有的狀態，它在 從AWS 的package/template/services所使用resource來描述所需狀態。在底層，CHEF 使用 JSON 和 Ruby，因此在使用 CHEF 時，最好了解這些腳本語言。

CHEF 提供完整的雲原生cookbooks，並使用cookbook建立應用程式環境。它確實需要有關如何定義這些cookbook的知識。如之前所述，我們將在其他的文章中更詳細地探討這一點。最好的部分是我們可以使用已經由社區開發和測試的cookbook，並且可以從 GitHub 下載。

我們可以使用的其他工具集是 OpsWorks for Puppet Enterprise。在這種情況下，我們將部署控制 AWS 中的基礎設施的 Puppet master server。 Puppet 使用包含 AWS 中基礎設施組件所需狀態的modules。使用 Puppet，我們可以像使用 CHEF 一樣部署、配置和管理系統，無論它們是在 AWS 中使用 EC2 還是在地端機房。它將部署系統、安裝OS、配置資料庫並註冊所需的狀態政策，所有這些都形成了我們可以在開發工具包中定義自己或從 Puppet Forge 使用的workflow，其中一個大型community為 Puppet module做出貢獻。

GCP的自動化

到目前為止，我們應該清楚的是，通過將環境抽象為單獨的可識別的層次(layer)，可以自動部署和管理我們的環境。 我們可以部署完整的應用程式堆疊並使用我們定義的政策對其進行配置，以確保所有這些堆疊都是一致與合規的。 由於我們確實將堆疊作為一個整體而無需接觸其他組件．既然都是代碼，我們就只需要管理代碼，而不需要管理底層的實體設備，比如伺服器、交換機、路由器、電腦機架、電纜。 所有這些實體設備部分都由 CSP 負責。

在 GCP 中，我們有跟在 Azure 和 AWS 中看到的完全相同的概念。 GCP 自動部署的package和scripts。 非常簡單地解釋，Package就是what，而scripts就是how。 Package包含必須部署的工件(artifacts)，而scripts定義了package的部署方式。 使用scripts，靠定義好將我們要託管的系統放在GCP的project中，然後實際部署package，最後執行測試腳本以確保 系統可以被訪問並且它們按設計運作。

其他的自動化工具

我們討論了與 AWS、Azure 和 GCP 整合的原生工具。 我們還提到市面上有更多可用的工具。 CHEF、Puppet、Terraform、Spinnaker (最初是在 Netflix 創建的)和 Ansible 等只是其中的幾個。 要記住，所有這些工具都有強大的資產，但可能並不總是適合我們設定目標的工具。 俗話說，如果如果我們手上只有鐵鎚，那麼每個問題看起來都像釘子。 更好的說法是：該工具應該滿足我們的需要。 經常檢查我們手中的工具集很重要。 這是一個團隊的努力：允許雲端中的開發人員和解決方案構建者評估工具集並讓他們提出改進建議。

更多的DevOps工具可參考此網址．

對多雲環境設計自動化

自動化似乎是雲端中的聖杯，但我們應該避免一些主要的陷阱。 雲端中自動化專案失敗的三個主要原因如下：

• 讓自動化過於複雜：
  雲端中的任何事物一樣，我們應該在開始之前制定計劃。 我們必須考慮layer：我們在哪個layer部署了哪些component，這些是重複性動作嗎？ 想出執行這些動作的最簡單方法，以便讓它們非常容易重複。 例如，開新的VM 很可能就是這樣的任務。 我們會做什麼來建立VM？ 我們確定機器應該放在哪裡，建立機器，然後安裝OS。 這是我們可以自動化的三個基本步驟。
• 嘗試自動化每件事：
  例如PaaS 解決方案。 許多雲原生應用程式使用 PaaS，只需一個命令即可觸發。 該命令的觸發器是我們可以包含在自動化腳本中的東西，但不是服務本身。 我們也許可以這樣做，但我們不應該這麼做：這太複雜了。 這個陷阱與第一個陷阱密切相關：使自動化過於複雜。
• 無視相依性：
  如果流程因自動化腳本中不可用的第一個組件而失敗，自動化就沒有意義。 這意思是， 自動化腳本呼叫雲端環境中的組件。 這就是orchestration的有用的地方。通過自動化，我們呼叫 CSP 提供的許多特定服務，但這些呼叫必須按特定順序進行。
  例如，如果我們從自動化腳本部署DB，我們應該首先配置並確認DB server已啟動並且 OS已經ready，然後再部署DB，最後才是實際資料。 自動化的一個好的做法是服務可以獨立自動化，這樣如果另一個組件不可用，它們就不會掛掉。 如果部署DB的自動化腳本沒有找到要實例化的 VM，它應該只是停住並等待服務器上線，而不是繼續安裝DB。 這種現象稱為lock-step。

那麼，我們如何開始呢？ 這個問題的答案是版控。 如果我們沒有以邏輯方式來存儲代碼，我們就無法開始自動化。 這從source code開始，但是所有不同組件的所有迭代都需要歸檔在一個repo中，這個repo可供使用它的每個人共享和存取。 這不僅確保了代碼可以在每次迭代中被重覆使用和改進，而且還可以追踪誰更改了代碼以及它是如何變更的。 在系統發生故障的情況下，我們可以在發生故障時將變更追溯到哪個正常的版本。

對於版控，我們可以使用 Git，但還有更多可用的工具，例如 Subversion。 真正重要的是我們必須將所有代碼置於版控之下。 從下面的清單中，我們將明確識別不同的抽象層：

• Application code
• Runtime scripts
• 環境中任何建構區塊的部署腳本。 這些可以是image building腳本，也可以是 CHEF recipes或 Puppet module。
• Buildpacks for containers
• 用於封裝和產生組件的腳本，例如 DB，以及在容器化的情況下的K8S nodes和 Pod。
• 針對desired state的配置檔案，像是AWS CloudFormation, Azure DSC與 Terraform 檔案
• 針對核心與邊緣組件的配置檔案，像是防火牆設定與DNS參數檔案

從source code和version control，我們將設計自動化流程。 如果我們在分層和版本方面做得很好，那麼我們可以從三個類別開始設計自動化：

• Application code
• System configuration
• Application configuration

從應用程式中，我們在system layer定義我們需要哪些資源。 然後，我們建立流程以將系統配置為desired state，以便它們準備好運行應用程式代碼。 讓我們以一個簡單的 Web application為例，它包含一個 Web server、Application server和一個我們使用 PaaS 服務的DB。 我們將如何自動化部署這個堆疊？ 在下圖中，顯示了一個更詳細的工作流程，與圖中的工作流程相鄰：

在什麼是多雲(Multi-Cloud)文章中，我們介紹了 12 因子應用程式。 12 因子應用程式是真正自動化的。 12 因子中的第一個是code base：我們將存儲所有代碼的單一個repo。 第二個因子是關於確保組件具有非常清晰的 — 明確的— 對依賴關係的描述。 第三個因素是關於configuration：配置與應用程式代碼本身是分開的。 根據這些，我們再次有了我們的layers。

結論

在本文中，我們討論了自動化的基本原理。 我們已經學會了如何在不同的層次中抽像我們的環境：application、system和configuration。 我們研究了在 AWS、Azure 和 GCP 中實現自動化的工具，並發現我們可以使用更多工具在多雲環境中自動部署和管理系統。 我們已經學會了如何開始設計自動化流程，並且版控在自動化中至關重要。