Terraform-provider-aws: aws_alb_target_group kann mit angehängten Listenern nicht neu erstellt werden

Ich stoße auch mit 0.9.8 darauf

@radeksimko Das ist auch ein kniffliges Thema. Würden Sie uns bitte helfen, es zu lösen? Was ist der richtige Weg, um es zu lösen?

Es gibt zwei Möglichkeiten, um zu verhindern, dass "Ressource in Gebrauch" zerstört wird, soweit ich weiß.

1. Standardaktion eines aws_alb_listener
2. Teil von aws_alb_listener_rule

Ich erwäge, einen Parameter wie "force_destroy" hinzuzufügen. Wenn Sie es aktivieren, müssen Sie alle Load Balancer als Listener und dann als Regeln durchlaufen. Falls eine Beziehung zu einer Regel besteht, wird auch die Regel gelöscht. Dies wird das zweite Problem lösen. Beim ersten bin ich mir nicht sicher, aber ein nächster Kandidat target kann als Standard festgelegt werden. Das hört sich gar nicht so schlecht an.

Was denkst du @radeksimko?

Übrigens war dieses Problem eines der Hauptprobleme in den vorherigen Trackern. :)

Dasselbe in 0.9.11

Ich fügte hinzu

  lifecycle {
    create_before_destroy = true
  }

zum Hörer und zur Zielgruppe und konnte eine Neubewerbung mit Änderungen erfolgreich durchführen. Ich bin mir nicht sicher, welcher den Trick gemacht hat.

@spanktar Es scheint nicht zu funktionieren, wenn sich Ihr Zielgruppenname nicht ändert, da Zielgruppennamen eindeutig sein müssen. Können Sie das bestätigen oder verneinen?

Die Lösung von @spanktar funktioniert nicht, wenn sich der Zielgruppenname nicht ändert.

@varjoinen Sie müssen name_prefix mit create_before_destroy verwenden.

@hoffmannliu-ayla das wäre schön wenn das behoben wäre https://github.com/terraform-providers/terraform-provider-aws/issues/1301

Sie können ein random_id|pet an die Zielgruppen-Ressourcen-ID mit einem create_before_destroy in der Lebenszyklusrichtlinie anhängen und Verwalter für die zufällige ID für die Dinge verwenden, die am Ende versuchen würden, die Ressource als zu durchlaufen Problemumgehung.

@GrantSheehan das hat funktioniert, danke. Schrecklich, aber es erledigt die Arbeit.

Für meinen Anwendungsfall habe ich Ihre Idee leicht geändert:

resource "random_string" "target_group" {
  length = 8
  special = false
}


resource "aws_lb_target_group" "preview" {
  # Target group names conflict on update, hence the random 
  name     = "my-name-${random_string.target_group.result}"
  ...

  lifecycle {
    create_before_destroy = true
    ignore_changes = ["name"]
  }
}

ohne Bewahrer, um bei jeder Änderung automatisch zu aktualisieren.

@hraban Terraform gefällt es mir nicht
Fehler ist
aws_alb_target_group.blabla-tg: aws_alb_target_group.blabla-tg: Unterschiede stimmten während der Anwendung nicht überein. Dies ist ein Fehler in Terraform und sollte als GitHub-Problem gemeldet werden

ok, halten Sie uns über Ihren Fortschritt bei der Fehlerberichterstattung auf dem Laufenden!

Die Lösung von @hraban funktioniert bei mir in 11.1.0 nicht

*(Ich nehme an, ich könnte die widersprüchlichen Regeln/Anhänge manuell entfernen, bevor ich mich erneut beantrage – das ist nicht ideal)

-- wenn ich mein Gesicht auf den Schreibtisch schlage, hört der Schmerz auf --

Die Kombination aus dem Verschieben von name nach tags und dem Aktivieren create_before_destroy behebt das Problem.

resource "aws_alb_target_group" "test" {
  lifecycle {
    create_before_destroy = true
  }

  port     = "8081"
  protocol = "HTTP"
  vpc_id   = "${var.vpc_id}"


  tags {
    Name = "test"
  }
}

