Terraform-provider-aws: data.aws_ecs_task_definition: Fehler beim Abrufen der Aufgabendefinition

auch in terraform 1.0 reproduziert

Ich habe auch das gleiche Problem! Was merkwürdig ist, ist, dass beim Versuch der Suche mit einem Vanille-Status (vollständig leer) der Plan und die Anwendung wie erwartet funktionieren. Nur wenn ich eine vorhandene Statusdatei habe, funktioniert sie nicht.

Noch merkwürdiger ist, dass die Ressourcen im Statefile sowieso nicht vorhanden sind und es dennoch fehlschlägt? 🤔

Eintauchen in das Debuggen ... Ich habe festgestellt, dass func dataSourceAwsEcsTaskDefinitionRead in einem Vanille-Projekt nicht aufgerufen wird, sondern in einem vorhandenen. Dies scheint ein Terraformmuster zu sein. Ich konnte dies reproduzieren, indem ich zuerst eine einfache Ressource (eine Sicherheitsgruppe) erstellte und dann versuchte, eine Suche durchzuführen. Der Plan schlug fehl, wenn eine Ressource bereits in einer Statusdatei vorhanden war (in diesem Fall die Sicherheitsgruppe). Ich habe meine Hypothese überprüft, indem ich auch eine andere Datenquelle erstellt habe, die eine nicht vorhandene Sicherheitsgruppe nachgeschlagen hat. Der Plan dafür schlug ebenfalls fehl.

Wenn die Argumente einer Dateninstanz keine Verweise auf berechnete Werte enthalten, z. B. Attribute von Ressourcen, die noch nicht erstellt wurden, wird die Dateninstanz gelesen und ihr Status während der "Aktualisierungs" -Phase von Terraform aktualisiert, die standardmäßig vor ausgeführt wird einen Plan erstellen. Dies stellt sicher, dass die abgerufenen Daten für die Planung verfügbar sind und das Diff die tatsächlich erhaltenen Werte anzeigt.

Dateninstanzargumente können sich auf berechnete Werte beziehen. In diesem Fall können die Attribute der Instanz selbst erst aufgelöst werden, wenn alle ihre Argumente definiert sind. In diesem Fall wird das Aktualisieren der Dateninstanz bis zur "Übernehmen" -Phase verschoben, und alle Interpolationen der Dateninstanzattribute werden im Plan als "berechnet" angezeigt, da die Werte noch nicht bekannt sind.

Das ist für mich doppelt interessant. Basierend auf den oben genannten Dokumenten sollte die Konfiguration von OP nicht fehlschlagen, da data.aws_ecs_task_definition.my-service von aws_ecs_task_definition.my-service.family data.aws_ecs_task_definition.my-service abhängt, aber in der Plan * -Phase fehlschlägt (auch mein Problem). Vielleicht ist dies ein Fehler auf Terraform-Ebene und kein Anbieter-Level?

• Bearbeiten: Es wurde fälschlicherweise angegeben, dass es in der Anwendungsphase anstelle der Planphase fehlgeschlagen ist.

@radeksimko könnten wir Ihre Augen darauf

Ich sehe auch dieses Problem.

Ich brauche eigentlich keine Daten und Ressourcen für dasselbe in derselben Datei. Ich habe die Daten auskommentiert und jetzt scheint es besser zu funktionieren.

Siehe auch: https://github.com/terraform-providers/terraform-provider-aws/issues/632
Erläuterung: https://github.com/terraform-providers/terraform-provider-aws/issues/13#issuecomment -318700677

Ich konnte dieses Problem umgehen, indem ich der Datenquelle ein "abhängiges_on" hinzufügte:

resource "aws_ecs_task_definition" "task" {
...
}
data "aws_ecs_task_definition" "task" {
  depends_on = [ "aws_ecs_task_definition.task" ]
  ...
}

Ich hoffe es hilft.

Es ist nicht wirklich ein Fehler, die Lösung von @parruda ist richtig. Die resource aws_ecs_service und die data aws_ecs_task_definition erwarten beide, dass verwandte resource aws_ecs_task_definition bereits erstellt werden müssen.

