基于插件的架构

Terraform 架构

Terraform 使用 Go 编程语言（Golang） 编写，并以单个二进制文件的形式提供，该文件包含解析和部署 Terraform 配置所需的核心组件。它不包含与各种提供者（providers）和配置器（provisioners）交互所需的代码。这些代码通过插件提供。每个插件作为独立进程运行，并通过 RPC 接口与核心 Terraform 二进制文件通信。

注意：过去许多提供者的代码是直接打包在 Terraform 二进制文件中的。这导致二进制文件体积不断膨胀，每当有提供者需要添加或更新功能时，都必须发布新的 Terraform 版本。HashiCorp 转向插件架构，使 Terraform 二进制文件更轻量，并允许提供者按自己的节奏进行更新。

插件使得 Terraform 二进制文件保持较小体积，减少了潜在攻击面，并简化了核心代码的调试工作。这使得提供者和配置器可以独立开发各自的插件，也清晰地区分了 Terraform 本身的功能与插件扩展的能力。

核心要点

Terraform 通过插件机制实现对提供者和配置器的支持，而不是将它们直接集成到核心二进制文件中。

使用多个提供者的演示

我们可以采用两种不同的方式：

• 在配置中使用多个不同的提供者。
• 使用同一提供者的多个实例。

多个不同的提供者

即使是最简单的配置，也很可能涉及多个不同的提供者。以下是一个示例配置：

1provider "aws" {
2  region = "us-east-1"
3}
4
5resource "random_integer" "rand" {
6  min = 10000
7  max = 99999
8}
9
10resource "aws_s3_bucket" "bucket" {
11  name = "unique-name-${random_integer.rand.result}"
12  ...
13}

在此配置中，我们已使用两个不同的提供者创建了一个 S3 存储桶。random 提供者用于生成一个随机整数作为存储桶名称，而 aws 提供者则用于创建 S3 存储桶资源。使用某个提供者时，可以在 provider 块中显式声明，也可以通过使用该提供者的资源隐式确定。

同一提供者的多个实例

有时我们需要为同一个提供者定义多个实例。例如，aws 提供者是区域相关的。如果要在多个区域创建 AWS 资源，则需要多个 aws 提供者实例。其他类似场景包括 Azure 中使用多个订阅，或 Kubernetes 中配置多个主节点。

所有提供者都支持 alias 元参数，可用于为提供者指定别名以便引用。在创建资源时，可以通过指定提供者实例的别名来选择使用哪一个。以下是示例：

1provider "aws" {
2  region = "us-east-1"
3}
4
5provider "aws" {
6  region = "us-west-2"
7  alias = "west"
8}
9
10resource "aws_ec2_instance" "example-west" {
11  name = "instance2"
12  provider = aws.west
13  ...
14}

由于我们在 resource 块中指定了要使用的提供者，因此 EC2 实例将在 us-west-2 区域创建。提供者别名的通用格式为 <提供者名称>.<别名名称>，如本例中的 aws.west。

那么如果我们向配置中添加如下内容会怎样？

1resource "aws_ec2_instance" "example-east" {
2  name = "instance1"
3  ...
4}

我们没有指定使用哪个提供者实例。Terraform 会查找未定义别名的提供者，并使用该提供者。在本例中，example-east EC2 实例将被创建在 us-east-1 区域。

提供者别名也可用于模块中，其表达式格式如下：

1module "vpc" {
2  source = "terraform-aws-modules/vpc/aws"
3  providers = {
4    aws = aws.west
5  }
6}

这是因为模块内部可能包含多个提供者，因此需要传入一个映射，键为提供者名称，值为完整的别名。实际使用中还有更多细节需要注意。

核心要点

一个配置中可以包含多个不同的提供者，也可以包含同一提供者的多个实例。理解如何使用 alias 参数以及多实例提供者的适用场景非常重要。