Terraform-provider-aws: terraform versucht, den ecs-Dienst mit dem Standard-Starttyp neu zu erstellen

Gleiches Problem mit TERRAFORM_VERSION = 0.11.2 und PROVIDER_AWS_VERSION = 1.7.0 in eu-west-1.

Ich habe das gleiche Problem, auch wenn launch_type auf EC2 gesetzt wurde.

Was wirklich seltsam ist, ist, dass es in einigen Regionen zu funktionieren scheint, in anderen jedoch nicht.

Der Status wird in us-east-2 nicht aktualisiert, aber in us-east-1 und us-west-2 wird er problemlos aktualisiert (ich habe die Statusdatei direkt überprüft, um die Werte sicherzustellen).

TF v 0.10.8 und testete viele AWS-Anbieter, einschließlich des neuesten, gleichen Problems.

Vielen Dank !

Selbst wenn Sie launch_type auf EC2 , wird es nicht im Terraform-Status gesetzt, da aws das Attribut nicht zurückgibt. Wir sind mit dem Problem in eu-west-1 . Es sieht so aus, als würde AWS die Änderung einführen oder sogar nur testen.

@loivis Ich wollte gerade dieses Problem erstellen. Das ist so viel Mist. Dies in 1.12.0

-/+ module.website.aws_ecs_service.service (new resource required)
      id:                                                           "arn:aws:ecs:eu-west-1:0123456789:service/website" => <computed> (forces new resource)
      cluster:                                                      "arn:aws:ecs:eu-west-1:0123456789:cluster/ct-backend-ecs-alpha" => "arn:aws:ecs:eu-west-1:0123456789:cluster/ct-backend-ecs-alpha"
      deployment_maximum_percent:                                   "200" => "200"
      deployment_minimum_healthy_percent:                           "100" => "100"
      desired_count:                                                "1" => "1"
      iam_role:                                                     "arn:aws:iam::0123456789:role/alpha/website-alb-role-alpha" => "arn:aws:iam::0123456789:role/alpha/website-alb-role-alpha"
      launch_type:                                                  "" => "EC2" (forces new resource)
      load_balancer.#:                                              "1" => "1"
      load_balancer.6411033.container_name:                         "website" => "website"
      load_balancer.6411033.container_port:                         "80" => "80"
      load_balancer.6411033.elb_name:                               "" => ""
      load_balancer.6411033.target_group_arn:                       "arn:aws:elasticloadbalancing:eu-west-1:0123456789:targetgroup/website-alpha/f4d1ed5454453dec" => "arn:aws:elasticloadbalancing:eu-west-1:0123456789:targetgroup/website-alpha/f4d1ed5454453dec"
      name:                                                         "website" => "website"
      placement_constraints.#:                                      "1" => "1"
      placement_constraints.4150048827.expression:                  "attribute:stack == nodejs" => "attribute:stack == nodejs"
      placement_constraints.4150048827.type:                        "memberOf" => "memberOf"
      placement_strategy.#:                                         "2" => "2"
      placement_strategy.2750134989.field:                          "instanceId" => "instanceId"
      placement_strategy.2750134989.type:                           "spread" => "spread"
      placement_strategy.3619322362.field:                          "attribute:ecs.availability-zone" => "attribute:ecs.availability-zone"
      placement_strategy.3619322362.type:                           "spread" => "spread"
      task_definition:                                              "arn:aws:ecs:eu-west-1:0123456789:task-definition/website-alpha:245" => "${aws_ecs_task_definition.service.arn}"

Wir haben das gleiche Problem mit der Terraform-Version 0.11.3 und dem aws-Anbieter: 1.13 . Es führt zu Ausfallzeiten bei unseren Bereitstellungen, da der ecs-Dienst ständig zerstört und neu erstellt wird. Dies dauert länger als das Aktualisieren der Aufgabendefinition.

Hallo,

Gleiches hier in eu-west-1 auch mit aws.provider in 1.11.0 oder 1.12.0

In der Zwischenzeit können Sie ignore_changes auf launch_type . Gerade getestet, es funktioniert.

