聊到 Terraform, 必然绕不开 IaC 这个概念？那么，什么是 IaC? 🤔
基础架构即代码 (Infrastructure as Code, IaC) 是指通过代码而不是手动流程/控制台点击来管理和配置基础架构。
这里有 2 个关键词：
Infrastructure 是被管理对象，在这里，主要是指公有云（还有私有云、混合云等）.
Code 是管理方式，即像管理代码一样管理公有云资源。那么管理代码最重要的部分： 版本管理是绕不开的。
使用 IaC，创建的配置文件包含了基础设施的 spec，这使得编辑和分发配置变得更加容易。IaC 还确保每次都提供相同的环境、相同的资源、相同的配置。通过编辑和记录配置的 spec，IaC 有助于避免未记录的、临时的配置更改（当然，前提是所有人都使用 IaC，而不是还会有人在控制台点击修改导致配置漂移）。
版本控制是 IaC 的重要组成部分，配置文件应该像任何其他软件源代码文件一样受到源代码控制。
另外，随着公有云的发展，公有云的标准化的 API 也使得将基础架构组件模块化 (Terraform 里叫做 modules) 成为可能，使用者可以像搭积木一样组合这些基础的组件。比如：在 AWS 上建个静态博客，就可以组合以下组件：
有两种实现 IaC 的方法：声明式和命令式。
声明式方法定义了系统的理想状态，包括需要的资源以及它们应该具有的任何属性，IaC 工具将自动配置它。
Terraform 就是基于 IaC 声明式的理念。在 Terraform 流行之前，另一个将声明式发扬光大的当然是：Kubernetes!
声明式方法还保留系统对象当前状态的列表，这使得拆除基础架构更易于管理。
相反，命令式方法定义了实现所需配置所需的特定命令，然后需要以正确的顺序执行这些命令。
典型的就是 Ansible.
IaC 工具通常能够在两种方法中运行，但往往更喜欢一种方法而不是另一种方法。
如 Terraform, 它更喜欢声明式的方法，但是它的 Provider、Modules、函数中仍然残留不少命令式的方法， 如：local-exec
IaC（特别是声明式的）是随着公有云而发展起来的。
置备基础设施历来是一个耗时且成本高昂的手动过程。现在基础设施管理已经从数据中心的物理硬件、虚拟化转移到容器和云计算。
借助云计算，基础设施组件的数量不断增加，每天都有更多的应用程序发布到生产环境中，并且基础设施需要能够频繁地启动、扩展和关闭。如果没有适当的 IaC 实践，管理当今基础设施的规模会变得越来越困难。
IaC 可以帮助您的组织管理 IT 基础设施需求，同时提高一致性并减少错误和手动配置。
这， 就是 IaC 的必要性。
毋庸置疑的，Terraform 是 IaC 领域事实上的领导者。
所有主流公有云，私有云，虚拟化，K8s, 容器都有在维护对应的 Terraform Provider 和 Modules.
IaC 工具有哪些？目前主流的有：
声明式：
命令式：
我觉得主要有以下原因：
IaC 是实施 DevOps 实践和 CI/CD 的重要组成部分。DevOps 和 CI/CD 主要是应用和组件层面的， 而 IaC 消除了开发人员的大部分配置工作，开发人员可以执行脚本让他们的基础设施准备就绪。
这样一来，应用程序部署就不会因等待基础架构而停止，系统管理员也不需要管理耗时的手动流程。那么整个开发部署迭代的流程就会越来越快， 越来越快。..
IaC 帮助您协调开发和运维，因为两个团队可以在代码仓库中看到基础架构全貌。
而且每个环境都可以使用相同的部署过程。环境一致性也有保障，开发上测试通过的，生产上出问题的概率也小。
DevOps 最佳实践也适用于 IaC 中的基础架构。基础设施可以通过与应用程序在软件开发期间相同的 CI/CD 管道，对基础设施代码应用相同的测试和版本控制。将 IaC 的 modules 代码也引入 DevOps 理念，快速测试，快速迭代。
IaC 是什么？基础架构即代码 (Infrastructure as Code, IaC) 是指通过代码而不是手动流程/控制台点击来管理和配置基础架构。
IaC 有声明式和命令式两种实现方式，现在更主流的是声明式的。
为什么需要 IaC? 随着云计算带来的大量基础设施，IaC 已成必备工具。
IaC 也可以和 DevOps 流程/理念相契合。
本文为系列文章-Grafana GaC(Grafana 即代码） 的第二篇 - Grafana Terraform Provider 基础。