澄清Terraform之外的更改

Question

我不完全了解Terraform如何处理外部变化。让我们举一个例子：

resource "aws_instance" "ec2-test" {
  ami           = "ami-0d71ea30463e0ff8d"
  instance_type = "t2.micro"
}

1：安全组修改

默认安全组已由另一个人手动替换。 Terraform检测更改：

❯ terraform plan --refresh-only
aws_instance.ec2-test: Refreshing state... [id=i-5297abcc6001ce9a8]

Note: Objects have changed outside of Terraform

Terraform detected the following changes made outside of Terraform since the last "terraform apply" which may have affected this plan:

  # aws_instance.ec2-test has changed
  ~ resource "aws_instance" "ec2-test" {
        id                                   = "i-5297abcc6001ce9a8"
      ~ security_groups                      = [
          - "default",
          + "test",
        ]
        tags                                 = {}
      ~ vpc_security_group_ids               = [
          + "sg-8231be9a95a4b1886",
          - "sg-f2fc3af19c4adefe0",
        ]
        # (28 unchanged attributes hidden)

        # (7 unchanged blocks hidden)
    }

无需更改：

❯ terraform plan
aws_instance.ec2-test: Refreshing state... [id=i-5297abcc6001ce9a8]

No changes. Your infrastructure matches the configuration.

Terraform has compared your real infrastructure against your configuration and found no differences, so no changes are needed.

似乎正常，因为我们没有在resource> resource> resource> block中设置security_groups参数（所需状态与当前状态对齐）。

2：IAM实例配置文件添加了

IAM角色，已手动连接到实例上。 Terraform还检测到了变化：

❯ terraform plan --refresh-only
aws_instance.ec2-test: Refreshing state... [id=i-5297abcc6001ce9a8]

Note: Objects have changed outside of Terraform

Terraform detected the following changes made outside of Terraform since the last "terraform apply" which may have affected this plan:

  # aws_instance.ec2-test has changed
  ~ resource "aws_instance" "ec2-test" {
      + iam_instance_profile                 = "test"
        id                                   = "i-5297abcc6001ce9a8"
        tags                                 = {}
        # (30 unchanged attributes hidden)

        # (7 unchanged blocks hidden)
    }


This is a refresh-only plan, so Terraform will not take any actions to undo these. If you were expecting these changes then you can apply this plan to record the updated values in the Terraform state without
changing any remote objects.

但是，Terraform还计划恢复变化：

❯ terraform plan
aws_instance.ec2-test: Refreshing state... [id=i-5297abcc6001ce9a8]

Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols:
  ~ update in-place

Terraform will perform the following actions:

  # aws_instance.ec2-test will be updated in-place
  ~ resource "aws_instance" "ec2-test" {
      - iam_instance_profile                 = "test" -> null
        id                                   = "i-5297abcc6001ce9a8"
        tags                                 = {}
        # (30 unchanged attributes hidden)

        # (7 unchanged blocks hidden)
    }

Plan: 0 to add, 1 to change, 0 to destroy.

我试图弄清楚为什么这两个变化不会产生相同的效果。本文重点介绍了差异，具体取决于参数默认值： https://nedinthecloud.com/2021/12/23/terraform-apply-papply-when-when-external-change-happens/

但是security> security_groups 和iam_instance_profile 参数似乎相似（没有默认值的可选），那么为什么Terraform以不同的方式处理这两种情况？

（用Terraform v1.2.2，Hashicorp/AWS 4.21.0测试）

Answer 1

不幸的是，对这些情况的处理很大程度上取决于提供者开发人员做出的决策，因为提供商有责任决定如何调和配置与先前状态之间的任何差异。 （“先前的状态”是Terraform所说的状态，该状态是通过运行“刷新”步骤与远程系统同步的）。

Terraform Core采用您在配置中定义的值（如果尚不设置任何可选参数，Terraform Core使用null来表示该值）以及来自先前状态的值并将两个发送给提供者实施计划步骤。然后，只要每个属性的计划新值与输入一致，提供商就可以执行所需的任何逻辑。 “一致”表示以下条件之一是正确的：

1. 计划的值等于配置中设置的值。

   这是遵循的最直接情况，但是有多种原因导致提供商可能不这样做，我将稍后讨论。

2. 计划的值等于存储在先前状态的值。

   这代表了情况，即先前状态的值在功能上等效于配置中的值，但并不完全相等，例如远程系统将特定的字符串视为案例不敏感的，而两个值仅在情况下有所不同。

3. 提供商在其架构中指示这是一个可以由远程系统决定的值，例如远程系统在应用步骤中生成的对象ID，配置中的相应值为> null表示根本不设置参数。

   在这种情况下，提供商可以选择所需的任何值，因为配置对属性没有任何说明，因此远程系统对值是什么。

从您所描述的内容来看，在您的第一个示例中听起来像是提供商使用的方法3，而在第二个示例中，提供商使用的方法编号1。

由于我不是此提供商的开发人员，所以我不能确定为什么开发人员为什么做出了他们在这里做出的决定，但是提供者开发人员可以选择选项的一个常见原因是，对于可能由多种不同的资源类型设置特定价值的情况，在这种情况下，提供商可能被设计为治疗不存在的论点配置为含义“保持远程系统已经拥有的任何内容”，而配置中的非null参数意味着“设置远程系统使用此给定值”。

对于iam_instance_profile，似乎提供商认为null是该参数的有效配置值，并使用它来表示根本没有关联的实例配置文件的EC2实例。对于vpc_security_groups和security_groups，将参数设置为配置中的null “保持远程系统拥有的任何内容”，因此Terraform只是承认更改，但并没有提议撤消它。

根据我对EC2的了解，我可以猜测，这里的原因可能是基础EC2 API有两种不同的方法来设置安全组：您可以使用按名称指定安全组的旧式EC2经典样式（<<代码> security_groups 提供商中的参数）或通过ID指定它的新EC2-VPC样式（vpc_security_group_ids提供者中的论点）。无论您选择的两个中的哪个，远程系统大概会自动填充另一个，因此如果没有提供商中的特殊例外，则任何配置都无法收敛，除非您设置两个security> security_groups 和 vpc_security_group_ids，将它们设置为两个参考相同的安全组。为了避免这种情况，我认为提供商只允许您剩下的两者中的一个自动跟踪远程系统，远程系统具有副作用，提供商无法自动“修复”在Terraform之外进行的更改，除非您将至少设置为其中一个因此，提供商可以看到正确的价值应该是什么。

Terraform通过重置以匹配配置来调和远程系统的变化的能力是“最佳努力”机制，因为在许多情况下，需求与其他要求发生冲突，因此提供者开发人员必须逐案决定。要优先考虑什么。尽管Terraform确实会尽力告诉您Terraform之外的更改并提议在可能的情况下修复它们，但保持Terraform配置和远程系统同步的唯一某种方法是防止任何人在Terraform之外进行更改，例如使用AWS中的IAM政策。