Application Load Balancer mit AWS Elastic Beanstalk - Zielgruppe

Application Load Balancer mit AWS Elastic Beanstalk - Zielgruppe

Ich verwende einAnwendungslastenausgleichmitAWS Elastic Beanstalk

Nach einem automatischen AWS-Serverupdate erhielt ich die Meldung „503 Service Temporarily Unavailable“ (nur diese, mit nahezu null Serverlast – einzelne Instanz).

[PHP 7.3 läuft auf 64-Bit Amazon Linux/2.9.2 (automatisches Upgrade von 2.9.1)]

Die Umgebung selbst erwies sich als gesund.

Ich verwende den Application Load Balancer für HTTPS und zukünftige Skalierung.

Es stellte sich heraus, dass AWS EB eine neue EC2-Instanz erstellt und die vorherige Instanz beendet hatte und daher keine Instanz in der Zielgruppe registriert war, auf die der Application Load Balancer verwiesen hatte.

Wie kann ich AWS so konfigurieren, dass eine Ersatz-Elastic Beanstalk EC2-Instanzautomatisch in einer Zielgruppe registriertfür einen Application Load Balancer?

Antwort1

Dies war vor einiger Zeit und was für mich gut funktioniert zu haben scheint, ist das Hinzufügen der anwendbaren Zielgruppe im Abschnitt „Zielgruppe“ unter den Auto Scaling-Gruppen.

Gehen Sie also zur EC2-Konsole und dann ganz unten im linken Menü (zumindest für mich derzeit) finden Sie die Auto Scaling Groups. Klicken Sie in der Liste auf die Auto Scaling Group, klicken Sie auf der Registerkarte Details auf Bearbeiten und fügen Sie dann die entsprechende Zielgruppe hinzu.

Dadurch bleiben sie scheinbar auch dann synchron, wenn sich die Instanzen ändern.

Es sollte also so aussehen:Bildschirmfoto

Antwort2

Ich hatte genau das gleiche Problem. Nachdem ich einen Tag lang gegoogelt und verschiedene Ansätze ausprobiert hatte, fügte ich schließlich meinem .ebextensions-Verzeichnis ein Skript mit diesen Anweisungen hinzu:

container_commands:
   01_register_ALB_target:
    command: "aws elbv2 register-targets --region us-east-1 --target-group-arn arn:aws:elasticloadbalancing:us-east-1:xxxxxxxx:targetgroup/xxxxx/xxxxx
--targets Id=$(curl -s http://169.254.169.254/latest/meta-data/instance-id)"

Ehrlich gesagt bin ich mir nicht 100 % sicher, ob es in einer tatsächlichen Crash-and-Reboot-Situation einwandfrei funktioniert. Ich unternehme zum Beispiel keine Anstrengungen, die vorherige Instanz-ID aus der Zielgruppe zu entfernen (ich vermute, sie wird automatisch entfernt, zumindest nach einer Weile). Aber der Befehl wird definitiv während der Bereitstellung ausgeführt und scheint keinen Schaden anzurichten, wenn die Instanz bereits beim Ziel registriert war.

Sehen:https://docs.aws.amazon.com/cli/latest/reference/elbv2/register-targets.html

verwandte Informationen