Wie aktualisiere ich automatisch die Liste der Nginx-Upstream-Server, wenn sich der Hostname von aws ec2 ändert oder erhöht?

Ich möchte die automatische Skalierung in AWS einrichten. Ich möchte Elastic Load Balancer nicht verwenden.

Bei der automatischen Synchronisierung in Amazon werden EC2-Instanzen nahtlos bei Bedarfsspitzen erstellt, um die Leistung aufrechtzuerhalten. Bei Bedarfsstillständen wird die Leistung automatisch verringert, um die Kosten zu minimieren.

Da diese EC2-Instanzen automatisch erstellt werden, sind ihre Hostnamen NGINX unbekannt.

Ich kenne und habe bereits Upstream-Setup in Nginx auf 10 EC2-Instanzen.

Ich möchte in der Lage sein, Servernamen automatisch zu meiner Upstream-Nginx-Konfiguration hinzuzufügen / zu aktualisieren / zu löschen , wenn bei der automatischen Skalierung EC2-Instanzen hinzugefügt / aktualisiert / gelöscht werden .

— Luis Lobo Borobia
quelle

Sie müssen "Autoscaling" aus Ihrer Frage entfernen. Autoscaling ist ein AWS-Begriff. Ich denke, was Sie meinen, ist, dass Sie automatisch skalieren möchten (horizontal), indem Sie mehr Upstream-Knoten zu Ihrem Nginx hinzufügen, der als LB fungiert, und Sie fragen, wie Sie Ihre Nginx-Konfiguration automatisch ändern können, wenn Upstream-Knoten hinzugefügt / gelöscht / geändert werden. In diesem Fall bearbeiten Sie bitte Ihre Frage entsprechend.

— Talonx

Nun, eigentlich weiß ich, was Autoscalling ist, und das möchte ich sagen. Ich möchte beides mischen. Ich werde die Frage aktualisieren.

— Luis Lobo Borobia

Die Frage ist jetzt in ihrer Absicht klarer. Ich wollte für die Wiedereröffnung stimmen, sehe aber keine Option - ich schätze, ich habe noch nicht genug Repräsentanten.

— Talonx

Vielen Dank @ Salonx Ich hoffe, andere können meine Antwort stimmen

— Luis Lobo Borobia

Ich denke, Sie können AWS-Benachrichtigungen zur automatischen Skalierung (über SNS bereitgestellt) und eine der nginx-APIs von Drittanbietern kombinieren, um Ihre nginx-Konfiguration zu aktualisieren und neu zu laden. Dabei wird vorausgesetzt, dass sie den Hostnamen der neu erstellten / beendeten Instanz zurückgibt. Entschuldigen Sie die Unklarheit - ich bin mit der automatischen Skalierungs-API nicht sehr vertraut.

— Talonx

Antworten:

Dies kann erreicht werden, indem Amazon SDK (ich bin fast fertig damit, werde es auf Github setzen) verwendet wird und der SNS-, EC2- und Autoscaling-Dienst verwendet wird.

Ich habe die folgenden Schritte befolgt, um dies zu erreichen:

Aktiviere die HTTP-Benachrichtigung und abonniere meinen Webserver.
Meiner Autoscaling-Gruppe wurde ein Lifecycle-Hook mit einem Heartbeat von 1 Minute hinzugefügt (um 1 Minute vor dem Beenden zu warten), um den Server zu beenden
Erstellt eine Indexdatei, um die Nachricht zu analysieren und festzustellen, um welche Art von Nachricht es sich handelt (z. B. Starten oder Beenden).
Sobald die Art des Ereignisses festgelegt wurde, fragte ich EC2, um die private IP der Instanz zu erhalten
Warten Sie beim Starten, bis der Header 200 empfangen wird, und fügen Sie dann die IP-Adresse zu nginx config hinzu und laden Sie sie erneut
Im Falle von Terminate entferne die IP aus der Konfiguration und lade nginx neu

Das Skript finden Sie hier https://github.com/singhupendra/aws-autoscale

— Upendra
quelle

Gibt es eine Chance, dass du das auf github gepostet hast? Ich versuche, das Gleiche zu tun, und jede Unterstützung wäre dankbar.

— Aaron

Bitte benutzen Sie - github.com/singhupendra/aws-autoscale

— Upendra

