Einführung
Eine laufende Instanz ist nur dann nützlich, wenn ihre Anwendung korrekt initialisiert wurde. Sie verwenden Terraform, um ein vorbereitetes Anwendungs-AMI auszulesen, eine EC2-Instanz im bereitgestellten Netzwerk zu starten und die Anwendung über User Data zu konfigurieren.
Sie sollten Terraform-Variablen und Ressourcenreferenzen, Routing in öffentlichen Subnetzen, Sicherheitsgruppen und die Grundlagen des EC2-Starts kennen. Diese frische Umgebung stellt das AMI, ein Schlüsselpaar, das Netzwerk und eine separate Referenzanwendung bereit. Sie erstellen und entfernen Ihre eigene Anwendungsinstanz.
Bezug zu Zertifizierungen
| Zertifizierung | Prüfungsaufgabe | Übung |
|---|---|---|
| Cloud Practitioner (CLF-C02) | Task 3.1 | Eine initialisierte EC2-Anwendung über Infrastructure as Code bereitstellen und ihren bereitgestellten Zustand mit der AWS CLI untersuchen. |
Lab-Überblick

Ein AMI auslesen und die Anwendung starten
In diesem Schritt verbinden Sie ein vorbereitetes AMI, Netzwerkeingaben und User Data mit einer Terraform-EC2-Ressource und überprüfen anschließend die Antwort der initialisierten Anwendung.
Öffnen Sie Terminal und AWS View. Der Referenzserver läuft bereits. Das Anwendungsnetzwerk ist bereit, aber es gibt noch keinen application-server. Dieses Lab verwendet weder die VM noch Ressourcen eines vorherigen Labs wieder.
Wechseln Sie in das Arbeitsverzeichnis und untersuchen Sie die vorbereiteten Eingabewerte:
cd /home/labex/project/application-launch
cat terraform.tfvars.json
Diese Werte kennzeichnen das bereitgestellte AMI, Subnetz und die Sicherheitsgruppe. Das Netzwerk weist beim Start bereits öffentliche IP-Adressen zu, hat eine Internet-Route und erlaubt dem User-Client den Zugriff auf Anwendungsport 8081. Terraform ist für die Kursumgebung vorbereitet; persönliche Zugangsdaten sind nicht erforderlich.
Suchen Sie das bereitgestellte Anwendungsimage über eine unabhängige AWS-Abfrage. Ein AMI beschreibt das Image, das bei der Erstellung einer Instanz verwendet wird; das Lesen eines vorhandenen AMIs erstellt kein neues Image.
aws ec2 \
describe-images \
--filters Name=name,Values=report-server-ubuntu-2204 \
--query 'Images[].{Image:ImageId,Name:Name,Architecture:Architecture}'
Der Name lautet report-server-ubuntu-2204, die Architektur ist x86_64 und die ID stimmt mit der Eingabe ami_id überein. Eine Terraform-Datenquelle liest ein vorhandenes Objekt; eine Ressource verwaltet den Lebenszyklus eines Objekts. Sie lesen dieses AMI mit data.aws_ami.application und erstellen anschließend eine Instanz mit aws_instance.application.
Erstellen Sie application.tf. Das äußere Heredoc mit Anführungszeichen schreibt HCL ohne Shell-Expansion. Innerhalb von HCL interpoliert ${...} einen Terraform-Ausdruck, und jsonencode wandelt die Nachricht in gültiges JSON um. Das innere Heredoc mit dem in Anführungszeichen gesetzten Begrenzer CONFIG schreibt dieses JSON in die Konfiguration der vorbereiteten Anwendung, wenn User Data im neuen Gastsystem ausgeführt werden.
cat > application.tf <<'HCL'
data "aws_ami" "application" {
most_recent = true
filter {
name = "image-id"
values = [var.ami_id]
}
}
resource "aws_instance" "application" {
ami = data.aws_ami.application.id
instance_type = "t3.micro"
key_name = "report-key"
subnet_id = var.subnet_id
vpc_security_group_ids = [var.security_group_id]
user_data_replace_on_change = true
user_data = <<-SCRIPT
#!/bin/bash
set -eu
cat > /etc/report-app/config.json <<'CONFIG'
${jsonencode({ message = var.message })}
CONFIG
SCRIPT
tags = {
Name = "application-server"
}
}
output "instance_id" {
value = aws_instance.application.id
}
output "image_id" {
value = data.aws_ami.application.id
}
HCL
Die Instanz referenziert die AMI-Datenquelle statt einer kopierten Image-ID. Die bereitgestellten Subnetz- und Gruppeneingaben verbinden sie mit dem vorbereiteten Netzwerk. User Data werden während des ersten Starts ausgeführt, um die Anwendung zu konfigurieren; sie sind kein interaktiver Anmeldebefehl. Der Standardwert der Eingabe message ist Terraform report application. user_data_replace_on_change führt bei späteren Änderungen der Startkonfiguration ausdrücklich zu einer Ersetzung; dieses Release-Verhalten untersuchen Sie in einem späteren Lab.
Initialisieren, formatieren und validieren Sie die Konfiguration:
terraform init
terraform fmt
terraform validate
Wenn init die Meldung Incomplete lock file information for providers ausgibt, beschreibt sie Prüfsummen für andere Plattformen. Diese vorbereitete VM verwendet linux_amd64; fahren Sie fort, nachdem Initialisierung und Validierung erfolgreich abgeschlossen wurden.
Prüfen Sie den Plan. Er liest das bereitgestellte AMI und schlägt die Erstellung einer EC2-Instanz vor. Er darf weder den Referenzserver ersetzen noch ein neues AMI erstellen.
terraform plan
Wenden Sie die Konfiguration an und geben Sie auf Nachfrage yes ein:
terraform apply
Speichern Sie die resultierende Instanz-ID und Image-ID und zeigen Sie beide an:
INSTANCE_ID=$(terraform output -raw instance_id)
echo "$INSTANCE_ID"
IMAGE_ID=$(terraform output -raw image_id)
echo "$IMAGE_ID"
Fragen Sie die Instanz unabhängig davon ab. Vergleichen Sie ihren laufenden Zustand, ihr Image, ihr Subnetz und ihre Sicherheitsgruppe mit den vorbereiteten Eingaben.
aws ec2 \
describe-instances \
--instance-ids "$INSTANCE_ID" \
--query 'Reservations[].Instances[].{ID:InstanceId,State:State.Name,Image:ImageId,Subnet:SubnetId,Groups:SecurityGroups[].GroupId,PublicIP:PublicIpAddress}'
Wählen Sie in AWS View application-server, User · 198.51.100.10 und Application · 8081 aus und klicken Sie auf Send request. Erwarten Sie Connected · 200 und Terraform report application. Die tatsächliche Anwendungsantwort weist nach, dass die Startkonfiguration die Anwendung erreicht hat; running allein würde dieses Ergebnis nicht belegen.

