SRE文档1. Terraform
1.1 介绍
Terraform 是一种基础设施即代码（IaC）工具，用于创建、更改和管理云基础设施资源。 它允许开发人员使用代码来预置和支持托管基础设施，解决了手动预置基础设施组件的困难和耗时问题。其使用一种名为 HashiCorp 配置语言（HCL）的特定领域语言来编写声明式配置文件。它还提供了自动化基础设施变更管理的机制，支持多云部署，并拥有活跃的开发人员社区。 与Kubernetes相比，Terraform的抽象级别更高，管理云环境中的资源及其配置，而Kubernetes专注于集群中容器的部署和生命周期。
1.2 什么是Terraform✅
Terraform 是一个安全、高效地部署、更改、版本化基础设施和应用程序的工具，可以用来管理多层次的资源。从上层的软件配置到底层的网络、系统配置都可以使用 Terraform 统一进行管理。
Terraform是一款可以帮助我们高效地构建，更改和版本控制的自动化运维工具。
解决了那些痛点
- 传统部署太复杂且低效，还有出错的风险；
- 传统部署无法自动化地留存部署的架构；
- 传统部署无法做到多平台适应。
1.3 什么是IaC✅
基础设施即代码（Infrastructure-as-Code，IaC）意味着使用代码来定义和管理基础设施，用户不必在每次开发、测试或部署软件时都配置环境。所有基础设施参数都以称为清单的文件的形式保存。
开发人员对基础设施配置文件进行编码，并将其存储在版本控制中。如果有人编辑了一个文件，拉取请求和代码审查工作流可以检查更改的正确性。因此，与所有代码文件一样，清单易于重用、编辑、复制和共享，它使构建、测试、准备和部署基础设施更快、更一致。
IaC的优势✅
借助自动化流程，IaC 协助企业以多种方式管理其 IT 基础设施需求。以下是部署 IaC 的部分优势：
- 提升架构一致性：IaC 可提高一致性并减少通常会在手动配置过程中发生的错误。其还能够消除手动流程期间可能会发生的配置漂移。IaC 会整理和记录您的配置规格，进而协助您避免出现未记录的临时配置改变。
- 降低运维成本：IaC 可通过编程方式管理虚拟机，这样就不必手动配置硬件及更新。一位操作员使用同一组代码，即可部署并管理一台机器或 1,000 台机器。这样就意味着，需要的员工减少，不必再购买新硬件，成本会因此大幅降低。
- 提升操作效率：基础设施编码化可为您提供配置模板，进而简化系统配置、维护和管理。其可以打造出可重复、可扩展的弹性基础设施。这也意味着，DevOps 能够加速软件开发的各个环节，每天能发布的应用也将更多。
- 加快部署速度：IaC 能将开发人员耗时冗长的配置工作转变为简单的脚本执行，通过脚本执行就能让其基础设施准备就绪。因此，部署应用不再需要等待基础设施，新软件的发布也大大提速。
- 降低操作风险：IaC 也支持版本控制，因此，配置文件也会和其他任何软件源代码文件，归入源代码控制。如此，风险就会降低。
IaC 工具✅
服务器自动化和配置管理工具通常可以用来实现IaC。当然，也有一些专门针对IaC的解决方案。一些常见的方案如下：
- Chef
- Puppet
- Ansible
- Saltstack
- Terraform
- AWS CloudFormation
- Aliyun ROS资源编排
- Tencent TIC资源编排
1.4 IaC的两种方式✅
采用基础设施即代码的方法有两种，一种是声明式的方式，一种是命令式的方式，不同的方式都可以实现IaC。尽管两种方法都能让大多数 IaC 工具正常运行，使用哪一种取决于手上的任务。
声明式✅
声明式方法也称为功能性方法，明确定义了系统的理想状态，但未明确指出达到该状态的方法。这种方法可让您明确名义想要的资源，包括必需的属性。IaC 软件会自动配置理想的基础设施，声明式 IaC 工具将会自动应用作出的任何改变。声明式 IaC 可多次执行且结果相同，无需人为干预。
如：AWS CloudFormation、Terraform、Puppet。
命令（编程）式✅
相比之下，命令式方法可让您明确定义配置基础设施的方式，以及实现的方法。命令式方法也叫作过程式方法，明确定义了实现特定配置所需的命令。之后需要按照正确的顺序执行这些命令，一次一个步骤。这个方法较脆弱，依靠的是明确的指示，不接受任何更新。需要改变时，命令式 IaC 工具将会要求操作员解读应如何应用这些改变。
如：Chef、Ansible。
不同IaC对比✅
| 工具 | 类型 | 语言/DSL | 主要用途 | 状态管理 | 学习曲线 | 云平台支持 | 特点与优势 |
|---|---|---|---|---|---|---|---|
| Terraform | 声明式 | HCL (HashiCorp) | 云资源部署（多云、基础设施） | 本地或远端 | 中等 | ☁️ AWS, Azure, GCP 等 | ✅ 多云支持，社区庞大，模块丰富 |
| Ansible | 命令式（可声明） | YAML | 配置管理，轻量级部署 | 无（幂等执行） | 低 | ☁️ AWS, 本地，混合云 | ✅ Agentless，SSH 即可用 |
| Chef | 命令式 | Ruby DSL | 配置管理（企业环境） | 有 | 高 | ☁️ AWS, 本地 | 🔒 安全强，复杂度高 |
| SaltStack | 命令式 | YAML + Jinja2 | 大规模服务器管理 | 有 | 高 | ☁️ 云+物理混合环境 | ⚡ 快速远程命令执行，适合运维大户 |
| Helm | 声明式 | YAML + 模板 | Kubernetes 应用包部署 | N/A（K8s） | 低 | ☁️ K8s 环境 | K8s 包管理，类 apt/yum |
1.5 Terraform工作原理与逻辑✅
Terraform原理
Terraform 通过其应用程序编程接口（API）在云平台和其他服务上创建和管理资源。提供程序使 Terraform 能够与任何具有可访问 API 的平台或服务协同工作。
- Terraform通过Provider这个与API直接交互的后端驱动来完成对云平台上基础设施资源的管理。
- 不同的基础设施提供商需要对应的Provider来实现对自家基础设施的统一管理。
- HashiCorp官方和Terraform社区已经编写了大量的Provider来管理数千种不同类型的资源和服务。
- https://registry.terraform.io/browse/providers
你可以在 Terraform Registry 上找到所有公开可用的提供者，包括 Amazon Web Services (AWS)、Azure、Google Cloud Platform (GCP)、Kubernetes、Helm、GitHub、Splunk、DataDog 等。
在实际操作中，Terraform和Provider是两个独立存在的package。 Terraform会在运行时根据用户模板中指定的provider或者resource、datasource的标志自动下载配置所用到的所有provider，并将其放在执行目录下的一个隐藏目录
.terraform下。
Terraform 的核心工作流程
由三个阶段组成：
- Write
编写：你定义资源，这些资源可能跨越多个云提供商和服务。例如，你可能创建一个配置来在虚拟私有云（VPC）网络中的虚拟机上部署应用程序，并配置安全组和负载均衡器。
- Plan
计划：Terraform 创建一个执行计划，描述它将创建、更新或销毁的基础设施，该计划基于现有基础设施和你的配置。
- Apply
应用：在批准后，Terraform 会按照正确的顺序执行提议的操作，并尊重任何资源依赖关系。例如，如果你更新了 VPC 的属性并更改了该 VPC 中的虚拟机数量，Terraform 会先重新创建 VPC，然后再扩展虚拟机。
参考：https://developer.hashicorp.com/terraform/intro
1.6 Terraform 生命周期✅
Terraform 的生命周期由init、plan、apply和 destroy，4个阶段构成。
- Terraform init 初始化工作目录，其中包括所有的配置文件。
- Terraform plan 被用来创建执行计划以达到基础设施的期望状态。为了达到预期状态，会对配置文件进行更改。
- Terraform apply 会对在 plan 阶段中定义的基础设施进行更改，从而使基础设施达到期望状态。
- Terraform destroy 这一阶段用于删除所有的旧基础设施资源，这些资源在apply 阶段后被标记为污损（taint）
1.7 Terraform 核心概念✅
Terraform 中使用的核心概念/术语：
- Variables：也被称为 input-variables（输入变量），它是 Terraform 模块使用的键值对，可以自定义。
- Provider：一种插件类型，与 API 服务进行交互并访问相关资源。
- Module：它是一个包含 Terraform 模板的文件夹，所有的配置都可以在这里定义。
- State：它由 Terraform 管理的基础设施和相关配置的缓存信息组成。
- Resources：它指一个或多个基础设施对象（计算实例、虚拟网络等）的块（block），这些对象用于配置和管理基础设施。
- Data Source：它是由 provider 实现的，以返回外部对象的信息到 Terraform。
- Output Values：这是 Terraform 模块的返回值，可以被其他配置使用。
- Plan：这是指其中一个阶段，在这一阶段中会决定需要创建、更新或销毁什么，以便从基础设施的 real/current 状态转移到期望状态。
- Apply：这一阶段会应用基础设施的更改 real/current 状态，以推动到期望状态。
1.9 IaC 对于 DevOps 至关重要？✅
- IaC 是实施 DevOps 实践和持续集成/持续交付（CI/CD）的一个重要组成部分。IaC 免除了开发人员的大部分置备工作，他们只需要执行一个脚本即可让基础架构准备就绪。
- 如此一来，应用部署就不必再等待基础架构，而系统管理员也不用管理耗时的手动流程。
- CI/CD 离不开贯穿应用整个生命周期（从集成和测试阶段，到交付和部署）的持续自动化和持续监控。
- 环境要实现自动化，需要保持一致。如果开发团队以一种方式部署应用或配置环境，而运维团队以另一种方式部署和配置，则实现应用部署的自动化并不能发挥作用。
- 通过 DevOps 方法来协调开发和运维团队，可以减少错误、手动部署及不一致的情况。
- IaC 会帮助您协调开发和运维工作，因为这两个团队可以使用有关应用部署的同一描述，以支持 DevOps 方法。
- 每种环境（包括生产环境）都应使用相同的部署过程。每次使用 IaC 时，它都会生成相同的环境。
- 此外，您也无需分别维护具有独特配置（无法自动复制）的不同部署环境，从而确保了生产环境的一致性。
- DevOps 最佳实践也同样适用于 IaC 中的基础架构。在软件开发期间，基础架构可采用与应用相同的 CI/CD 管道，因此可以对基础架构代码应用相同的测试和版本控制。
参考文档：
https://developer.hashicorp.com/terraform/tutorials
https://developer.hashicorp.com/terraform/language/providers
https://github.com/warrenlucky/terraform-course/tree/master
https://devopscube.com/setup-prometheus-using-docker/
https://wsgzao.github.io/post/terraform/
开发公司：HashiCorp
入门手册：https://www.terraform.io/intro/index.html
Github：https://github.com/hashicorp/terraform
https://wsgzao.github.io/post/terraform/
https://developer.hashicorp.com/terraform/tutorials/aws-get-started/infrastructure-as-code
git clone https://github.com/techiescamp/devops-projectsgit clone https://github.com/techiescamp/devops-projects