小窍门
Azure 平台的云原生 .NET 应用电子书封面缩略图。
云原生应用程序的一个关键属性是，它们利用云的功能来加快开发速度。 这种设计通常意味着完整的应用程序使用不同类型的技术。 应用程序可能在 Docker 容器中提供，某些服务可能使用 Azure Functions，而其他部分可能直接在硬件 GPU 加速的大型金属服务器上分配的虚拟机上运行。 没有两个云原生应用程序是相同的，因此很难提供单个机制来传送它们。
Docker 容器可以使用 Helm 图表在 Kubernetes 上运行，以便进行部署。 可以使用 Terraform 模板配置 Azure Functions。 最后，虚拟机的分配可以使用 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 不再是可有可无的选项。 这是一项要求，应在任何项目开始时妥善规划和提供资源。