Beispielkontrollpunkt: AWS View zeigt die laufende Anwendung und ihre tatsächlich initialisierte Nachricht. Ressourcen-IDs und Adressen unterscheiden sich in jeder VM.
Untersuchen Sie die Terraform-Zuordnung und bestätigen Sie den übereinstimmenden Zustand:
terraform state list
terraform plan
Der State enthält die AMI-Datenquelle und die Instanzressource; der Plan meldet No changes.
Die Instanz entfernen und die bereitgestellte Infrastruktur erhalten
In diesem Schritt löschen Sie ausschließlich die von Terraform verwaltete Anwendungsinstanz und erhalten dabei ihr Quellimage, das vorbereitete Netzwerk und die Referenzanwendung.
Eine Datenquelle besitzt nicht das Image, das sie liest. VPC, Subnetz, Route, Sicherheitsgruppe und Schlüsselpaar wurden ebenfalls außerhalb dieses States bereitgestellt. Prüfen Sie den Löschumfang, bevor Sie ihn genehmigen:
terraform plan -destroy
Erwarten Sie eine zu löschende verwaltete Instanz. Führen Sie anschließend die Löschung aus und geben Sie yes ein:
terraform destroy
Fragen Sie dieselbe Instanz-ID ab. Ihr Zustand sollte terminated sein; eine fehlgeschlagene Anfrage beweist keine Terminierung.
aws ec2 \
describe-instances \
--instance-ids "$INSTANCE_ID" \
--query 'Reservations[].Instances[].{ID:InstanceId,State:State.Name}'
Das vorbereitete Image muss weiterhin unter seiner ursprünglichen ID existieren:
aws ec2 \
describe-images \
--image-ids "$IMAGE_ID" \
--query 'Images[].{Image:ImageId,Name:Name}'
Prüfen Sie den verbleibenden State:
terraform state list
Es sollte keine verwaltete Anwendungsressource mehr vorhanden sein. In AWS View ist die terminierte Instanz nicht mehr als laufendes Ziel auswählbar. Wählen Sie reference-server, die Quelle User und Port 8081 aus und senden Sie eine Anfrage. Die Antwort muss weiterhin Connected · 200 mit Reference application sein.
Behalten Sie die HCL-Dateien zur Durchsicht bei. Die erhaltene Konfiguration würde bei einem späteren gewöhnlichen Plan eine neue Instanz vorschlagen; dies bedeutet nicht, dass der Löschvorgang fehlgeschlagen ist.
Zusammenfassung
Sie haben eine AMI-Datenquelle von einer EC2-Ressource unterschieden, bereitgestellte Netzwerkeingaben eingebunden, eine Anwendung über User Data initialisiert und ihre tatsächliche Antwort geprüft. Sie haben einen Plan ohne Änderungen bestätigt und ausschließlich die verwaltete Instanz entfernt. Image, Netzwerk und Referenzanwendung blieben erhalten.



