Ein Anwendungsnetzwerk definieren

Einführung

Ihre Anwendung benötigt einen Adressraum, bevor sie ausgeführt werden kann. Sie definieren mit Terraform eine AWS-VPC und ein Subnetz, vergleichen das bereitgestellte Netzwerk mit dem Terraform-State und entfernen ausschließlich Ihr Anwendungsnetzwerk.

Sie sollten den init/plan/apply-Workflow von Terraform, Ressourcenadressen und die CIDR-Grundlagen von AWS-VPCs und Subnetzen bereits kennen. Terminal, Terraform-Werkzeuge, AWS CLI und ein separates Referenznetzwerk sind vorbereitet. Jedes Lab beginnt unabhängig von den anderen; Sie benötigen keine Ressourcen aus einer früheren VM.

Bezug zu Zertifizierungen

Lab-Überblick

Die VPC definieren und bereitstellen

In diesem Schritt setzen Sie den Adressplan der Anwendung in eine Terraform-Ressource um und untersuchen die daraus entstehende VPC.

Öffnen Sie Terminal. AWS View zeigt die aktuellen Netzwerkressourcen; beobachten Sie dort die Topologie, während die CLI präzise Felder liefert und Terraform die Änderungen verwaltet. Das vorhandene reference-network gehört zu einer anderen Anwendung und muss unverändert bleiben.

Eine VPC bildet eine regionale Netzwerkgrenze. Ihr CIDR-Block definiert ihren Adressbereich: 10.62.0.0/16 reserviert Adressen für diese Anwendung. Die Terraform-Adresse aws_vpc.application ist eine Konfigurationsadresse und keine AWS-ID. AWS weist die ID nach der Erstellung zu.

Das Verzeichnis application-network enthält die vorbereitete Provider-Konfiguration. Sie wählt das bereitgestellte Konto und die getesteten Werkzeugversionen aus. Wechseln Sie in dieses Verzeichnis:

cd /home/labex/project/application-network

Erstellen Sie main.tf. Das Heredoc mit Anführungszeichen schreibt die folgende HCL bis HCL unverändert in die Datei; > erstellt oder ersetzt diese Datei. Mit dem Tag Name lässt sich das Anwendungsnetzwerk leicht vom Referenznetzwerk unterscheiden.

cat > main.tf <<'HCL'
resource "aws_vpc" "application" {
  cidr_block = "10.62.0.0/16"
  tags = {
    Name = "application-network"
  }
}
HCL

Initialisieren Sie das Arbeitsverzeichnis, um den benötigten Provider auszuwählen, und formatieren und validieren Sie anschließend die Konfiguration. Die Validierung prüft die Konfigurationsstruktur; sie beweist nicht, dass eine Ressource existiert.

terraform init
terraform fmt
terraform validate

Wenn init die Meldung Incomplete lock file information for providers ausgibt, bezieht sich dies auf 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 einen Plan. Terraform beschreibt auch die Standardeinstellungen der VPC; suchen Sie in der vorgeschlagenen Erstellung nach cidr_block und dem Tag Name.

terraform plan

Die abschließende Zusammenfassung sollte eine zu erstellende Ressource anzeigen. Wenden Sie die Konfiguration an und geben Sie yes ein, wenn Terraform um Bestätigung bittet:

terraform apply

Fragen Sie die tatsächliche VPC ab. --filters wählt das Anwendungs-Tag aus; --query zeigt nur die ID und den CIDR-Block. Die ID variiert, während der CIDR-Block 10.62.0.0/16 sein muss.

aws ec2 \
  describe-vpcs \
  --filters Name=tag:Name,Values=application-network \
  --query 'Vpcs[].{ID:VpcId,CIDR:CidrBlock}'

Prüfen Sie die aktuelle Anzeige in AWS View: Die Anwendungs-VPC erscheint neben der Referenz-VPC. Die neue VPC hat derzeit noch kein Anwendungssubnetz.

Ein Subnetz über eine Ressourcenreferenz verbinden

In diesem Schritt erstellen Sie ein Subnetz innerhalb der Anwendungs-VPC und überprüfen seinen Adressbereich, seine Availability Zone und seine Terraform-Zuordnung.

Ein Subnetz gehört zu genau einer VPC und einer Availability Zone. Verwenden Sie 10.62.1.0/24, einen kleineren Bereich innerhalb des /16-Bereichs der VPC, in us-east-1a. Weder dieser CIDR-Block noch eine Availability Zone allein machen ein Subnetz öffentlich; Internet-Routing und Zugriffsregeln folgen später.

Erstellen Sie subnet.tf. Der Ausdruck aws_vpc.application.id referenziert die VPC-Ressource. Terraform nutzt diese Abhängigkeit, um die VPC vor dem Subnetz zu erstellen, und ermittelt die tatsächliche ID automatisch. Sie kopieren keine ID aus einer Befehlsausgabe in die HCL-Konfiguration.