Ich verwende https://www.terraform.io/docs/providers/random/r/id.html , um das Problem ebenfalls zu umgehen.

Wie wir herausgefunden haben, besteht das Problem wirklich darin, dass wir die Ressource nicht entfernen können, bevor eine neue Zielgruppe erstellt wird. Wir umgehen das mit dem Attribut lifecycle , indem wir create_before_destroy auf true setzen.
Wenn der Ressourcenname statisch ist, stoßen wir leider auf das Problem, dass wir eine Namenskollision haben. Dies ist nur ein Problem, wenn ein Attribut geändert wird, das eine neue Zielgruppenanlage erzwingt. Die Attribute, die dieses Verhalten erzwingen, sind in https://github.com/terraform-providers/terraform-provider-aws/blob/master/aws/resource_aws_lb_target_group.go#L48 gut definiert

Eine Lösung für das Problem kann implementiert, in einem Modul abstrahiert oder inline gelöst werden. Ich werde meine Lösung posten, wie wir das inline behoben haben.

locals {
  LB-name = "${terraform.workspace}-LB"
  LB-protocol = "HTTP"
  LB-vpc-id = "${var.vpc-id}"
  LB-target-type = "ip"
}

resource "random_id" "LB" {
  keepers {
    name = "${local.LB-name}"
    protocol = "${local.LB-protocol}"
    vpc_id ="${local.LB-vpc-id}"
    target_type = "${local.LB-target-type}"
  }
  byte_length = 4
}

resource "aws_lb_target_group" "LB" {
  name = "${local.LB-name}-${random_id.LB.hex}"
  port = 9292
  protocol = "${local.LB-protocol}"
  vpc_id ="${local.LB-vpc-id}"
  target_type = "${local.LB-target-type}"

  lifecycle {
    create_before_destroy = true
  }
}

In meinem Fall sind name , protocol , vpc_id und target_type möglicherweise sich ändernde Attribute, die bei Änderung die Erstellung einer neuen Zielgruppe erzwingen. Ich habe sie in lokale Variablen extrahiert und als Bewahrer an die Ressource random_id übergeben - das heißt im Grunde zwischen den Zeilen "Wenn sich keines der Attribute in der Bewahrerkarte ändert, bleibt die Ausgabe der Ressource random_id statisch". Ich habe absichtlich port nicht zur Keepers Map (und lokalen Variablen) hinzugefügt, da dies nicht die Erstellung einer neuen Zielgruppe erzwingt, sondern an Ort und Stelle aktualisiert werden kann.

Beachten Sie, dass ich random_id.LB.hex innerhalb des Namens target_groups verwende, sodass sich der Name der Zielgruppe ändert, wenn sich ein Keepers-Attribut ändert, wodurch wir das Problem kollidierender Namen umgehen können.

Das heißt, dies ist eine generische High-Level-Lösung für das Problem, und vielleicht wäre es besser, wenn es innerhalb des Providers oder Kerns behoben werden könnte. Die Lösung lässt sich sicher auch in ein Modul abstrahieren.

Ich habe dieses Problem kürzlich erlebt.

Ich habe meine Listener in meiner AWS-Konsole gelöscht. und dann lief ein terrafrom plan/apply und es hat geklappt.

Die Verwendung ${substr(uuid(),0, 3)} hat bei mir funktioniert

resource "aws_lb_target_group" "preview" {
  # Target group names conflict on update, hence the random 
  name     = "my-name-${${substr(uuid(),0, 3)}}"
  ...

  lifecycle {
    create_before_destroy = true
    ignore_changes = ["name"]
  }
}

Sehen Sie nicht wirklich einen Sinn darin, eine zufällige Zeichenfolge von 3 Zeichen zu schneiden, Kollisionen sind bei dieser Granularität so eine Möglichkeit.

immer noch ein Problem am 0.11.13

Und immer noch ein Problem bei 0.12.3

