Ungültige Infrastruktur vor der Planung zurückweisen

Einführung

Ihr Team verfügt bereits über Berichtsspeicher, der mit Terraform verwaltet wird. Bevor Sie automatisierte Bereitstellungen hinzufügen, benötigen Sie einen Job, der schlecht formatierte oder strukturell ungültige Konfigurationen zurückweist, bevor sie die Planungsphase erreichen.

Sie konfigurieren zwei statische Prüfungen, beobachten, wie jede Prüfung einen tatsächlich ausgeführten Job anhält, und reparieren die Konfiguration. Sie sollten bereits Terraform-Konfiguration, Plan und State, Git-Grundlagen und Shell-Exit-Status verstehen. Die vorbereitete Umgebung erfordert kein persönliches AWS-Konto.

Bezug zu Zertifizierungen

Prüfungen vor dem Plan hinzufügen

In diesem Schritt integrieren Sie statische Prüfungen in einen bereitgestellten, sequenziell ausgeführten Job. Der vorhandene Bucket und der Bericht bilden die bestehende Infrastruktur im Hintergrund: Dieses Lab muss ihre Daten und den Terraform-State unverändert lassen.

Verwenden Sie die Oberfläche Terminal. Wechseln Sie in das bereitgestellte Git-Repository und laden Sie dessen Werkzeugumgebung. source übernimmt die vorbereiteten Variablen in Ihre aktuelle Shell; es stellt keine Infrastruktur bereit.

cd /home/labex/project/report-delivery
source environment.sh

Untersuchen Sie die Ressourcenkonfiguration und die aktuellen Job-Phasen. cat gibt jede Datei aus, damit Sie sehen können, was der Job verwaltet und welche Schritte er ausführt.

cat main.tf pipeline.json

Der Bucket hat ein Tag Purpose. Der Job enthält derzeit nur eine Phase plan. Ein erfolgreicher Plan allein belegt nicht, dass zuvor Formatierung und Struktur geprüft wurden.

terraform fmt -check prüft die kanonische Formatierung von Terraform, ohne Dateien neu zu schreiben. terraform validate prüft, ob die initialisierte Konfiguration in sich konsistent ist, einschließlich der unterstützten Ressourcenattribute. Keine der beiden Prüfungen beweist, dass die Konfiguration die geschäftlichen Anforderungen erfüllt; Assertions für Module folgen im nächsten Lab.

Das bereitgestellte Ausführungsprogramm ordnet Phasennamen festen Terraform-Befehlen zu und hält beim ersten Fehler an. Lassen Sie run-job.py unverändert: Ihre Aufgabe besteht darin, pipeline.json zu konfigurieren, und nicht darin, das bereitgestellte Ausführungsprogramm umzuschreiben. Die Prüfungen bestätigen, dass der verwendete Einstiegspunkt dem bereitgestellten Original entspricht, bevor sie sein Verhalten auswerten. Fügen Sie beide Prüfungen vor der Planung hinzu. Das Here-Dokument schreibt den JSON-Inhalt zwischen seinen Begrenzern in pipeline.json; die Anführungszeichen um EOF erhalten seinen Inhalt unverändert.

cat > pipeline.json <<'EOF'
{"stages":["fmt","validate","plan"]}
EOF

Führen Sie den Job mit dem Standardinterpreter von Python aus. Dieser lokale Runner dient der Übung; seine Phasen führen standardmäßige Terraform-Befehle aus.

python3 run-job.py

Erwarten Sie [fmt] native exit 0, [validate] native exit 0 und [plan] native exit 0. Der Plan meldet keine Änderungen, weil die bereitgestellte Infrastruktur bereits ihrer Konfiguration entspricht. Ein Fehler hält spätere Phasen an. Ein Plan mit Änderungen verwendet den nativen Exit-Code 2. Der Runner behandelt ihn als erfolgreiche Vorschau, niemals als Erlaubnis zum Anwenden der Änderungen.

Untersuchen Sie Ihre Änderung mit Git. -- trennt den Pfad von den Befehlsoptionen.

git diff -- pipeline.json

Der Diff sollte beide neuen Prüfungen vor plan zeigen. In diesem Job gibt es keine Apply-Phase.

Bei einem Formatierungsfehler anhalten

In diesem Schritt fügen Sie einen gültigen HCL-Ausdruck mit nicht kanonischen Abständen ein. Anschließend weisen Sie nach, dass die Formatierungsprüfung den Job vor der Planung anhält.

Hängen Sie einen kleinen Ausgabeblock an. >> hängt Inhalt an die vorhandene Datei an. Die engen Abstände sind beabsichtigt; die Ausgabe verwaltet keine neue Ressource.

cat >> main.tf <<'EOF'

output "format_probe" {value="spacing"}
EOF

Führen Sie den Job erneut aus. Dieser Befehl soll fehlschlagen; der Fehler ist das nützliche Ergebnis.

python3 run-job.py

Die erste Phase meldet den nativen Exit-Code 3 und listet main.tf auf. Der Job gibt Job stopped; later stages did not run. aus. Es sollte keine Zeile mit [validate] oder [plan] erscheinen. Die Formatierung lässt sich korrigieren, ohne AWS zu kontaktieren.