@ KIVagant das macht Sinn, da ich auch das gleiche Problem hatte.

Obwohl ich sagen würde, dass die Terraform-Dokumente dafür zeigen, dass das data -Objekt und resource , die zusammen verwendet werden, aktualisiert werden sollten, um dies widerzuspiegeln. So wie es jetzt aussieht, impliziert das Dokument, dass nichts fehlschlagen sollte, wenn die Ressource nicht existiert.

Ansonsten macht @parruda solutions für mich Sinn

Ja, ich sollte das Update wahrscheinlich vor dem Antworten ausprobieren, es funktioniert, aber es führt zu einer kontinuierlichen Änderungserkennung.
Welches ist nicht das erwartete / gewünschte Ergebnis

@parrudas Fix hat bei mir funktioniert, aber jetzt löst das explizite depends_on bei jedem tf-Lauf eine Aktualisierung meiner Aufgabendefinitionen aus. Gibt es eine bewährte Methode, um dies zu verhindern? Ich verwende Terraform v0.11.5
und provider.aws v1.10.0.

@dendrochronology , ich benutze so etwas:

data "aws_ecs_task_definition" "blabla" {
  task_definition = "${aws_ecs_task_definition.blabla.family}"
  depends_on = [ "aws_ecs_task_definition.blabla" ]
}


resource "aws_ecs_task_definition" "..." {
  family                = "..."
  task_role_arn         = "${aws_iam_role.blabla.arn}"

  container_definitions = "${data.template_file.task_definition.rendered}"

  depends_on = [
    "data.template_file.task_definition",
  ]

  lifecycle {
    ignore_changes = [
      "container_definitions" # if template file changed, do nothing, believe that human's changes are source of truth
    ]
  }
}


resource "aws_ecs_service" "blabla" {
  name            = "blabla"
  cluster         = "${aws_ecs_cluster.cluster_name.id}"
  task_definition = "${aws_ecs_task_definition.blabla.family}:${max("${aws_ecs_task_definition.blabla.revision}", "${data.aws_ecs_task_definition.blabla.revision}")}"
  desired_count   = 1
  iam_role        = "${aws_iam_role.ecs_service.name}"

// Not compatible with placement_constraints:distinctInstance, commented
//  placement_strategy {
//    type  = "binpack"
//    field = "cpu"
//  }

  placement_constraints {
    type  = "distinctInstance"
  }

  load_balancer {
    elb_name       = "${aws_elb.blabla.name}"
    container_name = "internal"
    container_port = "${var.blabla_port}"
  }

  depends_on = [
    "aws_iam_role.ecs_service",
    "aws_elb.blabla",
    "aws_iam_role.blabla",
    "aws_ecs_task_definition.blabla"
  ]

  lifecycle {
    ignore_changes = ["task_definition"] # the same here, do nothing if it was already installed
  }
}

@ KIVagant ahhh, ich werde mit dem ignore_changes Lifecycle Hook spielen!

Ah, schön, damit spiele ich auch. Würde das bedeuten, dass ich das manuell taint tun müsste, wenn ich Änderungen an der Vorlagendatei für die Aufgabendefinition vornehme?

Es hängt von Ihren Zielen ab. In unserem Fall enthält die Vorlage eine leere Stelle für Geheimnisse, die nach der ersten Installation durch Terraform gefüllt werden, und wir möchten nicht zulassen, dass vorhandene Aufgabendefinitionen geändert werden. Und wir steuern sie manuell nach der ersten Installation.

@dendrochronology Entschuldigung für die fehlende Antwort. Ich habe das Problem eigentlich nie bemerkt, weil wir die Aufgabendefinition bei jedem Lauf aktualisieren möchten. Ich hoffe, Sie haben eine Lösung gefunden.

Dies scheint immer noch ein Problem zu sein. Wenn Sie nur das verwenden, was in den Dokumenten steht, erhalten Sie Folgendes:

Error: Error running plan: 1 error(s) occurred:

