雲端原生應用程式套件組合
雲端原生應用程式的關鍵屬性在於，它們會利用雲端的功能來加速開發。 此種設計通常代表完整應用程式會使用多種不同類型的技術。 應用程式可能會隨附在 Docker 容器中，部分服務可能會使用 Azure Functions，而其他部分可能會直接在具有硬體 GPU 加速之大型金屬伺服器上配置的虛擬機器上執行。 因為所有的雲端原生應用程式都不相同，所以很難提供單一機制來運送它們。
Docker 容器可以使用 Helm Chart 在 Kubernetes 上執行，以進行部署。 Azure Functions 可以使用 Terraform 範本來配置。 最後，您可以使用 Terraform 配置虛擬機器，但使用 Ansible 進行建置。 這是各種不同的技術，且無法將它們一同封裝為合適的套件。 直到現在。
雲端原生應用程式套件組合 (CNAB) 是由許多社群導向的公司 (例如 Microsoft、Docker 和 HashiCorp) 所共同開發的分散式應用程式封裝規格。
這項合作於 2018 年 12 月宣告，因此距離向更大的社群公開成果之前，仍有一些工作要做。 不過，目前已有開放式規格和稱為 Duffle 的參考實作。 此工具是以 Go 撰寫，為 Docker 與 Microsoft 之間的共同成果。
CNAB 可以包含不同類型的安裝技術。 這項層面可讓 Helm Chart、Terraform 範本和 Ansible Playbook 等項目共存於相同的套件中。 建置之後，套件即為獨立且可攜式；可以從 USB 隨身碟安裝。 套件會以密碼編譯方式簽署，以確保源自其宣告的合作對象。
CNAB 的核心是名為 bundle.json 的檔案。 此檔案會定義套件組合的內容，可以是 Terraform、影像或其他任何項目。 圖 11-9 定義叫用部分 Terraform 的 CNAB。 不過請注意，它實際上會定義用來叫用 Terraform 的叫用映像。 封裝完成時，位於 cnab 目錄中的 Docker 檔案會內建於 Docker 映像中，且該映像會包含在套件組合中。 在套件組合的 Docker 容器內安裝 Terraform，代表使用者不需要在電腦上安裝 Terraform 即可執行統合。
{
"name": "terraform",
"version": "0.1.0",
"schemaVersion": "v1.0.0-WD",
"parameters": {
"backend": {
"type": "boolean",
"defaultValue": false,
"destination": {
"env": "TF_VAR_backend"
}
}
},
"invocationImages": [
{
"imageType": "docker",
"image": "cnab/terraform:latest"
}
],
"credentials": {
"tenant_id": {
"env": "TF_VAR_tenant_id"
},
"client_id": {
"env": "TF_VAR_client_id"
},
"client_secret": {
"env": "TF_VAR_client_secret"
},
"subscription_id": {
"env": "TF_VAR_subscription_id"
},
"ssh_authorized_key": {
"env": "TF_VAR_ssh_authorized_key"
}
},
"actions": {
"status": {
"modifies": true
}
}
}
圖 10-18 - Terraform 檔案範例
bundle.json 也會定義一組向下傳遞至 Terraform 的參數。 套件組合的參數化，可讓您在不同的環境中安裝套件組合。
CNAB 格式也具有彈性，可讓其用於任何雲端。 它甚至可以用於內部部署解決方案，例如 OpenStack。
DevOps 決策
目前 DevOps Space 內有許多很棒的工具，甚至還有更多關於如何成功的絕佳書籍和論文。 其中一本用以展開 DevOps 旅程的熱門書籍為The Phoenix Project，其描寫了一間從 NoOps 轉換至 DevOps 的虛構公司。 有一件事是肯定的：部署複雜、雲端原生應用程式時，DevOps 不再是「加分項目」。 而是一項需求，且應該在任何專案開始時進行規劃和資源配置。
