雲端原生應用程式的主要屬性是，它們會利用雲端的功能來加速開發。 此設計通常表示完整應用程式使用不同類型的技術。 應用程式可能會隨附於 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 劇本等專案並存於相同的套件中。 建置後，套件是獨立且可攜式的;您可以從 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 領域中擁有眾多優秀的工具，更不乏許多探討如何成功的精彩書籍和論文。 在開始 DevOps 旅程時的推薦書籍是 The Phoenix Project，它講述了一家虛構公司從 NoOps 轉型為 DevOps 的過程。 有一件事是確定的：在部署複雜的雲端原生應用程式時，DevOps 不再是一個「可有可無」的選擇。 這是一項需求，應該在任何專案開始時進行規劃並分配必要的資源。