Ich habe die uuid-Lösung ausprobiert, aber ich muss sie nicht ändern, wenn sich andere Dinge nicht geändert haben und ich nicht herausfinden kann, wie.

Ich habe bisher einen anständigen Erfolg mit random_integer gefunden, ähnlich wie bei der obigen Problemumgehung. Ich achte darauf, die Werte durch die Halter zu ziehen.

resource "random_integer" "web_target_group_id" {
  min = 1
  max = 999

  keepers = {
    port        = "${local.web_port}"
    protocol    = "HTTP"
    vpc_id      = "${var.vpc_id}"
  }
}

resource "aws_lb_target_group" "web" {
  name                 = "foo-web-${random_integer.web_target_group_id.result}"
  port                 = "${random_integer.web_target_group_id.keepers.port}"
  protocol             = "${random_integer.web_target_group_id.keepers.protocol}"
  vpc_id               = "${random_integer.web_target_group_id.keepers.vpc_id}"

  lifecycle {
    create_before_destroy = true
  }

  # ...etc
}

Sehen Sie dies in v0.12.4

Sehen Sie dies in v0.12.8

Sehen Sie dies in v0.12.9

Sehen Sie dies in v0.12.10

Diese Ausgabe ist jetzt drei Jahre alt.

Ich habe dies in Terraform v0.12.24 und provider.aws v2.58.0 erhalten.

gleiches Problem mit v0.12.24:
Fehler: Fehler beim Löschen der Zielgruppe: ResourceInUse: Die Zielgruppe ' arn:aws :elasticload Balancing:XXXXXXXXXXXX ' wird derzeit von einem Listener oder einer Regel verwendet
Statuscode: 400, Anforderungs-ID: XXXXXXXX

Gibt es dafür eine Problemumgehung? Ich komme da auch nicht ran.

Hallo allerseits.

Wie Sie sehen, lässt die AWS-API nicht zu, dass eine Zielgruppe gelöscht wird, wenn ihr eine Listener-Regel zugeordnet ist. Wenn eine Portnummer in der Zielgruppe geändert wird, wird die Zielgruppe neu erstellt. Leider gibt es in Terraform derzeit keine Möglichkeit zu sagen „diese Ressource auch löschen, wenn eine andere Ressource gelöscht wird“, aber wir haben einige Gedanken darüber, wie wir damit umgehen können .

Zusätzlich zum Argument $#$ name aws_alb_target_group unterstützt name_prefix und generiert auch einen zufälligen Namen, wenn keiner von beiden angegeben wird. Wie in https://github.com/terraform-providers/terraform-provider-aws/issues/636#issuecomment -397459646 vorgeschlagen, kann der Name stattdessen in einem Name -Tag festgelegt werden. Aufgrund der Funktionsweise von name_prefix und der Längenbeschränkung für Zielgruppennamen darf das Präfix nur sechs Zeichen lang sein.

Einige der anderen Lösungen, die den Anbieter random verwenden , um den Namen Eindeutigkeit hinzuzufügen, funktionieren ebenfalls.

Das Festlegen lifecycle { create_before_destroy = true } ist auch erforderlich, um den Abhängigkeitszyklus zwischen den Ressourcen zu unterbrechen.

Ich werde dieses Problem schließen, da dies eine Einschränkung der AWS-API und der Art und Weise, wie Terraform mit Ressourcen umgeht, ist und vom AWS-Anbieter nicht behoben werden kann. Es gibt eine Reihe von Problemumgehungen, mit denen das Problem behoben werden kann.

Sie haben dies überwunden, indem Sie die aws_alb_target_group umbenannt und wieder umbenannt haben

Ich werde dieses Problem sperren, da es seit _30 Tagen_ ⏳ geschlossen ist. Dies hilft unseren Betreuern, die aktiven Probleme zu finden und sich darauf zu konzentrieren.

Wenn Sie der Meinung sind, dass dieses Problem erneut geöffnet werden sollte, empfehlen wir Ihnen, ein neues Problem zu erstellen, das für zusätzlichen Kontext auf dieses zurückverlinkt. Danke!