После того, как кластер EKS создан Terraform, следующий план видит изменения подсети в теги

Question

Я собираюсь использовать Terraform для поддержки всей моей инфраструктуры мониторинга в AWS. До сих пор в моем проекте terraform были созданы VPC, подсети, соответствующие группы безопасности. Я использую реестр Terraform, где это возможно:

• VPC
• безопасность-группа
• IAM-роль
• ЭКС

Проблема, которую я вижу, заключается в том, что после развертывания кластера EKS он вводит теги в VPC и подсети, которые, как представляется, не известны Terraform. Поэтому при следующем запуске terraform plan он идентифицирует теги, которыми он не управляет, и намеревается удалить их:

------------------------------------------------------------------------

An execution plan has been generated and is shown below.
Resource actions are indicated with the following symbols:
  ~ update in-place

Terraform will perform the following actions:

  ~ module.vpc.aws_subnet.private[0]
      tags.%:                                "4" => "3"
      tags.kubernetes.io/cluster/monitoring: "shared" => ""

  ~ module.vpc.aws_subnet.private[1]
      tags.%:                                "4" => "3"
      tags.kubernetes.io/cluster/monitoring: "shared" => ""

  ~ module.vpc.aws_vpc.this
      tags.%:                                "4" => "3"
      tags.kubernetes.io/cluster/monitoring: "shared" => ""


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

------------------------------------------------------------------------

Открыта проблема с terraform-provider-aws с локальным обходным путем с использованием bash , но кто-нибудь знает, как заставить Terraform узнать об этих тегах или получить их следует игнорировать последующими планами надежным способом?

Answer 1

Просто добавьте теги при вызове модуля, обратите внимание, что в примере https://registry.terraform.io/modules/terraform-aws-modules/vpc/aws/1.41.0 там показаны теги, а в документации написано «Карта тегов для добавления ко всем ресурсам», чтобы вы могли добавить ее к этой карте.

Answer 2

Если вы управляете модулем, вы можете попробовать использовать предложение ignore_changes в блоке lifecycle. Что-то вроде

    lifecycle {
      ignore_changes = [
        "tags"
    ]
}

Будет гораздо сложнее с модулем, который вы не контролируете.