Eine Anwendungsbereitstellung wiederverwenden und ändern

Einführung

Eine Anwendungsbereitstellung kann sich ändern, ohne dass jede Änderung ihre Instanz ersetzt. Sie verwenden ein bereitgestelltes lokales Modul, prüfen eine Tag-Aktualisierung, die die Anwendung erhält, und veröffentlichen anschließend eine neue Startkonfiguration, die sie ersetzt. Die Anwendung liest ihren Bericht aus bereitgestelltem externem Speicher.

Dieses Lab setzt grundlegende Terraform-Modulaufrufe, Pläne und State sowie die vorherigen Labs zu EC2 und Anwendungsrollen voraus. Eine frische Umgebung stellt die anfängliche Bereitstellung, Netzwerk, AMI, Rolle und Profil, private Berichte und Referenzanwendung bereit. Sie ändern den Modulaufruf und beobachten in jeder Phase Ressourcenidentität, lokale Dateien und externe Daten.

Bezug zu Zertifizierungen

Lab-Überblick

Die Modulschnittstelle lesen und eine Aktualisierung anwenden

In diesem Schritt lesen Sie die Ein- und Ausgaben des bereitgestellten Moduls, ändern seine Release-Tag-Eingabe und prüfen, dass die vorhandene Instanz und lokale Datei unversehrt bleiben.

Die obere Ansicht AWS View beobachtet dieselben Ressourcen wie Terminal und sendet tatsächliche Anwendungsanfragen. Die Modulbereitstellung läuft bereits. Die bereitgestellte Rolle mit ihrem Profil gewährt nur das erforderliche Lesen des Berichts; Netzwerk, Rolle und Berichts-Bucket bleiben außerhalb der Zuständigkeit dieses Root-Moduls.

Untersuchen Sie den Root-Aufruf und die kleine Modulschnittstelle:

cd /home/labex/project/application-releases
cat application.tf
cat modules/application/variables.tf
cat modules/application/outputs.tf
cat modules/application/main.tf
terraform state list
ORIGINAL_ID=$(terraform output -raw instance_id)
echo "$ORIGINAL_ID"
REPORT_BUCKET=$(terraform output -raw report_bucket)
echo "$REPORT_BUCKET"

source = "./modules/application" wählt das lokale Modulverzeichnis aus. Der Aufruf übergibt vorbereitete Infrastruktureingaben sowie message und release_label. Das untergeordnete Modul erstellt die EC2-Ressource, und sein Ausgabewert stellt die tatsächliche Instanz-ID über die Root-Ausgabe bereit. Die State-Adressen beginnen daher mit module.application.

Das Modul ordnet release_label dem Tag ReleaseNote zu. Es übernimmt message in User Data und aktiviert user_data_replace_on_change. Sie ändern die Eingaben der aufrufenden Konfiguration und behalten diese bereitgestellte Implementierung bei. Lassen Sie alle drei Dateien unter modules/application/ unverändert und verwenden Sie dieses bereitgestellte lokale Modul. Nehmen Sie Ihre Änderungen im Root-Aufruf vor.

Wählen Sie in AWS View application-server, User · 198.51.100.10, Application · 8081 und Health aus und klicken Sie auf Send request. Erwarten Sie Connected · 200 und Application release one. Wählen Sie Local report file und senden Sie erneut: Die vorbereitete Instanz enthält local,existing-record. Wählen Sie Private report, um den separaten S3-Bericht period,total / Q1,320 zu lesen.

Ändern Sie ausschließlich die Tag-Eingabe von initial zu reviewed. Dies schreibt den kleinen Root-Aufruf neu und erhält dabei alle Infrastrukturreferenzen sowie die Startnachricht:

cat > application.tf <<'HCL'
module "application" {
  source = "./modules/application"
  ami_id = var.ami_id
  subnet_id = var.subnet_id
  security_group_id = var.security_group_id
  profile_name = var.profile_name
  report_bucket = var.report_bucket
  message = "Application release one"
  release_label = "reviewed"
}
output "instance_id" { value = module.application.instance_id }
output "image_id" { value = module.application.image_id }
output "report_bucket" { value = var.report_bucket }
HCL
terraform fmt
terraform validate
terraform plan

Prüfen Sie eine Aktualisierung ohne Neuerstellung des Instanz-Tags des Moduls, ohne Instanzerstellung oder -löschung. Wenden Sie die Konfiguration an und geben Sie yes ein:

terraform apply

Vergleichen Sie die tatsächliche ID und das native Tag:

echo "$ORIGINAL_ID"
terraform output -raw instance_id
aws ec2 \
  describe-instances \
  --instance-ids "$ORIGINAL_ID" \
  --query 'Reservations[].Instances[].{ID:InstanceId,State:State.Name,Tags:Tags}'

Die ID ist unverändert und ReleaseNote ist reviewed. Senden Sie in AWS View Anfragen für Health und Local report file an dieselbe Instanz. Ihre Nachricht lautet weiterhin Application release one, und ihr vorhandener lokaler Datensatz bleibt erhalten. Eine Tag-Aktualisierung führt die Startinitialisierung nicht erneut aus.

terraform plan

Erwarten Sie No changes.

Die Ersetzung durch eine neue Startkonfiguration prüfen und ausführen

In diesem Schritt ändern Sie die Startnachricht, untersuchen einen gespeicherten Ersetzungsplan und prüfen die neue Anwendung, während der externe Bericht erhalten bleibt.

Die Nachricht ist Teil von User Data. Die Einstellung user_data_replace_on_change dieses Moduls macht eine Änderung der Startkonfiguration zu einer expliziten Instanzersetzung. Der vorhandene lokale Datensatz gehört zum Dateisystem der alten Instanz; der S3-Bericht gehört zu separat bereitgestelltem Speicher.

