LabEx
Beitreten

Kapazität mit einer Auto Scaling-Gruppe erhalten

AWSBeginner
Jetzt üben

Einführung

Ein Load Balancer kann eine defekte Anwendung umgehen, startet aber keinen Ersatzserver. Du erstellst eine Startvorlage und eine Gruppe für zwei Instanzen, verursachst einen Fehler und prüfst, dass eine neue Instanz tatsächlich Anfragen beantwortet.

Du solltest EC2 User Data, ALB-Zielgruppen und Anwendungsprüfungen kennen. Diese frische Umgebung liefert Netzwerk, Anwendungsimage, Schlüsselpaar und leere Zielgruppe mit HTTP-Listener, aber keine vorhandene Servergruppe. CLI und Verbindungsdateien sind unabhängig von früheren Labs vorbereitet.

Prüfungsbezug

Dieses Lab bietet einführende Praxis zu folgenden Prüfungsthemen.

Anwendungsstartvorlage erstellen

Du definierst die Konfiguration, mit der Auto Scaling jeden Server startet.

Wechsle ins Arbeitsverzeichnis und lade die vorbereiteten Netzwerkvariablen:

cd /home/labex/project
source launch.env

Eine Startvorlage speichert AMI, Typ, Sicherheitsgruppen und Startkonfiguration. Prüfe die bereitgestellte Datei:

cat launch-template.json
cat application-user-data.sh

Das JSON wählt das vorbereitete AMI, t3.micro, report-key und die Anwendungssicherheitsgruppe. UserData enthält das separat gezeigte Skript in base64. Es setzt die Nachricht auf Application ready und healthy auf true. Jeder Start muss dies anwenden, damit Ersatzserver bereit sind; eine Änderung in einem alten Server ändert die Vorlage nicht.

Erstelle die Vorlage. file:// lässt die CLI den Parameterwert aus der JSON-Datei lesen:

LT_ID=$(aws ec2 \
  create-launch-template \
  --launch-template-name application-template \
  --launch-template-data file://launch-template.json \
  --query 'LaunchTemplate.LaunchTemplateId' \
  --output text)

Vorlagen besitzen nummerierte Versionen. Prüfe Version 1, die deine Gruppe ausdrücklich verwendet:

aws ec2 \
  describe-launch-template-versions \
  --launch-template-id "$LT_ID" \
  --versions 1 \
  --query 'LaunchTemplateVersions[].{Version:VersionNumber,AMI:LaunchTemplateData.ImageId,Type:LaunchTemplateData.InstanceType,Key:LaunchTemplateData.KeyName,Groups:LaunchTemplateData.SecurityGroupIds}'

Eine Vorlage startet keine Instanzen. Öffne AWS View: ALB und Zielgruppe existieren, aber noch keine registrierten Anwendungen.

Servergruppe starten und verbinden

Du erstellst eine Auto Scaling-Gruppe und verbindest ihre echten Instanzen mit dem bereitgestellten ALB.

Eine Auto Scaling-Gruppe erhält die gewünschte Instanzzahl zwischen Minimum und Maximum. Die gewünschte Kapazität ist eine Anzahl, keine Durchsatzmessung. Minimum 2, Wunsch 2 und Maximum 3 starten zwei Server und erlauben einen weiteren.

Ermittle Zielgruppen-ARN und DNS-Namen des Load Balancers:

TG_ARN=$(aws elbv2 \
  describe-target-groups \
  --names application-targets \
  --query 'TargetGroups[0].TargetGroupArn' \
  --output text)

LB_DNS=$(aws elbv2 \
  describe-load-balancers \
  --names application-alb \
  --query 'LoadBalancers[0].DNSName' \
  --output text)

Erstelle die Gruppe mit Version 1 und beiden Subnetzen. --target-group-arns registriert Gruppeninstanzen automatisch am ALB. --health-check-type ELB berücksichtigt den Load-Balancer-Zustand beim Ersatz; EC2-Prüfungen allein erkennen nicht alle Anwendungsfehler. Die Schonfrist ermöglicht den Start vor zustandsbedingtem Ersatz. Hier sind es 30 Sekunden; in Produktion muss sie zum Startverhalten passen:

aws autoscaling \
  create-auto-scaling-group \
  --auto-scaling-group-name application-fleet \
  --launch-template "LaunchTemplateId=$LT_ID,Version=1" \
  --min-size 2 \
  --max-size 3 \
  --desired-capacity 2 \
  --vpc-zone-identifier "$SUBNET_ID,$SECOND_SUBNET_ID" \
  --target-group-arns "$TG_ARN" \
  --health-check-type ELB \
  --health-check-grace-period 30

Prüfe Gruppe und Instanz-IDs:

aws autoscaling \
  describe-auto-scaling-groups \
  --auto-scaling-group-names application-fleet \
  --query 'AutoScalingGroups[].{Min:MinSize,Desired:DesiredCapacity,Max:MaxSize,HealthCheck:HealthCheckType,Grace:HealthCheckGracePeriod,Instances:Instances[].InstanceId}'

Warte auf betriebsbereite Anwendungen und prüfe die Ziele:

aws elbv2 \
  wait target-in-service \
  --target-group-arn "$TG_ARN"

aws elbv2 \
  describe-target-health \
  --target-group-arn "$TG_ARN" \
  --query 'TargetHealthDescriptions[].{Instance:Target.Id,Health:TargetHealth.State}' \
  --output table

Erwarte zwei gesunde IDs. Sende sechs Anfragen und vergleiche die Antwort-IDs mit der Gruppe:

for request in 1 2 3 4 5 6; do
  curl --config client.conf -sS "http://$LB_DNS/health"
  echo
done

Öffne AWS View. Prüfe Kapazität 2, zwei gesunde Ziele und echte 200-Antworten beider IDs mit Send request. Subnetz- und Zonenangaben zeigen Konfiguration; physische Ausfallsicherheit zwischen Zonen wird hier nicht gemessen.

Automatischen Ersatz beobachten

Du verursachst einen Anwendungsfehler und lässt die Gruppe die Instanz ohne manuelle Reparatur ersetzen.

Wähle eine aktuelle Gruppeninstanz und ermittle ihre öffentliche SSH-Adresse:

OLD_ID=$(aws autoscaling \
  describe-auto-scaling-groups \
  --auto-scaling-group-names application-fleet \
  --query 'AutoScalingGroups[0].Instances[0].InstanceId' \
  --output text)

OLD_IP=$(aws ec2 \
  describe-instances \
  --instance-ids "$OLD_ID" \
  --query 'Reservations[0].Instances[0].PublicIpAddress' \
  --output text)

Ändere nur healthy, sodass die Anwendung 503 liefert. Wie zuvor verhindert eine temporäre JSON-Datei das Überschreiben während des Lesens:

ssh -F ssh_config "ubuntu@$OLD_IP" \
  'sudo jq ".healthy = false" /etc/report-app/config.json > /tmp/report-config.json && sudo install -m 644 /tmp/report-config.json /etc/report-app/config.json'

ssh -F ssh_config "ubuntu@$OLD_IP" \
  'curl -s -o /dev/null -w "%{http_code}\n" http://127.0.0.1:8081/health'

Erwarte 503. Die Anwendung ist defekt, während die Instanz läuft. ALB erkennt fehlgeschlagene Prüfungen; nach der Schonfrist ersetzt die Gruppe die Instanz und stellt die gewünschte Kapazität wieder her. Dieselbe Vorlage startet den Ersatz mit gesunder Konfiguration.

Beobachte IDs und Zustände in AWS View. Der ungesunde Zustand kann kurz sein, weil der Ersatz direkt folgt. Ein neues Ziel kann zunächst initial anzeigen. Führe keine Reparatur und kein zusätzliches run-instances aus.

Warte auf die Beendigung der alten Instanz und gesunde Ziele:

aws ec2 \
  wait instance-terminated \
  --instance-ids "$OLD_ID"

aws elbv2 \
  wait target-in-service \
  --target-group-arn "$TG_ARN"

Prüfe alte Instanz und aktuelle Gruppe:

aws ec2 \
  describe-instances \
  --instance-ids "$OLD_ID" \
  --query 'Reservations[].Instances[].{Instance:InstanceId,State:State.Name}'

aws autoscaling \
  describe-auto-scaling-groups \
  --auto-scaling-group-names application-fleet \
  --query 'AutoScalingGroups[].{Desired:DesiredCapacity,Instances:Instances[].InstanceId}'

Die alte ID sollte terminated sein. Kapazität bleibt 2, eine neue ID ersetzt die alte. Der Ersatz ist neu initialisiert; Änderungen nur im alten Server werden nicht automatisch übernommen.

Sende erneut sechs Anfragen:

for request in 1 2 3 4 5 6; do
  curl --config client.conf -sS "http://$LB_DNS/health"
  echo
done

Suche beide aktuellen IDs einschließlich Ersatz, ohne alte ID. Prüfe zwei gesunde Ziele in AWS View und eine echte Ersatzantwort mit Send request. Ressourcenanzahlen allein beweisen keine funktionierende Anwendung.

Ersatzinstanz beantwortet Anfragen

Beispiel: Die Kapazität bleibt zwei und die neue Instanz liefert HTTP 200. Deine IDs unterscheiden sich.

Servergruppe und Vorlage löschen

Du entfernst Gruppe, Instanzen und Vorlage und behältst den vorbereiteten ALB und das Netzwerk.

Lösche die Gruppe mit --force-delete, um ihre Instanzen trotz Minimum 2 zu beenden. Nur die Vorlage zu löschen stoppt keine Instanzen:

aws autoscaling \
  delete-auto-scaling-group \
  --auto-scaling-group-name application-fleet \
  --force-delete

aws ec2 \
  wait instance-terminated \
  --filters "Name=tag:aws:autoscaling:groupName,Values=application-fleet"

aws ec2 \
  delete-launch-template \
  --launch-template-id "$LT_ID"

Der Waiter wählt Gruppeninstanzen über das automatische Auto-Scaling-Tag, einschließlich der früher ersetzten Instanz, und wartet auf alle Beendigungen. Prüfe fehlende Gruppe, Vorlagen und Zielregistrierungen:

aws autoscaling \
  describe-auto-scaling-groups \
  --auto-scaling-group-names application-fleet \
  --query 'AutoScalingGroups[].AutoScalingGroupName'

aws ec2 \
  describe-launch-templates \
  --query 'LaunchTemplates[].LaunchTemplateName'

aws elbv2 \
  describe-target-health \
  --target-group-arn "$TG_ARN" \
  --query 'TargetHealthDescriptions[].Target.Id'

Alle drei Listen sollten [] sein. Die Abmeldung kann dauern; warte kurz und wiederhole nötigenfalls die letzte Abfrage. AWS View behält ALB und Zielgruppe ohne Servergruppe oder registrierte Ziele. Bewahre Netzwerk, AMI und Schlüsselpaar.

Zusammenfassung

Du hast eine versionierte Vorlage und eine Gruppe für zwei echte Server erstellt, ALB-Prüfungen für Ersatz genutzt, einen Fehler verursacht und Antworten einer neuen ID geprüft. Anschließend hast du Gruppe, Instanzen und Vorlage entfernt und Load Balancer sowie Netzwerk erhalten.

Im nächsten Lab ändern einfache Skalierungsrichtlinien die Kapazität und prüfen Gruppengrenzen.

Verwandt AWS Kurse
AWS-Grundlagen für Anfänger

AWS-Grundlagen für Anfänger

aws
AWS S3 für Anfänger

AWS S3 für Anfänger

aws
AWS IAM für Anfänger

AWS IAM für Anfänger

aws