👉 Terraform 系列文章
聊到 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 流程/理念相契合。
三人行, 必有我师; 知识共享, 天下为公. 本文由东风微鸣技术博客 EWhisper.cn 编写.