Einführung
Dein Team betreibt zwei Anwendungsserver, aber Clients brauchen eine gemeinsame Serviceadresse. Du erstellst einen Application Load Balancer, verbindest seinen Listener mit einer Zielgruppe und registrierst beide Server. Echte HTTP-Antworten zeigen, welcher Server die jeweilige Anfrage bearbeitet.
Du solltest EC2-Instanzen, VPC-Subnetze und Sicherheitsgruppen aus den vorherigen Kursen kennen. Die Umgebung stellt Netzwerk, laufende Server und eine konfigurierte AWS CLI bereit. Du erstellst die Ressourcen für den Lastausgleich und entfernst sie am Ende.
Bezug zu Zertifizierungen
Dieses Lab bietet Grundlagenpraxis für folgende Prüfungsthemen.
- Solutions Architect – Associate (SAA-C03) · Aufgabe 2.1: Application-Load-Balancer-Konzepte und Verteilung von Anfragen auf Anwendungsserver.
- CloudOps Engineer – Associate (SOA-C03) · Aufgabe 2.2: Grundlegende Konfiguration von Elastic Load Balancing und Beobachtung der Zielverfügbarkeit.
Den Application Load Balancer erstellen
Du erstellst einen gemeinsamen Eingang für die zwei vorbereiteten Anwendungsserver.
Ein Application Load Balancer (ALB) verteilt HTTP- oder HTTPS-Anfragen auf Anwendungsserver. Ein Network Load Balancer (NLB) behandelt Transportverbindungen wie TCP und UDP; ALB passt zu dieser HTTP-Anwendung. In diesem Lab verwendest du durchgehend ALB.
Wechsle in das vorbereitete Arbeitsverzeichnis:
cd /home/labex/project
Die Datei launch.env enthält Kennungen des bereitgestellten Netzwerks. Lies sie und lade dann mit source die Variablenzuweisungen in deine aktuelle Shell:
cat launch.env
source launch.env
SUBNET_ID und SECOND_SUBNET_ID bezeichnen Subnetze in zwei unterschiedlichen Availability Zones. ALB benötigt mindestens zwei solche Subnetze. ALB_SECURITY_GROUP_ID bezeichnet die vorbereitete Gruppe für HTTP-Listenerverkehr auf Port 80; die Server haben eine separate Gruppe für ihren Anwendungsport.
Erstelle einen internetseitigen Application Load Balancer namens application-alb. Internet-facing beschreibt sein Adressierungsschema. --query wählt nur den ARN aus, --output text erleichtert dessen Wiederverwendung. Die Shell-Syntax $(...) speichert die Ausgabe in LB_ARN:
LB_ARN=$(aws elbv2 \
create-load-balancer \
--name application-alb \
--type application \
--scheme internet-facing \
--subnets "$SUBNET_ID" "$SECOND_SUBNET_ID" \
--security-groups "$ALB_SECURITY_GROUP_ID" \
--query 'LoadBalancers[0].LoadBalancerArn' \
--output text)
Ein Amazon Resource Name (ARN) identifiziert eine AWS-Ressource. Untersuche den Load Balancer mit dem gespeicherten ARN:
aws elbv2 \
describe-load-balancers \
--load-balancer-arns "$LB_ARN" \
--query 'LoadBalancers[].{Name:LoadBalancerName,Type:Type,Scheme:Scheme,DNS:DNSName}'
Suche nach application-alb, Typ application und Schema internet-facing. Der DNS-Name ist die Adresse für Clients und variiert je nach Umgebung. Der Load Balancer allein verbindet noch keine Server.
Klicke neben Terminal auf AWS View. Die Seite liest denselben Ressourcenstatus wie CLI und sollte application-alb anzeigen. Zielgruppe und Ziele sind noch leer, weil sie noch nicht verbunden sind.
Das Bild zeigt diesen Erstellungsschritt. Der Ressourcenname passt zum Lab; der DNS-Name ist ein Beispielwert.
Einen Listener mit einer Zielgruppe verbinden
Du legst fest, wohin eingehende HTTP-Anfragen gehen.
Eine Zielgruppe enthält Server, die eine Anwendung bedienen können. Ihr Port dient zur Verbindung mit diesen Servern. Ein Listener nimmt Clientverbindungen am Load Balancer entgegen und bestimmt über eine Aktion das Ziel. Hier verwenden Clients Port 80, die Serveranwendung läuft auf 8081.
Erstelle eine Instanz-Zielgruppe in der bereitgestellten VPC. --target-type instance bedeutet, dass du EC2-Instanz-IDs registrierst. /health ist der Bereitschaftsendpunkt der Anwendung:
TG_ARN=$(aws elbv2 \
create-target-group \
--name application-targets \
--protocol HTTP \
--port 8081 \
--vpc-id "$VPC_ID" \
--target-type instance \
--health-check-path /health \
--query 'TargetGroups[0].TargetGroupArn' \
--output text)
Erstelle den HTTP-Listener. Seine Standardaktion leitet Anfragen an TG_ARN weiter. Die CLI-Kurzschreibweise Type=forward,TargetGroupArn=... definiert diese Aktion:
LISTENER_ARN=$(aws elbv2 \
create-listener \
--load-balancer-arn "$LB_ARN" \
--protocol HTTP \
--port 80 \
--default-actions "Type=forward,TargetGroupArn=$TG_ARN" \
--query 'Listeners[0].ListenerArn' \
--output text)
Untersuche den erstellten Listener:
aws elbv2 \
describe-listeners \
--load-balancer-arn "$LB_ARN" \
--query 'Listeners[].{Protocol:Protocol,Port:Port,Actions:DefaultActions}'
Die Ausgabe sollte HTTP-Port 80 und eine Weiterleitungsaktion zu deiner Zielgruppe zeigen. In AWS View erscheint die Gruppe zwischen ALB und Serverbereich. Es sind noch keine Ziele registriert; du musst die Server verbinden.
Beide Anwendungsserver registrieren und testen
Du registrierst zwei laufende Server und beobachtest echte Anfragen an beide.
Liste die vorbereiteten Server auf. Der Namensfilter wählt ihre Tags aus, die Abfrage zeigt relevante Verbindungsfelder:
aws ec2 \
describe-instances \
--filters 'Name=tag:Name,Values=app-a,app-b' \
--query 'Reservations[].Instances[].{Instance:InstanceId,Name:Tags[?Key==`Name`].Value|[0],State:State.Name,PrivateIP:PrivateIpAddress}' \
--output table
Beide Instanzen sollten running sein. Ermittle ihre IDs einzeln nach Namen, damit die Reihenfolge der Liste keine Rolle spielt:
APP_A=$(aws ec2 \
describe-instances \
--filters 'Name=tag:Name,Values=app-a' \
--query 'Reservations[0].Instances[0].InstanceId' \
--output text)
APP_B=$(aws ec2 \
describe-instances \
--filters 'Name=tag:Name,Values=app-b' \
--query 'Reservations[0].Instances[0].InstanceId' \
--output text)
Das Registrieren verbindet diese IDs mit der Zielgruppe. Ohne explizite Port-Überschreibung verwendet jedes Ziel den Anwendungsport 8081 der Gruppe:
aws elbv2 \
register-targets \
--target-group-arn "$TG_ARN" \
--targets "Id=$APP_A" "Id=$APP_B"
Der ALB prüft /health, um die Verfügbarkeit festzustellen. Warte, bis die Ziele gesund sind. Ein CLI-Waiter wiederholt reine Statusabfragen, bis die Bedingung erfüllt ist oder das Zeitlimit abläuft:
aws elbv2 \
wait target-in-service \
--target-group-arn "$TG_ARN"
Untersuche die registrierten IDs, Ports und Gesundheitszustände:
aws elbv2 \
describe-target-health \
--target-group-arn "$TG_ARN" \
--query 'TargetHealthDescriptions[].{Instance:Target.Id,Port:Target.Port,Health:TargetHealth.State}' \
--output table
Beide Ziele sollten Port 8081 und Zustand healthy zeigen. Speichere den DNS-Namen des Load Balancers:
LB_DNS=$(aws elbv2 \
describe-load-balancers \
--load-balancer-arns "$LB_ARN" \
--query 'LoadBalancers[0].DNSName' \
--output text)
Nutze den HTTP-Client curl für den Gesundheitsendpunkt. --config client.conf liest die bereitgestellten Verbindungseinstellungen; -sS verbirgt Fortschritt und zeigt Fehler weiterhin an:
curl --config client.conf -sS "http://$LB_DNS/health"
Eine erfolgreiche Antwort sieht ungefähr so aus; die Instanz-ID ist ein Beispiel:
{"service":"Report server","message":"Application ready","instance_id":"i-..."}
Sende sechs einzelne Anfragen. Die for-Schleife wiederholt die Anfrage, und echo setzt jede Antwort auf eine eigene Zeile:
for request in 1 2 3 4 5 6; do
curl --config client.conf -sS "http://$LB_DNS/health"
echo
done
Suche die Werte von APP_A und APP_B in den Antworten. Das zeigt die Verteilung auf zwei Server; die Anfrageanzahl misst weder Leistung noch Kapazität. Der Standardalgorithmus ist Round Robin. In Produktion beeinflussen auch Verbindungen und weitere Einstellungen die Verteilung.
Öffne AWS View und prüfe, dass beide Ziele gesund sind. Klicke mehrfach auf Send request und lies instance_id. Die Anfrage geht über den Listener zur Anwendung; die Karten zeigen Ressourcen, die Antwort identifiziert den tatsächlich antwortenden Server.
Das Beispiel zeigt zwei gesunde Ziele und eine erfolgreiche Anfrage. Deine IDs unterscheiden sich; vergleiche die Antwort mit deinen eigenen Zielen.
Die Ressourcen für den Lastausgleich entfernen
Du entfernst deine Ressourcen und bewahrst die bereitgestellten Server sowie das Netzwerk.
Lösche zuerst den Listener, um die Weiterleitungsabhängigkeit zur Zielgruppe zu entfernen:
aws elbv2 \
delete-listener \
--listener-arn "$LISTENER_ARN"
Lösche deinen Load Balancer und anschließend seine Zielgruppe:
aws elbv2 \
delete-load-balancer \
--load-balancer-arn "$LB_ARN"
aws elbv2 \
delete-target-group \
--target-group-arn "$TG_ARN"
Bestätige, dass beide Ressourcenlisten leer sind:
aws elbv2 \
describe-load-balancers \
--query 'LoadBalancers[].LoadBalancerName'
aws elbv2 \
describe-target-groups \
--query 'TargetGroups[].TargetGroupName'
Jede Abfrage sollte [] liefern. AWS View sollte weder Load Balancer noch Zielgruppe zeigen. Die bereitgestellten EC2-Server laufen weiter; sie sind Vorbereitungsressourcen und gehören nicht zu deiner Bereinigung.
Zusammenfassung
Du hast einen Application Load Balancer erstellt, einen HTTP-Listener mit einer Zielgruppe verbunden und zwei EC2-Server registriert. Du hast deren Gesundheit geprüft und beide Server anhand echter Antworten identifiziert. Abschließend hast du deine Ressourcen entfernt und die vorbereiteten Server sowie das Netzwerk bewahrt.
Im nächsten Lab untersuchst du, wie Gesundheitsprüfungen einen Anwendungsausfall erkennen, gesunde Ziele weiter bedienen lassen und ein wiederhergestelltes Ziel erneut aufnehmen.