Ändern Sie die Nachricht im Aufruf und speichern Sie den Plan:

sed -i 's/Application release one/Application release two/' application.tf
terraform fmt
terraform validate
terraform plan -out=release.tfplan
terraform show release.tfplan

Prüfen Sie die -/+-Ersetzung der Instanz und die geänderten User Data. Der Plan darf das bereitgestellte Netzwerk, die Rolle, das Profil, das Image, den Bucket oder die Referenzanwendung nicht löschen. release.tfplan speichert den geprüften Plan für den nächsten Befehl.

Führen Sie diesen gespeicherten Plan aus:

terraform apply release.tfplan

Das Ausführen eines gespeicherten Plans fragt nicht erneut nach yes; der Befehl führt die gespeicherten Aktionen aus. Warten Sie auf den Abschluss und vergleichen Sie anschließend die beiden tatsächlichen Instanzidentitäten:

NEW_ID=$(terraform output -raw instance_id)
echo "$ORIGINAL_ID"
echo "$NEW_ID"
aws ec2 \
  describe-instances \
  --instance-ids "$ORIGINAL_ID" "$NEW_ID" \
  --query 'Reservations[].Instances[].{ID:InstanceId,State:State.Name,Image:ImageId}'

Die IDs unterscheiden sich: Die ursprüngliche Instanz ist terminated, und die neue ist running auf demselben vorbereiteten AMI. Ordnen Sie die IDs zu, statt sich auf die Zeilenreihenfolge zu verlassen.

Wählen Sie in AWS View den laufenden Eintrag application-server aus und senden Sie Health. Erwarten Sie Connected · 200 und Application release two. Die terminierte alte Instanz ist nicht mehr als laufendes Ziel auswählbar.

Senden Sie Local report file. Der Inhalt lautet jetzt local,initialized und wurde durch User Data in der neuen Instanz erstellt. Der lokale Datensatz der alten Instanz wurde durch die Ersetzung nicht erhalten. Senden Sie anschließend Private report: Der externe S3-Bericht liefert weiterhin Connected · 200 mit period,total / Q1,320 zurück. Senden Sie Unrelated private object und erwarten Sie Connected · 403 mit Access denied.

Wählen Sie abschließend reference-server, User, Port 8081 und Health aus und senden Sie eine Anfrage. Sie muss weiterhin Connected · 200 und Reference application zurückgeben.

terraform plan

Erwarten Sie No changes. Die neue Instanz wird vom Modul verwaltet, während externe Daten und Referenzumgebung unversehrt bleiben.

Die Modulanwendung löschen und ihre Abhängigkeiten erhalten

In diesem Schritt entfernen Sie die verwaltete Ersatzinstanz und erhalten dabei die bereitgestellte Infrastruktur, die Anwendungsrolle und die externen Berichtsdaten.

Halten Sie die Image-ID fest, bevor Sie die verwalteten Ressourcen des Root-Moduls löschen:

IMAGE_ID=$(terraform output -raw image_id)
echo "$IMAGE_ID"
terraform plan -destroy

Erwarten Sie eine zu löschende verwaltete Instanz. Die AMI-Datenquelle liest ein vorhandenes Image; Netzwerk, Profil, Rolle und Bucket wurden dem Modul als bereitgestellte Eingaben übergeben. Führen Sie die Löschung aus und geben Sie yes ein:

terraform destroy

Fragen Sie den nativen Zustand der terminierten Ersatzinstanz ab und untersuchen Sie den verbleibenden State:

aws ec2 \
  describe-instances \
  --instance-ids "$NEW_ID" \
  --query 'Reservations[].Instances[].{ID:InstanceId,State:State.Name}'
terraform state list

Erwarten Sie terminated und keine verbleibende verwaltete Instanz im State. Das bereitgestellte Image und Profil müssen weiterhin existieren:

aws ec2 describe-images --image-ids "$IMAGE_ID" --query 'Images[].{ID:ImageId,Name:Name}'
aws iam \
  get-instance-profile \
  --instance-profile-name supplied-application-reader \
  --query 'InstanceProfile.{Name:InstanceProfileName,Roles:Roles[].RoleName}'

Verwenden Sie die verwaltende Identität in Terminal, um den erhaltenen S3-Bericht zu lesen. Dies prüft den Erhalt externer Daten; der eigene begrenzte Zugriff der Anwendung wurde vor dem Löschen geprüft.

aws s3api get-object --bucket "$REPORT_BUCKET" --key report.csv /tmp/g5-retained-report.csv
cat /tmp/g5-retained-report.csv

Seine Bytes bleiben period,total / Q1,320. Wählen Sie in AWS View reference-server, User, Port 8081 und Health aus und senden Sie eine Anfrage. Erwarten Sie Connected · 200 mit Reference application.

Behalten Sie Root- und Moduldateien zur Durchsicht bei. Erhaltene HCL-Konfiguration würde bei einem späteren gewöhnlichen Plan eine neue Instanz vorschlagen; die Bereinigung erfordert das native Löschen der verwalteten Anwendung und keinen leeren zukünftigen Plan.

Zusammenfassung

Sie haben die Ein- und Ausgaben eines bereitgestellten Moduls verwendet, um eine vorhandene Anwendung zu aktualisieren und eine Ersatzinstanz bereitzustellen. Sie haben die Auswirkungen auf Ressourcen und Daten geprüft, einen gespeicherten Plan ausgeführt, instanzlokale Dateien von erhaltenen externen Berichten unterschieden und ausschließlich die vom Modul verwaltete Anwendung bereinigt.