* module.frontshop_staging.data.aws_ecs_task_definition.frontshop: 1 error(s) occurred:

* module.frontshop_staging.data.aws_ecs_task_definition.frontshop: Resource 'aws_ecs_task_definition.frontshop' not found for variable 'aws_ecs_task_definition.frontshop.family'

Die einzigen geänderten Dinge sind, dass dies innerhalb eines Moduls ist und der Name Frontshop ist. Könnte es mit dem Modul zusammenhängen?
Ich habe es auch mit abhängigen_on versucht und es wird nicht funktionieren. Ich denke darüber nach, eine erste Version anzuwenden, um die Ressource zu erstellen, und dann die Daten mit max zu verwenden, um die neueste Version zu erhalten.

Eigentlich ist das, was ich gesagt habe, eine Lüge. Es sieht so aus, als ob es ein Problem gibt, wenn Sie einen ungültigen JSON für Containerdefinitionen haben und meiner nicht die Heredoc-Syntax verwendet, sondern eine JSON-Datei mit einer Vorlage, und es sollte ein Array von Containern sein, und ich habe nur ein Hauptobjekt.
Hier, wo ich davon erfahren habe

nett @jaysonsantos. In meinem Fall trat der Fehler aufgrund eines JSON-Syntaxfehlers auf

Bei einem Provider-Upgrade auf 1.59 und Terraform 11.11 wird dieser Fehler weiterhin angezeigt.

Wenn die Zerstörung von Terraform ohne Fehler abgeschlossen ist, funktioniert sie ohne Abhängigkeiten einwandfrei.

Wenn die Zerstörung von Terraform jedoch bei etwas anderem fehlschlägt, zum Beispiel:

 Error removing user, role, or group list from IAM Policy Detach bootstrap-iam-group-attach1:
– NoSuchEntity

Unabhängig vom ecs-Service. Etwas, das Terraform ein zweites Mal zerstört, würde sich sonst auflösen. Beim zweiten Durchgang die

Failed getting task definition ClientException: Unable to describe task definition.

Der Fehler tritt erneut auf und die Statusdatei ist beschädigt.

Dieses Problem ist mir nicht sehr klar. Es scheint, als würden einige Leute behaupten, wir sollten KEIN abhängiges_on in der Datenquelle für die Aufgabendefinition verwenden, aber beim ersten Ausführen schlägt es immer fehl, weil die Ressource nicht existiert.

Zu Ihrer Information für alle anderen, die über das Problem stolpern: https://github.com/terraform-providers/terraform-provider-aws/pull/10247 eine bessere Problemumgehung mit aws_ecs_task_definition.self.revision und erklärt, warum das besprochen depends_on Ansatz ist nicht das, was Sie wollen!

Dies umgeht das Problem, dass beim ersten Rollout der Ressourcen keine Aufgabendefinition vorhanden ist. Das Dokumentationsbeispiel für die direkte Referenzierung von "task_family" funktioniert nicht und wird beim ersten Anwenden mit einem Fehler beendet. Siehe auch diese Ausgabe Nr. 1274

Der Grund dafür ist, dass Datenquellen fehlende Daten nicht ordnungsgemäß verarbeiten. Leider wird das nicht angesprochen, wie hier angegeben: hashicorp / terraform # 16380 (Kommentar). Eine der vorgeschlagenen Problemumgehungen besteht darin, ein explizites depends_on hinzuzufügen. Dies führt jedoch zu einer möglichen Änderung der Ausgabe des Terraformplans, obwohl sich diese tatsächlich nicht ändern wird. Darüber hinaus wird durch die Terraform-Dokumentation selbst davon abgeraten.

In diesem Thread werden einige andere Problemumgehungen erwähnt, aber keine davon scheint für Hashicorp / Terraform # 16380 geeignet zu sein

aws_ecs_task_definition.self.revision kann erst referenziert werden, wenn die Ressource erstellt wurde (im Gegensatz zu family, die bereits im Code vorhanden ist). Anscheinend kann Terraform dadurch die Abhängigkeiten korrekt auflösen und die Datenquelle verhält sich wie erwartet.