cat > subnet.tf <<'HCL'
resource "aws_subnet" "application" {
  vpc_id            = aws_vpc.application.id
  cidr_block        = "10.62.1.0/24"
  availability_zone = "us-east-1a"
  tags = {
    Name = "application-subnet"
  }
}

output "vpc_id" {
  value = aws_vpc.application.id
}

output "subnet_id" {
  value = aws_subnet.application.id
}
HCL

Formatieren und validieren Sie die neue Datei und prüfen Sie anschließend den Plan. Er sollte ein Subnetz hinzufügen und zwei Ausgabewerte bereitstellen, ohne Ihre VPC zu ersetzen.

terraform fmt
terraform validate
terraform plan

Wenden Sie die Konfiguration an und bestätigen Sie mit yes:

terraform apply

Speichern Sie die erzeugten IDs und zeigen Sie sie an. $(...) erfasst die Ausgabe eines Befehls; terraform output -raw gibt eine Zeichenfolge ohne Anführungszeichen zurück.

VPC_ID=$(terraform output -raw vpc_id)
echo "$VPC_ID"
SUBNET_ID=$(terraform output -raw subnet_id)
echo "$SUBNET_ID"

Fragen Sie AWS unabhängig davon ab. Das VPC-Feld des Subnetzes muss der angezeigten VPC-ID entsprechen, sein CIDR-Block muss 10.62.1.0/24 und seine Availability Zone us-east-1a sein.

aws ec2 \
  describe-subnets \
  --subnet-ids "$SUBNET_ID" \
  --query 'Subnets[].{ID:SubnetId,VPC:VpcId,CIDR:CidrBlock,Zone:AvailabilityZone}'

Der Terraform-State ordnet Konfigurationsadressen bereitgestellten Ressourcen zu. Untersuchen Sie diese Zuordnung; vergleichen Sie die VPC- und Subnetz-IDs mit AWS, statt einen State-Eintrag als Nachweis eines funktionierenden Netzwerks zu betrachten.

terraform state list
terraform state show aws_subnet.application

Die Liste enthält aws_vpc.application und aws_subnet.application. Prüfen Sie jetzt, ob Konfiguration und bereitgestellte Ressourcen übereinstimmen:

terraform plan

Erwarten Sie No changes. In AWS View erscheint das Anwendungssubnetz innerhalb seiner tatsächlichen VPC, neben dem unveränderten Referenznetzwerk.

Nur das Anwendungsnetzwerk entfernen

In diesem Schritt prüfen Sie die Löschreihenfolge, löschen Ihren Terraform-Stack und bestätigen, dass das Referenznetzwerk erhalten bleibt.

Terraform verwendet denselben Abhängigkeitsgraphen in umgekehrter Reihenfolge: Es entfernt das Subnetz vor der VPC. Ein Löschplan umfasst die von diesem Arbeitsverzeichnis verwalteten Ressourcen. Das separat vorbereitete Referenznetzwerk sollte daher nicht darin erscheinen.

Prüfen Sie die geplanten Löschungen:

terraform plan -destroy

Erwarten Sie zwei zu löschende Ressourcen. Prüfen Sie die Ressourcenadressen, bevor Sie fortfahren. Löschen Sie anschließend das Anwendungsnetzwerk und geben Sie yes ein:

terraform destroy

Fragen Sie die Anwendungsressourcen anhand ihrer Tags ab. Beide Abfragen sollten leere Listen zurückgeben; eine fehlgeschlagene Anfrage beweist keine Löschung.

aws ec2 \
  describe-vpcs \
  --filters Name=tag:Name,Values=application-network \
  --query 'Vpcs[].VpcId'
aws ec2 \
  describe-subnets \
  --filters Name=tag:Name,Values=application-subnet \
  --query 'Subnets[].SubnetId'

Bestätigen Sie, dass Terraform keine Ressourcen mehr verwaltet:

terraform state list

Der Befehl gibt keine Ressourcenadressen aus. Untersuchen Sie abschließend das erhaltene Referenzsubnetz:

aws ec2 \
  describe-subnets \
  --filters Name=tag:Name,Values=reference-subnet \
  --query 'Subnets[].{CIDR:CidrBlock,Zone:AvailabilityZone}'

Sein CIDR-Block bleibt 10.90.1.0/24 in us-east-1b. AWS View zeigt jetzt nur noch das Referenznetzwerk. Ihre HCL-Dateien bleiben zur Durchsicht verfügbar, obwohl die Anwendungsressourcen gelöscht wurden.

Zusammenfassung

Sie haben eine VPC und ein Subnetz in HCL definiert, sie über eine Ressourcenreferenz verbunden, tatsächliche AWS-Netzwerkfelder mit dem Terraform-State verglichen und einen Plan ohne Änderungen bestätigt. Anschließend haben Sie ausschließlich Ihr verwaltetes Netzwerk entfernt und ein unabhängiges Referenznetzwerk erhalten. Routing und Sicherheitsregeln sind weitere, separate Schritte auf dem Weg zu einer erreichbaren Anwendung.