Vielen Dank an @talonx, ich habe einige Nachforschungen angestellt. Amazon Autoscale hat eine API, mit der der aktuelle Status der Autoscaling-Gruppe abgefragt und deren Mitglieder aufgelistet werden können. Es gibt die Instanz-ID zurück ( http://docs.aws.amazon.com/AutoScaling/latest/DeveloperGuide/api_requests.html#query-example ). Anschließend können Sie mithilfe der Describe-Tools den Servernamen ermitteln ( http: // docs) .aws.amazon.com / AWSEC2 / latest / CommandLineReference / ApiReference-cmd-DescribeInstances.html ) und erstellen Sie schließlich die Upstream-Include-Datei neu. Ich konnte die Autoscaling-Benachrichtigungen erkennen, um einen Prozess zu starten, der diese Aufgaben ausführt.

Ich habe es immer noch nicht implementiert, aber es ist ein langer Weg.

Man kann Autocaling auch mit SNS verwenden: http://docs.aws.amazon.com/AutoScaling/latest/DeveloperGuide/ASGettingNotifications.html

— Luis Lobo Borobia
quelle

Dies ist im Grunde das, was ich getan habe. Ich habe ein Ruby-Skript geschrieben, das alle N Minuten ausgeführt wird. Mit dem AWS SDK werden die Mitglieder der ASG abgefragt und mit einer ERB-Vorlage eine neue Konfiguration generiert. Wenn sich die neue Konfiguration von der aktuellen unterscheidet, wird sie kopiert und der Dämon (in meinem Fall Haproxy) wird angewiesen, die Konfiguration neu zu laden. Beachten Sie, dass Instanzen nach dem Beenden einige Zeit in der ASG verbleiben. Stellen Sie daher sicher, dass instance.status ==: running ausgeführt wird. Beachten Sie auch, dass wenn es N Minuten dauert, nachdem die Instanz gestartet wurde, um Anforderungen zu bedienen, diese erst jetzt verwendet werden> instance.launch_time + N.

— Mark Wagner,

Vielen Dank an MarkWagner. Gibt es eine Möglichkeit, dass Sie dieses Skript irgendwo freigeben können? Gist, Github? Vielen Dank!

— Luis Lobo Borobia

Hattest du Glück mit diesem Drehbuch? Gibt es ein Beispiel auf Github oder anderswo?

— Aaron

Nein, aber im Moment erlaubt nginx-plus (die kostenpflichtige Version) dies mehr.

— Luis Lobo Borobia

Ich habe dies selbst noch nicht implementiert, möchte jedoch die sofortige Neukonfiguration von NGiNX Plus verwenden . Ich denke, dass entweder das AMI oder das Konfigurationsmanagement (Puppet, Salt oder so), das eine Auto Scaling Group-Instanz einrichtet, die NGiNX-Rekonfigurations-API erreichen könnte (möglicherweise über einen internen Route53-Domänennamen, sodass keine feste IP-Adresse vorhanden ist) müssen verwendet werden) und fügen sich dem Upstream-Cluster für den Reverse-Proxy hinzu. Danach übernahm die integrierte Integritätsprüfung von NGiNX die [hinzugefügte] Instanz und löschte sie, falls sie nicht mehr verfügbar war. Dies scheint die sauberste Lösung zu sein, und es gibt keine Verzögerung beim Hinzufügen der Instanz und kaum Verzögerung beim Löschen, da NGiNX Plus über eine Out-of-Band-Integritätsprüfung verfügt.

Auf diese Weise müssen Sie kein Auto-Discovery-System (Consul, Serf oder ähnliches) einrichten, das für kleinere Setups häufig sowohl hinsichtlich Setup / Administration als auch der erforderlichen EC2-Instanzen einen hohen Aufwand bedeutet. Consul benötigt zum Beispiel mindestens drei Instanzen, um stabil zu sein. Serf könnte möglicherweise auf den ASG-Instanzen selbst ausgeführt werden, aber es ist immer noch mit dem Aufwand verbunden, sie zu warten. Wenn die ASG auf ein oder zwei Instanzen reduziert wird, verlieren Sie das Quorum.

Schließlich kann dies mit der automatischen Benachrichtigung über Änderungen der Auto Scaling-Gruppe kombiniert werden, möglicherweise auf den NGiNX-Servern, die für den Lastenausgleich verwendet werden. Ein durch eine solche Benachrichtigung ausgelöster Listener (dies könnte auch Upendra genannt haben) könnte dann die neue Instanz über die On-the-fly-Änderungs-API sofort zu NGiNX hinzufügen. Abgesehen von den Kosten für NGiNX Plus fragt man sich, warum überhaupt jemand Elastic Load Balancer mit seinen zahlreichen Problemen verwenden sollte.

Bearbeiten 2015.12.07: ngx_openresty ‚s - Balancer-by-lua ( siehe dieses GitHub Gewinde ) bietet eine weitere mögliche Open - Source - Lösung für Hot-Hinzufügen / Entfernen von Servern aus Nginx Upstream - Gruppe. Ich habe noch nicht selbst damit experimentiert, wollte aber hier eine Erwähnung für jeden hinzufügen, der über diesen Beitrag gestolpert ist.

— Ville
quelle