Einführung
Dein Team möchte, dass jeder neue Berichtsserver mit der richtigen Begrüßung der Anwendung startet. Du schreibst ein Bash-User-Data-Skript, übergibst es beim Start einer EC2-Instance und prüfst anschließend Anwendung und Startprotokoll.
Du solltest bereits wissen, wie man eine EC2-Instance startet und sich per SSH verbindet. Diese neue Umgebung stellt ein eigenes Image, Netzwerk und Schlüsselpaar bereit; du erstellst den Server und seine Startkonfiguration.
Bezug zur Zertifizierung
Dieses Lab übt die programmgesteuerte Ressourcenkonfiguration und Startautomatisierung und unterstützt Aufgabe 3.1 der Ziele für Domain 3 von AWS Certified Cloud Practitioner CLF-C02.
Die Anwendung beim Start konfigurieren
In diesem Schritt schreibst du ein Startskript, startest damit eine Instance und prüfst die Antwort ihrer Anwendung.
User Data sind Informationen, die einer Instance beim Start übergeben werden. Ein Linux-Startskript kann damit Software automatisch konfigurieren. Standardmäßig laufen diese Skripte beim ersten Systemstart als root; ihre Befehle benötigen daher kein sudo. Der offizielle EC2-User-Data-Leitfaden beschreibt dieses Startverhalten und den Speicherort des Protokolls.
Beginne in deinem Arbeitsverzeichnis:
cd /home/labex/project
Das vorbereitete Image enthält die Berichtsanwendung. Lade die Image- und Netzwerk-IDs in deine aktuelle Shell:
source launch.env
Erstelle user-data.sh mit einem Here-Dokument. Die äußeren SCRIPT-Markierungen begrenzen das gesamte Skript; die inneren JSON-Markierungen begrenzen die Anwendungskonfiguration. Markierungen in Anführungszeichen bewahren den Text unverändert. Die erste Zeile, #!/bin/bash, wählt Bash; set -euo pipefail stoppt das Skript bei fehlgeschlagenen Befehlen oder nicht gesetzten Variablen. Das letzte echo schreibt einen hilfreichen Eintrag ins Startprotokoll.
cat > user-data.sh <<'SCRIPT'
#!/bin/bash
set -euo pipefail
cat > /etc/report-app/config.json <<'JSON'
{
"message": "Started with User Data"
}
JSON
echo 'Report application configuration applied.'
SCRIPT
Damit erstellst du eine lokale Datei; noch wird keine Instance geändert. Übergib die Datei mit --user-data file://user-data.sh an run-instances. Die AWS CLI liest und codiert sie für die API, daher musst du sie nicht selbst codieren. Gib dem Server den Namen bootstrap-server:
aws ec2 \
run-instances \
--image-id "$AMI_ID" \
--instance-type t3.micro \
--subnet-id "$SUBNET_ID" \
--security-group-ids "$SECURITY_GROUP_ID" \
--key-name report-key \
--count 1 \
--user-data file://user-data.sh \
--tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=bootstrap-server}]'
Speichere die neue Instance-ID. Der Filter wählt das Namens-Tag aus, und $(...) erfasst das Ergebnis als Klartext:
INSTANCE_ID=$(aws ec2 \
describe-instances \
--filters Name=tag:Name,Values=bootstrap-server \
--query 'Reservations[0].Instances[0].InstanceId' \
--output text)
Prüfe Zustand und öffentliche Adresse:
aws ec2 \
describe-instances \
--instance-ids "$INSTANCE_ID" \
--query 'Reservations[].Instances[].{Instance:InstanceId,State:State.Name,PublicIPv4:PublicIpAddress}'
Bestätige running. Falls weiterhin pending angezeigt wird, warte kurz und wiederhole die Abfrage. Der laufende Zustand allein beweist keine erfolgreiche Startkonfiguration; als Nächstes prüfst du die Anwendung.
Öffne AWS View, klicke auf Refresh resources und wähle bootstrap-server unter Application requests. Klicke auf Check application. Bestätige HTTP 200 und die Meldung Started with User Data. Du hast den Server über sein Startskript konfiguriert, ohne ihn nach dem Start zu bearbeiten.
Dieses Beispiel zeigt die erwartete Antwort. Deine Instance- und Netzwerk-IDs werden anders sein.
Rufe die öffentliche Adresse für die SSH-Verbindung ab:
PUBLIC_IP=$(aws ec2 \
describe-instances \
--instance-ids "$INSTANCE_ID" \
--query 'Reservations[0].Instances[0].PublicIpAddress' \
--output text)
Die bereitgestellte SSH-Konfiguration wählt den privaten Schlüssel und den Zugriffsweg des Labs:
ssh -F ssh_config ubuntu@"$PUBLIC_IP"
Du befindest dich jetzt in der Anwendungs-Instance. Lies das Startausgabeprotokoll mit Administratorrechten:
sudo cat /var/log/cloud-init-output.log
Suche nach Report application configuration applied. Dies ist die Ausgabe deines Skripts. Prüfe bei einem Startfehler dieses Protokoll auf Befehlsfehler und teste danach die Anwendung selbst, statt dich allein auf den Instance-Zustand zu verlassen.
Kehre zum LabEx-Terminal zurück:
exit
Du kannst auch die auf der Instance gespeicherten User Data abrufen. Diese Abfrage wählt deren Base64-Wert aus; die Pipeline übergibt ihn an base64 --decode, um das ursprüngliche Skript anzuzeigen:
aws ec2 \
describe-instance-attribute \
--instance-id "$INSTANCE_ID" \
--attribute userData \
--query 'UserData.Value' \
--output text | base64 --decode
Bestätige, dass Bash-Skript und Begrüßung deiner Datei entsprechen. User Data läuft normalerweise nur beim ersten Systemstart; das Stoppen und erneute Starten einer Instance wiederholt diese Konfiguration nicht automatisch. Nutze Startautomatisierung für eine wiederholbare Erstkonfiguration und schreibe keine Zugangsdaten in das Skript.
Den initialisierten Server beenden
In diesem Schritt entfernst du die erstellte Instance und prüfst ihren endgültigen Zustand.
Beende nur die Instance, die deine gespeicherte Variable identifiziert:
aws ec2 \
terminate-instances \
--instance-ids "$INSTANCE_ID"
Warte, bis die Instance terminated erreicht. Der Waiter fragt den Zustand wiederholt ab und kehrt bei Erfolg ohne Ausgabe zurück:
aws ec2 \
wait instance-terminated \
--instance-ids "$INSTANCE_ID"
Bestätige den endgültigen Zustand:
aws ec2 \
describe-instances \
--instance-ids "$INSTANCE_ID" \
--query 'Reservations[].Instances[].{Instance:InstanceId,State:State.Name}'
Das Ergebnis sollte terminated zeigen. Aktualisiere AWS View und bestätige, dass bootstrap-server kein laufendes Anwendungsziel mehr ist. Lasse das vorbereitete Netzwerk und Schlüsselpaar bestehen.
Zusammenfassung
Du hast ein Bash-User-Data-Skript geschrieben und EC2 beim Start übergeben. Du hast die automatische Anwendungskonfiguration in AWS View geprüft, das Startausgabeprotokoll gelesen und das gespeicherte Skript abgerufen. Abschließend hast du den Server beendet und seinen endgültigen Zustand bestätigt.