Untersuchen Sie die konkret vorgeschlagenen Formatierungsänderungen. -diff zeigt sie an, während -check die Datei unverändert lässt.

terraform fmt -check -diff

Auch dieser Befehl gibt absichtlich einen Exit-Status ungleich null zurück. Lassen Sie den Formatierungsfehler für die Prüfung dieses Schritts bestehen; im nächsten Schritt beheben Sie ihn.

Formatierung und Gültigkeit unterscheiden

In diesem Schritt reparieren Sie die Formatierung und fügen anschließend einen anderen Fehler ein, den nur die strukturelle Validierung erkennt.

Lassen Sie Terraform zunächst die Abstände direkt in der Datei korrigieren. Wenn Sie fmt ohne -check ausführen, wird die Formatierung geändert.

terraform fmt

Die Ausgabe listet main.tf auf. Bestätigen Sie, dass die reparierte Konfiguration den Job erfolgreich durchläuft.

python3 run-job.py

Alle Phasen sollten ausgeführt werden. Durch die zusätzliche Ausgabe kann der Plan den nativen Exit-Code 2 zurückgeben; er schlägt eine Änderung der Ausgabe vor, ohne sie anzuwenden.

Hängen Sie nun eine Referenz auf ein Attribut an, das die S3-Bucket-Ressource nicht bereitstellt. Dieser Block verwendet die kanonische Formatierung und kann daher die erste Prüfung bestehen.

cat >> main.tf <<'EOF'

output "missing" {
  value = aws_s3_bucket.reports.missing_attribute
}
EOF

Prüfen Sie zunächst nur die Formatierung.

terraform fmt -check

Der Befehl gibt null zurück und erzeugt keine Ausgabe. Führen Sie anschließend den vollständigen Job aus.

python3 run-job.py

Erwarten Sie, dass die Formatierungsprüfung erfolgreich ist und validate anschließend den nativen Exit-Code 1 sowie die Diagnose Unsupported attribute ausgibt. Es sollte keine Zeile zur Planungsphase erscheinen. Der Ausdruck ist korrekt formatiert, verweist aber auf ein nicht unterstütztes Attribut. Lassen Sie diesen Fehler für die Schrittprüfung bestehen.

Die Konfiguration reparieren und die Umgebung erhalten

In diesem Schritt stellen Sie die bekannte gültige Ressourcenkonfiguration wieder her, führen den Job mit seinen vorgeschalteten Prüfungen erneut aus und überprüfen, dass sich der Berichtsspeicher nicht verändert hat.

git restore -- main.tf stellt nur diese Datei aus dem ursprünglichen Commit des Repositorys wieder her. Dabei werden beide experimentellen Ausgaben entfernt und Ihre separaten Änderungen an pipeline.json bleiben erhalten.

git restore -- main.tf

Führen Sie den vollständigen Job erneut aus.

python3 run-job.py

Alle drei Phasen sollten den nativen Exit-Code 0 zurückgeben. Der Plan sollte keine Änderungen melden. Erfolgreiche statische Prüfungen erlauben die Planung; sie genehmigen keine Bereitstellung und führen auch keine aus.

Lesen Sie den Bericht direkt aus dem Speicher. - leitet seinen Inhalt an die Standardausgabe, anstatt eine weitere lokale Kopie zu speichern.

aws s3   cp s3://delivery-gates-reports/report.csv -

Erwartete Ausgabe:

quarter,total
Q1,320

Untersuchen Sie den benachbarten Bericht, den diese Übung erhalten muss.

aws s3   cp s3://delivery-gates-neighbor/keep.txt -

Er sollte weiterhin preserve neighboring report enthalten. Prüfen Sie den abschließenden Git-Diff, um zu bestätigen, dass Ihre bleibende Änderung die Pipeline-Konfiguration betrifft.

git diff -- main.tf pipeline.json

Löschen Sie keinen der beiden vorbereiteten Buckets: Sie repräsentieren vorhandene Infrastruktur des Teams. Der Job enthält weder eine Bereitstellungsphase noch eine Phase zum Speichern eines Plans und hinterlässt daher keine neuen Cloud-Ressourcen oder Planartefakte, die bereinigt werden müssten. Die temporären Ausgabeexperimente wurden durch das Wiederherstellen von main.tf entfernt. Behalten Sie Ihre Qualitätsprüfungen für die abschließende Prüfung bei.

Zusammenfassung

Sie haben einen sequenziell ausgeführten Terraform-Job erstellt, der vor der Planung die Formatierung und die strukturelle Gültigkeit prüft. Sie haben beobachtet, wie ein Formatierungsfehler und ein separater Fehler durch ein nicht unterstütztes Attribut spätere Phasen anhalten. Anschließend haben Sie die Konfiguration repariert und die Berichtsdaten sowie den State erhalten.

Statische Gültigkeit ist eine Ebene der Qualitätssicherung. Im nächsten Lab prüfen ausführbare Assertions für Module, ob eine gültige Konfiguration das beabsichtigte Verhalten erzeugt. Informationen zu den hier verwendeten Prüfungen finden Sie in der offiziellen fmt-Referenz und der validate-Referenz.