Warum kann mein ECS-Dienst keine EC2-Instanzen mit meinem ELB registrieren?

Question

Ich habe eine EC2-Startkonfiguration, die das ECS-optimierte AMI erstellt. Ich habe eine automatische Skalierungsgruppe, die sicherstellt, dass ich immer mindestens zwei Instanzen zur Verfügung habe. Endlich habe ich einen Load Balancer.

Ich versuche, einen ECS-Dienst zu erstellen, der meine Aufgaben auf die Instanzen im Lastenausgleich verteilt.

Nach dem Lesen der Dokumentation für ECS Load Balancing, ist es mein Verständnis, dass meine ASG meine EC2-Instanzen nicht automatisch mit dem ELB registrieren sollte, weil ECS das erledigt. Also, meine ASG spezifiziert keine ELB. Ebenso hat mein ELB keine registrierten EC2-Instanzen.

Wenn ich meinen ECS-Dienst erstelle, wähle ich den ELB und wähle auch die ecsServiceRole. Nach dem Erstellen des Dienstes werden auf der Registerkarte "ECS-Instanzen" keine Instanzen angezeigt. Der Dienst kann auch keine Tasks starten, mit einem sehr allgemeinen Fehler von ...

Dienst konnte eine Aufgabe nicht platzieren, da die Ressourcen nicht gefunden werden konnten.

Ich bin seit etwa zwei Tagen hier und kann nicht herausfinden, welche Konfigurationseinstellungen nicht richtig konfiguriert sind. Hat jemand irgendwelche Ideen, was dazu führen könnte, dass dies nicht funktioniert?

aktualisieren @ 2015.06.25:

Ich denke, das könnte etwas mit der ECS_CLUSTER Benutzerdaten Einstellung zu tun.

In meiner EC2 Auto Skalierung Startkonfiguration, wenn ich die Benutzer Dateneingabe vollständig leer lassen, werden die Instanzen mit einem ECS_CLUSTER Wert von "default" erstellt. Wenn dies geschieht, sehe ich einen automatisch erstellten Cluster namens "default". In diesem Standardcluster sehe ich die Instanzen und kann Aufgaben wie erwartet mit dem ELB registrieren. Mein ELB-Gesundheitscheck (HTTP) wird bestanden, sobald die Aufgaben bei der ELB registriert sind und alles in der Welt gut ist.

Aber wenn ich diese Einstellung ECS_CLUSTER zu etwas Brauch ändern, sehe ich nie einen Cluster mit diesem Namen erstellt. Wenn ich manuell einen Cluster mit diesem Namen erstelle, werden die Instanzen niemals im Cluster sichtbar. Ich kann in diesem Szenario niemals Aufgaben mit dem ELB registrieren.

Irgendwelche Ideen?

Answer 1

Am Ende war es, dass meine EC2-Instanzen keine öffentlichen IP-Adressen zugewiesen wurden. Es scheint, dass ECS in der Lage sein muss, mit jeder EC2-Instanz direkt zu kommunizieren, was erfordert, dass jede Instanz eine öffentliche IP hat. Ich habe meinen Container-Instanzen keine öffentlichen IP-Adressen zugewiesen, da ich dachte, dass ich sie alle hinter einem öffentlichen Lastenausgleichsmodul hätte, und jede Container-Instanz wäre privat.

Answer 2

Ein weiteres Problem, das auftreten kann, ist das Zuweisen einer Rolle mit der richtigen Richtlinie für die Startkonfiguration. Meine Rolle hatte nicht die AmazonEC2ContainerServiceforEC2Role Richtlinie (oder die Berechtigungen, die es enthält) als specified here.

Answer 3

Es kann auch sein, dass der ECS-Agent eine Datei in/var/lib/ecs/data erstellt, in der der Clustername gespeichert wird.

Wenn der Agent zuerst mit dem Clusternamen 'default' startet, müssen Sie diese Datei löschen und den Agenten neu starten.

Answer 4

hatte ich ähnliche Symptome, aber am Ende die Antwort in den Log-Dateien zu finden:

/var/log/ecs/ecs-agent.2016-04-06-03:

2016-04-06T03:05:26Z [ERROR] Error registering: AccessDeniedException: User: arn:aws:sts::<removed>:assumed-role/<removed>/<removed is not authorized to perform: ecs:RegisterContainerInstance on resource: arn:aws:ecs:us-west-2:<removed:cluster/MyCluster-PROD 
    status code: 400, request id: <removed> 

In Mein Fall, die Ressource existierte, war aber nicht zugänglich. Es klingt, als würde OP auf eine Ressource zeigen, die nicht existiert oder nicht sichtbar ist. Sind Ihre Cluster und Instanzen in derselben Region? Die Protokolle sollten die Details bestätigen.

In Reaktion auf andere Beiträge:

Sie brauchen keine öffentliche IP-Adressen.

Sie benötigen: Die ecsServiceRole- oder äquivalente IAM-Rolle, die der EC2-Instanz zugewiesen wurde, um mit dem ECS-Dienst zu sprechen. Sie müssen auch den ECS-Cluster angeben und können über Benutzerdaten während der Instanz Start oder Startkonfiguration Definition, wie so geschehen:

#!/bin/bash 
echo ECS_CLUSTER=GenericSericeECSClusterPROD >> /etc/ecs/ecs.config 

Wenn Sie nicht tun dies auf neu gestartete Instanzen, können Sie dies nach dem Fall tun hat den Dienst gestartet und dann neu gestartet.

Answer 5

Dort waren mehrere Schichten von Problemen in unserem Fall. Ich werde sie auflisten, damit Sie sich ein Bild von den zu verfolgenden Fragen machen können.

Mein Gefängnis war 1 ECS in 1 Host. Aber ECS zwingt Sie, 2 Subnetze unter Ihrer VPC zu haben, und jeder hat 1 Instanz von docker host. Ich habe versucht, nur 1 Docker-Host in 1 Verfügbarkeitszone zu haben und konnte es nicht zum Laufen bringen.

Dann war das andere Problem, dass das einzige der Subnetze ein angeschlossenes Internet-Gateway hatte. So war einer von ihnen nicht öffentlich zugänglich.

Das Endergebnis war DNS diente 2 IPs für meine ELB. Und eine der IPs würde funktionieren und die andere nicht. So sah ich zufällige 404s beim Zugriff auf den NLB mit dem öffentlichen DNS.

Answer 6

Sie tun auf jeden Fall nicht benötigen öffentliche IP-Adressen für jede Ihrer privaten Instanzen. Der richtige (und sicherste) Weg dazu besteht in der Einrichtung eines NAT-Gateways und der Anbindung dieses Gateways an die Routing-Tabelle, die an Ihr privates Subnetz angeschlossen ist.

Dies ist ausführlich in der VPC-Dokumentation dokumentiert, speziell Scenario 2: VPC with Public and Private Subnets (NAT).