@sterfield whaaaaaat? Ich habe das getestet, funktioniert bei mir nicht :(

@joffreydupire bekommt das gleiche Problem mit Terraform 0.10.8 in eu-west-1

Hmm das ist komisch. Ich benutze 0.10.8 und die ignore_changes haben es gerade behoben. Ich kann in dem Zustand sehen, dass das Feld noch leer ist, aber TF ist jetzt glücklich.

🚫 🛑 🚫
BEARBEITEN:

Das funktioniert nicht! Obwohl der Dienst nicht zerstört und erstellt wird, wird der Dienst nicht mit der neuen Aufgabendefinition aktualisiert, wenn eine Aufgabendefinition aktualisiert wird.

Kann bestätigen! Dies hat es vorerst behoben! Werfen Sie später einen Blick auf den Code, um zu sehen, was passiert.

 .
 .
 .
  launch_type                        = "EC2"
 .
 .
  lifecycle {
    ignore_changes  = ["launch_type"]
    prevent_destroy = true
  }

@ Puneeth-n welche tf_version benutzt du?

@sterfield @ Puneeth-n hat auch für uns gearbeitet, danke.

@joffreydupire Terraform: 0.10.8 und terraform-provider-aws: 0.12.0

Ich frage mich, warum das heute passiert? Wurden heute Änderungen an der AWS-API vorgenommen?

@sterfield ignore_changes funktioniert mit dem neuesten Terraform- und AWS-Anbieter.

Eine andere Problemumgehung besteht darin, launch_type = "" explizit für die Ressource aws_ecs_service festzulegen.

Habe immer noch launch_type: "" => "EC2" (forces new resource) auch mit launch_type = "" und ignore_changes auf launch_type.

So traurig

@egarbi funktioniert hier nicht

@egarbi Ich launch_type -Eigenschaft vorhanden ist. launch_type auf andere als "" da Terraform Änderungen erkennt. Zumindest hat es in unserem Fall geholfen, es auf "" zu setzen.

@katona hat es verstanden, deine

@joffreydupire verwendet nicht gleichzeitig launch_type und ignore_changes da sonst der

@egarbi Ich habe versucht, mit launch_type = "" funktioniert nicht, dann versuchen Sie mit ignore_changes = ["launch_type"] immer noch das gleiche Problem

Ich bestätige das gleiche Verhalten mit:

• AWS-Region eu-west-1
• Terraform v0.11.3
• AWS Provider v1.7.0

Bearbeiten: Bitte sehen Sie den vollständigen Thread, tatsächlich scheint nur der auf "" gesetzte launch_type zu funktionieren.

Da TF den Starttyp in der Statusdatei nicht beibehält und wir ihn nicht speziell auf EC2 setzen können, besteht für mich das Risiko, dass sie über fargate gestartet werden?

Zuvor habe ich unsere Statusdateien einer anderen unserer Umgebungen überprüft und festgestellt, dass launch_type mit derselben TF- und AWS-Region bestehen bleibt.

@lenaing Zum Glück nicht. Gemäß der Dokumentation des ecs_service AWS-Anbieters:

launch_type - (Optional) The launch type on which to run your service. The valid values are EC2 and FARGATE. Defaults to EC2.

Übrigens sehe ich diese Änderungen auch in unseren Loadbalancern, ohne unseren Code zu berühren:

  ~ module.webclient.aws_alb.prod-extelb-webclient                                                                                           │not based on any personally identifiable information. To create
  enable_cross_zone_load_balancing:          "" => "false"

Bin ich der Einzige?

(Entschuldigung für das Pseudo-Offtopic)

@devvesa "
Ich verstehe, dass AWS dies hinzugefügt hat, um die Kompatibilität zu gewährleisten, aber sie möchten diesen Standardwert möglicherweise jederzeit ändern, um ...

@lenaing Nein, es ist standardmäßig in Terraform. Siehe hier

@loivis Der aws_ecs_service wird anscheinend nicht aktualisiert, wenn die neue Aufgabendefinition erstellt wird.

Die einzige Lösung, die zu funktionieren scheint, besteht darin, launch_type = "" und kein ignore_changes

resource "aws_ecs_task_definition" "service" {
  count                 = "${var.enable}"
  family                = "${var.name}-${var.environment}"
  container_definitions = "${var.container_definition}"
  task_role_arn         = "${var.task_role_arn}"
  network_mode          = "${var.network_mode}"
}

resource "aws_ecs_service" "service" {
  count                              = "${var.enable * var.alb_listener_count > 0 ? 1 : 0}"
  name                               = "${var.name}"
  cluster                            = "${var.cluster_id}"
  task_definition                    = "${aws_ecs_task_definition.service.arn}"
  launch_type                        = "EC2"
  desired_count                      = "${lookup(var.capacity, "desired", 1)}"
  iam_role                           = "${aws_iam_role.ecs_lb_role.arn}"
  deployment_maximum_percent         = "${var.max_healthy_percent}"
  deployment_minimum_healthy_percent = "${var.min_healthy_percent}"

  placement_strategy    = "${var.placement_strategy}"
  placement_constraints = "${var.placement_constraints}"

  load_balancer {
    target_group_arn = "${aws_alb_target_group.service.arn}"
    container_name   = "${var.name}"
    container_port   = "${lookup(var.port_mappings[0], "containerPort")}"
  }

  depends_on = ["aws_iam_role.ecs_lb_role", "aws_ecs_task_definition.service"]

  lifecycle {
    ignore_changes  = ["launch_type"]
    prevent_destroy = true
  }
}

@ Puneeth-n scheint es verursacht zu sein durch:

lifecycle {
  ignore_changes = ["launch_type"]
}

Wenn Sie stattdessen launch_type = "" verwenden, funktioniert dies einwandfrei.

BEARBEITEN:
Wenn Sie launch_type so definieren, dass es nicht null ist UND ignore_changes angibt, funktioniert dies tatsächlich wie erwartet.

@ s-maj Die Lösung, die für mich funktioniert, ist launch_type = "" Anschließend wird eine neue Aufgabendefinition erstellt und der ECS-Dienst aktualisiert. damit

lifecycle {
  ignore_changes = ["launch_type"]
}

ist eine schlechte Idee

@ Puneeth-n Ich verstehe nicht warum.

Es gibt eine Änderung bei launch_type , TF ignoriert dies und dies führt zu No changes .

Wenn Sie ein Problem haben, bei dem das Festlegen von launch_type als ignore_changes Ihren Service nicht entsprechend aktualisiert, ist dies ein separates Problem.

Ich sehe nicht, wie das Ignorieren dieses Felds, das sowohl in AWS als auch in TF standardmäßig ist, zu Problemen führen kann.

Ich habe immer noch explizit launch_type bis EC2 weil explizit> implizit, aber es ist nur um auf der sicheren Seite zu sein.

@sterfield Ich auch nicht! Ehrlich gesagt Geldautomat Ich habe nicht genug Zeit, um mich damit zu beschäftigen. Ich habe gerade gesagt, was für mich funktioniert.

Die API gibt definitiv nicht launchType für meine Dienste zurück. Könnten wir für diese Fälle standardmäßig EC2 verwenden?

Vermutlich gibt uns das SDK hier eine leere Zeichenfolge zurück:

https://github.com/terraform-providers/terraform-provider-aws/blob/6afb81fba282818c76c9006e4979d7663cf9b420/aws/resource_aws_ecs_service.go#L409

Die offene PR hier wird wahrscheinlich zusammengeführt und freigegeben, um dieses Szenario zu behandeln: # 4066

Ich habe vor dem Zusammenführen einige Nachforschungen zu den verschiedenen Regionen und Antworten angestellt, aber es scheint nicht, dass die von der ECS-API zurückgegebenen Informationen an eine andere Stelle in der Antwort verschoben wurden.

Ha, das habe ich verpasst - genau das, was ich in meinem vorherigen Kommentar vorgeschlagen habe.

Hallo zusammen,

AWS ECS Teammitglied hier. Wir haben ein vorübergehendes Szenario identifiziert, in dem das Feld launchType in den beschriebenen Dienstaufrufen nicht zurückgegeben wurde. Wir haben es behoben und bestätigt, dass es jetzt in allen API-Antworten angezeigt wird.

Vielen Dank,
Anirudh

Danke @aaithal! Ich wollte gerade posten, dass ich dies in eu-west-1 und us-east-2 nicht mehr reproduzieren konnte. Es scheint wie zuvor zu funktionieren.

@aaithal 🙏

Das Schließen dieses Problems, da die ECS-API-Antworten jetzt wie zuvor funktionieren sollten. Bitte schreiben Sie, wenn es einen Grund gibt, dieses Problem erneut zu öffnen.

Dies ist für mich in 1.40 nach dem Upgrade von 1.37 zurück

Ich werde dieses Problem sperren, da es seit 30 Tagen geschlossen ist. Dies hilft unseren Betreuern, die aktiven Themen 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 mit diesem Problem verknüpft wird. Vielen Dank!