用代码定义基础设施可以帮助我们方便的构建、跟踪基础设施，但代码本身隐含着逻辑和变化，对于基础设施来说，定义为数据更为恰当。原文：Shifting from Infrastructure as Code to Infrastructure as Data[1]
图片来源：Dzero Labs
人人想要 IaC
我一直被“基础设施即代码”(IaC，Infrastructure as Code)的理念所吸引。早在 2014 年，我的职责就是帮助团队安装供应商产品的新版本，不仅包括安装新软件，还包括配置新硬件。那时还没有云计算(至少在我工作的组织中是这样)，意味着我们只能以非常痛苦的手动过程来配置新的虚拟机，需要写大量的文档和通过很多审批。尽管我们已经设法提供了虚拟机并装好了软件，但还是有很多技术和政治障碍。
那时候我就想，“这真的很有趣!(呃……也许除了政治……)如果能找到一份既能配置硬件，又能应用软件技能的工作，那就太好了。”我感觉好像发现了一些东西……😉
快进到 2021 年，现在处于云时代，如果不是通过编程的方式，根本无法想象如何配置和管理 IT 基础设施(网络、虚拟机、Kubernetes 集群、负载均衡器等)，我们进入了基础设施即代码(IaC)的时代。
凭空创造基础设施？
图片来源：Sanketh Hiremath @unsplash
最重要的是，我们需要理解当使用 IaC 时，基础设施不是凭空产生的。让我们再深入挖掘一下……
很多人都知道公有云。公共云包括亚马逊的 AWS[2]、谷歌的 GCP[3]、微软的 Azure[4]、甲骨文的 OCI[5]、IBM Cloud[6]等等。这些公有云的底层是一个遍布全球的庞大数据中心网络，拥有堆积如山的硬件，所有这些硬件都由云服务商自己的框架管理。
尽管基础设施可能会被认为是无限的，但实际上私有云只有有限的物理基础设施。有两种私有云类型：内部的和托管的。内部私有云托管在组织自己的机房或数据中心，托管私有云由第三方服务提供商拥有和运营。托管私有云可以是单租户(专用于一个公司的数据中心)，也可以是多租户(托管多个公司的数据中心)。 像 OpenStack[7]、Apache CloudStack[8]、Azure Stack[9]、IBM Cloud Private[10]等框架都可以用来管理私有云。
当我们在公有云或私有云中提供基础设施时，一般会通过 API 进行配置，API 与数据中心管理框架通信，数据中心管理框架从可用物理资源池中为我们提供虚拟资源(如虚拟磁盘、虚拟网络、虚拟机)。
最佳实践
在配置云基础设施时，我们应该始终遵循以下关键实践，从而让我们始终保持愉悦、减少压力：
1. 短生命周期（Ephemerality）
云基础设施的生命周期应该比较短，如果需要对基础架构进行变更，请将其拆除并重新创建。如果现在还是手动变更的，那就更有理由需要这样做了。更新配置文件，把变更纳入版本控制，这样就可以跟踪所有变更。
永远不要害怕多次创建和破坏基础设施。如果很好的定义了基础架构，每次重新创建时，它都会以相同的方式运行，所以有什么可怕的呢？
注意：基础架构应该是不可变的，无状态组件的生命周期应该是短暂的，而有状态组件则不是。数据库和事件中心不能随便拆除和重新配置。这个过程应该完全自动化，但是重新分配一个数据库或者像 Kafka 这样的事件中心可能会非常复杂并具有破坏性。
2. 版本控制（Versioning）
始终对基础架构定义进行版本控制，以便在需要时轻松重新创建资源。
3. 简单化（Simplicity）
一旦基础设施自动化过程变得过于复杂，并发现自己试图方枘圆凿，请立即停下来。例如，如果发现自己的工作超出了 API 或基础设施配置工具的限制，那么是时候进行备份并重新考虑策略了。
基础设施即数据（Infrastructure as Data）
撇开最佳实践不谈，在供应云基础设施时，还有一件事我们还没有解决。当我们为云基础设施编写代码时，我们真的是在编写代码吗？答案是否定的。😱
让我们回到开始的地方，当我不得不以老式的方式提供基础设施时，必须将一组规格或清单交给能够满足我要求的团队。对于基于云的基础设施，我们也在做同样的事情——只是我们的规范现在是由 API 传递和实现的，而不是由一个人。你不用关心这个请求是如何被实现的，只需要知道它被准确的实现了。
举个例子，如果你准备创建一个有 5 个节点的 Kubernetes 集群，集群上的工作负载是内存密集型的，你希望节点拥有高 RAM 和中等计算能力。当你告诉谷歌启动 GKE 集群时，只需要告诉它启动 5 个 RAM 密集型计算节点。当你创建集群时，不会在意幕后发生了什么，只关心最终得到了想要的那个集群。
因此，我们需要做的只是描述想要创建的资源，这意味着我们应该使用一些常见的格式，如 JSON 或 YAML 来描述它们。什么是 JSON 和 YAML？它们只是表示数据的纯文本。🤯
这个概念不是最近才出现的，事实上，Ansible 的创始人迈克尔·德哈恩(Michael DeHaan)[11]在 2013 年的一篇博客文章[12]中就说过：
"...基础设施最好的建模方式不是代码，也不是 GUI，而是基于文本的、中立的、数据驱动的策略。"
在文章的后面，他创造了一个术语“基础设施即数据”(IaD，Infrastructure as Data)来描述这个概念。
IaD 是一种对基础设施的声明式方法——也就是说，你只要说出想要的内容，而不指定实现它的精确操作或步骤。这是 Kubernetes Controllers[13]，许多 CI/CD 工具(比如 GitHub Actions[14])，当然还有 Ansible[15]的概念。
谁会关心？
到这个时候，你可能想知道为什么我要花这么多精力试图说服你，IaD 是比 IaC 更好的范式。嗯，这么想很正常。
实话实说，这可以归结为一个词：简单。我已经花了足够的时间在 GCP 和 Azure 上配置云基础设施，可以告诉你，当你开始扩展基础设施时，事情会变得非常复杂。
当然，你会希望以一种良好的、结构化的方式配置和管理基础设施。老兄，这就是 JSON 的作用。但是要编写代码来实现？老实说，这毫无意义，基础设施是静态的，不是应用程序。
将基础设施视为代码打开了技术债的大门。记住，并不是所有的代码都是平等的，糟糕的代码会让你的生活变成人间地狱。
它也会带来不必要的复杂性。为什么你需要管理一大堆代码来定义基础设施，而实际上你所需要做的只是描述它？
配置云基础设施的方法
我们暂时把 IaD 放在一边，转而讨论配置云基础设施。我保证这是有意义的，请耐心听我说。
配置云基础设施的方法有很多。当我们进行配置时，这些方法会执行我们的代码，或者某些框架会解释我们的基础架构定义。下面我们粗略看一下这些不同的方法。
Terraform
Hashicorp[16]的 Terraform[17]是非常流行的平台中立工具，用于为各种公有云和私有云框架提供基础设施。它基于专有的类 JSON 的语言 HCL（Hashicorp Configuration Language）[18]来定义基础设施，支持一些非常简陋的循环、条件以及变量。Terraform 依赖一个 JSON 状态文件[19]来跟踪创建的基础设施，可以将此文件视为结构化日志。
Pulumi
几个前微软员工[20]创立了 Pulumi[21]，目标直指广阔的 Terraform 市场。它也是平台中立的，借用了 Terraform 的许多概念，包括状态文件。主要的区别是 Pulumi 允许通过使用常规的 ole 编程语言来创建基础设施。Pulumi 目前支持的语言包括：TypeScript、Javascript、Python、Go 和 C#。
注：Terraform 最近通过推出 Pulumi 风格的 Terraform CDK[22]来反击 Pulumi。
Ansible
虽然一开始 Ansible 只是一个配置管理工具，但现在也可以用来配置和管理云基础设施[23]。Ansible 使用 YAML 来定义基础设施。与 Terraform 和 Pulumi 不同的是，Ansible 是无状态的。
Crossplane
Crossplane[24]是一个运行在 Kubernetes 上的云中立工具，用于在 Kubernetes 之外提供云资源。(我知道……这会让你很困惑！)因为它是原生支持 Kubernetes 的，所以是声明式的，并且使用 YAML 来描述正在配置的基础设施。Crossplane 还很新，因此，虽然它支持许多 AWS 资源[25]，但对其他云服务商(如 Azure[26]和 GCP[27])的支持相对较少。我写了一篇文章[28]记录了用 Crossplane 配置 GCP 集群的探索。
云服务商的命令行工具（Cloud Provider CLIs）
值得一提的是，云服务商的命令行工具是另一种配置基础设施的流行方式。当我说“云服务商的命令行”时，我指的是像 Azure 的 az[29]命令行和谷歌云平台的 gcloud[30]命令行。其他云服务商也有类似的命令行工具。这些命令行工具有一个共同点：它们提供了一种与云服务商 API 交互的方式，从而可以创建和管理资源。如果采用这种方式，我们需要编写包装器代码或者脚本来进行不同的命令行调用，从而实现基础设施的配置。
哪个工具最好？
图片来源：wearearmadillo.com
上面列出的所有工具中，我认为只有两个真正将基础设施视为数据，并且提供了云基础设施的最佳实践：Ansible 和 Crossplane。
为什么？
Terraform(声明式)和 Pulumi(基于代码)都使用状态文件，我意识到我可能是为数不多的被这个问题困扰的人之一。状态文件的存在是为了跟踪 Terraform 创建了哪些资源，从而确保它们不会被不必要的意外重新创建。虽然这是一个勇敢的想法，但我发现这违背了云基础设施的短生命周期原则——我们就应该重新创建它。
同样的，假设我们开始使用 Terraform 创建 3 个云资源。然后添加另一个资源，因为最初的 3 个资源在状态文件中，所以它们会保持原样，只有新资源被添加进去。但是你怎么知道这四种资源是和谐共存的呢？你不知道。除非你删除所有 4 个资源，然后从头开始重新创建它们。
最后，假设我们使用 Terraform 创建了云资源。然后，使用云服务商的管理控制台或 CLI 修改了它。你猜怎么着？Terraform 不知道发生了什么。状态文件不再与资源的实际状态同步。你完了！
作为个人偏好，我很不喜欢 Terraform 的 HCL，我完全读不懂 HCL 的代码。（对不起，Hashi 的粉丝！）此外，我也不喜欢 Terraform 在控制流和循环方面的尝试。对我来说，这让我头晕，我讨厌这样。🤢
作为软件工程师，我对 Pulumi 更感兴趣——我随时有可能用它接管 Terraform。然而，从 SRE 的角度来看，它并不是声明式设计。虽然编程语言很好，但也可能导致自动化过度复杂。记住：有一种东西叫做糟糕的代码，而糟糕的代码会导致技术债。
云服务商 CLI 是无状态的，我喜欢，但它们也不是声明式的。此外，为了使它们更加有效，还需要将它们包装在代码或脚本中。放弃了。
那我们就只剩下 Ansible 和 Crossplane 了。根据定义，Ansible 是声明式和无状态的，并且使用 YAML，这非常容易阅读——甚至比 JSON 更容易阅读。赢了！此外，让我惊讶的是，通过各种云服务商提供的库，Ansible 非常容易创建云基础设施。
Crossplane，作为原生支持 Kubernetes 的工具，也是声明式的，但不是完全无状态的。你看，因为 Crossplane 运行在 Kubernetes 上，利用了 etcd[31]（Kubernetes 的分布式键值存储），每当我们更改 Crossplan 基础架构定义时，都会被记录在 etcd 中，这让你觉得它的行为就像 Terraform/Pulumi 的状态文件一样，只是稍微有点不同。Crossplane 的博客[32]上说：“无论变更是否在预期内，它都会不断观察和纠正组织的基础设施，使其符合预期的配置。”我真的太喜欢这一点了！
结论
该死，太让人难以接受了！我们回顾一下前面的内容：
- 云上创建的资源(无论是公共的还是私有的)并不是凭空创建的，而是从现有的(有限的)物理资源中分配出来的虚拟资源。
- 基于云的基础设施应该是短暂的、简单的和版本控制的。
- 最好将基础设施视为数据，而不是代码。
- 基础设施即数据(IaD)不是一个新概念——它至少可以追溯到 2013 年!
- 大多数云配置工具都不适合 IaD，只有 Ansible 和 Crossplane 符合要求。
最后奖励你一幅老鼠 Susie 的照片。
a老鼠 Susie 喜欢拥抱，基础设施就是数据！图片由 Dzero 实验室提供。
Peace, love, and code.
相关文章：
Using Ansible's GCP Library to Provision a Kubernetes Cluster in Google Cloud: https://medium.com/dzerolabs/using-ansibles-gcp-library-to-provision-a-kubernetes-cluster-in-google-cloud-6fd1910f1700
Using Crossplane to Provision a Kubernetes Cluster in Google Cloud: https://medium.com/dzerolabs/using-crossplane-to-provision-a-kubernetes-cluster-in-google-cloud-cf5374d765ee
延伸阅读：
- Breaking Silos Using the Power of Infrastructure as Data in Kubernetes: https://www.redhat.com/en/blog/breaking-silos-using-power-infrastructure-data-kubernetes
- I do declare! Infrastructure automation with Configuration as Data: https://cloud.google.com/blog/products/containers-kubernetes/understanding-configuration-as-data-in-kubernetes
- The Rise of Infrastructure as Data: http://radar.oreilly.com/2013/08/the-rise-of-infrastructure-as-data.html
References:
[1] Shifting from Infrastructure as Code to Infrastructure as Data: https://medium.com/dzerolabs/shifting-from-infrastructure-as-code-to-infrastructure-as-data-bdb1ae1840e3
[2] AWS: https://aws.amazon.com/
[3] GCP: https://cloud.google.com/
[4] Azure: https://azure.microsoft.com/en-ca/
[5] OCI: https://www.oracle.com/ca-en/cloud/
[6] IBM Cloud: https://www.ibm.com/cloud
[7] OpenStack: https://www.openstack.org/
[8] Apache CluodStack: https://cloudstack.apache.org/
[9] Azure Stack: https://azure.microsoft.com/en-ca/overview/azure-stack/
[10] IBM Cloud Private: https://www.ibm.com/blogs/cloud-computing/2017/10/31/what-is-ibm-cloud-private/
[11] Ansible: https://en.wikipedia.org/wiki/Ansible_%28software%29
[12] The Rise of Instrastructure as Data: http://radar.oreilly.com/2013/08/the-rise-of-infrastructure-as-data.html
[13] Just-in-Time Kubernetes: A Beginner’s Guide to Understanding Kubernetes Core Concepts:https://medium.com/dzerolabs/just-in-time-kubernetes-a-beginners-guide-to-kubernetes-core-concepts-19ee7acbafa1
[14] Workflow syntax for GitHub Actions: https://docs.github.com/en/actions/reference/workflow-syntax-for-github-actions
[15] Ansible: https://www.ansible.com/
[16] Hashicorp: https://www.hashicorp.com/
[17] Terraform: https://www.terraform.io/
[18] Hashicorp Configuration Language: https://github.com/hashicorp/hcl
[19] The Terraform State File: An Overview: https://www.infrastructurecode.io/blog/the-terraform-state-file-an-overview
[20] Former Microsoft Midori team members launch Pulumi, an open-source cloud development company: https://www.zdnet.com/article/former-microsoft-midori-team-members-launch-pulumi-an-open-source-cloud-development-company/
[21] Pulumi: https://www.pulumi.com/
[22] Terraform CDK: https://github.com/hashicorp/terraform-cdk
[23] Cloud Support with Ansible: https://www.ansible.com/integrations/cloud
[24] Crossplane: https://crossplane.io/
[25] crossplane/provider-aws: https://doc.crds.dev/github.com/crossplane/provider-aws
[26] crossplane/provider-azure: https://doc.crds.dev/github.com/crossplane/provider-azure
[27] crossplane/provider-gcp: https://doc.crds.dev/github.com/crossplane/provider-gcp
[28] Using Crossplane to provision a Kubernetes cluster in Google Cloud: https://medium.com/dzerolabs/using-crossplane-to-provision-a-kubernetes-cluster-in-google-cloud-cf5374d765ee
[29] Azure Command-Line Interface (CLI) documentation: https://docs.microsoft.com/en-us/cli/azure/
[30] gcloud tool overview: https://cloud.google.com/sdk/gcloud
[31] About etcd: The data backbone of Kubernetes: https://medium.com/pradpoddar/about-etcd-the-data-backbone-of-kubernetes-e86ea1d4feeb
[32] Crossplane vs Terraform: https://blog.crossplane.io/crossplane-vs-terraform/
