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

问题描述

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

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

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

-/+ 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作为提供者有关:
我们如何避免每次破坏/创建资源?

也许是Terraform中的相关标志?

---

相关线程:

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

地形>在安全组上强制使用新资源

---

深入研究 plan 输出中，似乎其中一种资源发生了变化:

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

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

解决方案

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

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

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

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

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

  lifecycle {
    create_before_destroy = true
  }
}

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

如何处理零宕机时间的资源升级可能很棘手，并且很大程度上取决于资源是什么以及如何处理. 官方博客中有关于此的更多信息./p>

---

在您非常特定的用例中，它已更改了security_groups，这在

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

Maybe a relevant flag in Terraform?

---

Related threads:

Terraform > ipv6_address_count: "" => "0" (forces new resource)

terraform > forces new resource on security group

---

Edit:

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 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.

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,
            },

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.

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
  }
}

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.

---

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

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

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.

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屋！