云本机应用程序捆绑包
云原生应用程序的一个关键特性是，它们利用云的功能来加速开发。 这种设计通常意味着整个应用程序使用不同类型的技术。 应用程序可能在 Docker 容器中交付，某些服务可能使用 Azure Functions，而其他部分可能直接在采用硬件 GPU 加速的大型裸机服务器上分配的虚拟机上运行。 云原生应用程序各不相同，因此很难提供单一机制来交付它们。
Docker 容器可能会使用 Helm 图表在 Kubernetes 上运行来进行部署。 Azure Functions 可能是使用 Terraform 模板分配的。 而虚拟机可能是使用 Terraform 分配的，但却是使用 Ansible 构建的。 有各种各样的技术，并且没有方法来将它们全部打包到一个合理的包中。 这种情况到此为止了。
云原生应用程序捆绑包 (CNAB) 是多家有社区意识的公司（例如 Microsoft、Docker 和 HashiCorp）共同努力制定一种规范来打包分布式应用程序的产物。
这项成果是在 2018 年 12 月宣布的，因此要将它公开给更大型的社区，还有一些工作要完成。 不过，已经有一个开放规范和一个被称为 Duffle 的参考实现。 该工具是用 Go 编写的，它是 Docker 和 Microsoft 共同努力的结果。
CNAB 可包含不同类型的安装技术。 这使得 Helm 图表、Terraform 模板和 Ansible Playbook 等内容可在同一个包中同时存在。 生成后，包是自包含、可移植的包；可通过 U 盘安装它们。 这些包会进行加密签名，确保它们来自声明它们的一方。
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 不再是是“锦上添花”。 它是一项要求，应该在任何项目开始时就进行规划并设定资源。
