AWS on Terraform - 如何避免“强制使用新资源" [英] AWS on Terraform - How to avoid 'forces new resource'

问题描述

我正在使用 Terraform 启动我的云环境.

I'm using Terraform to launch my cloud environments.

似乎即使是很小的配置更改也会影响幕后的许多资源.

It seems that even minor configuration change affects many of the resources behind the scenes.

例如，在我创建 AWS 实例的情况下 - 一个小的更改将导致所有实例的自动生成:

For example, In cases where I create AWS instances - a small change will lead to auto-generation of all the instances:

-/+ aws_instance.DC (new resource required)
      id:   "i-075deb0aaa57c2d" => <computed> (forces new resource) <----- How can we avoid that?
      ami:  "ami-01e306baaaa0a6f65" => "ami-01e306baaaa0a6f65"
      arn:  "arn:aws:ec2:ap-southeast-2:857671114786:instance/i-075deb0aaa57c2d" => <computed>
      associate_public_ip_address: "false" => <computed>
      availability_zone: "ap-southeast-2a" => <computed>
      .
      .

我的问题与作为提供商的 AWS 相关:
我们如何避免每次都破坏/创建资源?

My question is related specifically to AWS as the provider:
How can we avoid the destruction/creation of resources each time?

可能是 Terraform 中的相关标志?

Maybe a relevant flag in Terraform?

相关话题:

Terraform >ipv6_address_count:"=>0"(强制新资源)

terraform >强制安全组上的新资源

在 plan 输出中潜水，似乎其中一个资源发生了变化:

Diving inside the plan output it seems that there was a change in one of the resources:

  security_groups.#: "0" => "1" (forces new resource)
  security_groups.837544107: "" => "sg-0892062659392afa9" (forces new resource)

从如何避免重新创造的角度来看，问题仍然是相关的.

Question is still relevant from the perspective of how to avoid the re-creation.

推荐答案

Terraform 资源只有在修改资源以匹配新配置时没有明确的升级路径时才会强制使用新资源.这是通过在参数上设置 ForceNew: true 标志在提供者级别完成的.

Terraform resources only force a new resource if there's no clear upgrade path when modifying a resource to match the new configuration. This is done at the provider level by setting the ForceNew: true flag on the parameter.

一个示例显示在 ami 参数:

An example is shown with the ami parameter on the aws_instance resource:

        Schema: map[string]*schema.Schema{
            "ami": {
                Type:     schema.TypeString,
                Required: true,
                ForceNew: true,
            },

这告诉 Terraform 如果更改了 ami 参数，那么它不应尝试执行更新，而是销毁资源并创建一个新资源.

This tells Terraform that if the ami parameter is changed then it shouldn't attempt to perform an update but instead destroy the resource and create a new one.

您可以使用 create_before_destroy生命周期配置块:

You can override the destroy then create behaviour with the create_before_destroy lifecycle configuration block:

resource "aws_instance" "example" {
  # ...

  lifecycle {
    create_before_destroy = true
  }
}

如果您更改了 ami 或其他无法更新的参数，Terraform 将创建一个新实例，然后销毁旧实例.

In the event you changed the ami or some other parameter that can't be updated then Terraform would then create a new instance and then destroy the old one.

如何处理资源的零停机升级可能很棘手，并且很大程度上取决于资源是什么以及您如何处理它.官方博客中提供了更多相关信息.

How you handle zero downtime upgrades of resources can be tricky and is largely determined on what the resource is and how you handle it. There's some more information about that in the official blog.

在您非常具体的用例中，security_groups 改变了这一点，在 aws_instance 资源文档:

In your very specific use case with it being the security_groups that has changed this is mentioned on the aws_instance resource docs:

注意:如果您在 VPC 中创建实例，请改用 vpc_security_group_ids.

NOTE: If you are creating Instances in a VPC, use vpc_security_group_ids instead.

这是因为 Terraform 的 AWS 提供商和 Terraform 使用的 EC2 API 向后兼容早于 VPC 的旧 EC2 Classic AWS 账户.使用这些帐户，您可以在 VPC 之外创建实例，但在创建实例后您无法更改该实例的安全组.如果您想更改实例的入口/出口，您需要在您已经附加到实例的组中工作.对于基于 VPC 的实例，AWS 允许用户在不替换实例的情况下修改实例安全组，因此在 API 中提供了一种不同的指定方式.

This is because Terraform's AWS provider and the EC2 API that Terraform is using is backwards compatible with old EC2 Classic AWS accounts that predate VPCs. With those accounts you could create instances outside of VPCs but you couldn't change the security groups of the instance after it was created. If you wanted to change ingress/egress for the instance you needed to work within the group(s) you had attached to the instance already. With VPC based instances AWS allowed users to modify instance security groups without replacing the instance and so exposed a different way of specifying this in the API.

如果您转而使用 vpc_security_group_ids 而不是 security_groups，那么您将能够在不替换实例的情况下修改这些内容.

If you move to using vpc_security_group_ids instead of security_groups then you will be able to modify these without replacing your instances.

这篇关于AWS on Terraform - 如何避免“强制使用新资源"的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！