Einführung
TIDE öffnet zwei Künstlerateliers für einen Tag. Die Website bietet ein Programm, eine Wegbeschreibung und einen herunterladbaren Leitfaden. Die City-Website ist live, und die Riverside-Referenzvorschau funktioniert weiterhin. Der Courtyard-Vorschaucontainer ist verschwunden. Stelle diesen Ort wieder her, ohne benachbarte Websites oder gemeinsame Netzwerke zu ersetzen.
Du brauchst grundlegende Terminalkenntnisse und Erfahrung mit Docker-Images, Containern und veröffentlichten Ports. Terraform wird hier eingeführt: HCL-Konfiguration, Provider, Ressourcen, Datenquellen, Pläne und Zustand. Werkzeuge und vollständige Website-Images sind vorbereitet. Du verwaltest lokales Docker auf einer Trainingsinstanz; Cloudkonto und Anwendungsprogrammierung sind nicht erforderlich.
Verwende Live Studios, Reference Preview, Venue Preview und Workstation. Venue Preview ist bis zur Wiederherstellung nicht verfügbar. Diese Umgebung startet unabhängig. Terraform 1.14.3 und der Community-Provider kreuzwerker/docker 3.0.2 sind festgelegt. Ein lokaler Provider-Spiegel macht die Initialisierung während der Übung vom öffentlichen Registry-Zugriff unabhängig.
Die Vorschau und ihre Zuständigkeitsgrenze deklarieren
In diesem Schritt nutzt du den normalen Besucherweg und deklarierst danach ausschließlich den fehlenden Container. Beginne in Live Studios. Die Startseite zeigt LIVE PROGRAMME / City. Wähle Meet the two studios, lies die Termine von Form & Field und Small Editions und wähle Find directions and the programme. Klicke auf Download the day programme und öffne die Textdatei: Sie muss City und beide Atelierprogramme enthalten. Klappe Do I need to book? auf; der Eintritt ist kostenlos und erfordert keine Buchung.
Wechsle zu Reference Preview. Derselbe Weg zeigt REFERENCE PREVIEW / Riverside. Erhalte diesen Container: Er gehört zur Terraform-Konfiguration und wird weiterhin benötigt. Venue Preview kann sich nicht verbinden, weil ihr Container fehlt. Ein fehlender Server unterscheidet sich von HTTP 404: Ein 404 stammt von einem laufenden Server, der eine bestimmte Seite nicht findet.
Root und Zustand lesen
Wechsle zu Workstation. Eine Terraform-Root ist das Verzeichnis, dessen .tf-Dateien gemeinsam ausgewertet werden. Terraform in einem anderen Verzeichnis wählt eine andere Root; Nachbarverzeichnisse werden nicht automatisch durchsucht. pwd zeigt deinen aktuellen Pfad:
pwd
/home/labex/project/preview/courtyard
ls listet Dateien auf, cat zeigt eine Textdatei. Lies die vorbereitete Konfiguration:
ls
cat main.tf
Eine .tf-Datei verwendet die Konfigurationssprache HCL. Blöcke gruppieren Einstellungen mit geschweiften Klammern; name = value weist einen Wert zu. Text in Anführungszeichen ist eine Zeichenkette; Ports sind Zahlen ohne Anführungszeichen. Der Block terraform legt das Hauptprogramm und den erforderlichen Provider fest. Ein Provider übersetzt Terraform-Operationen in Docker-API-Anfragen. provider "docker" {} verwendet den Docker-Daemon dieser Instanz und verbindet sich nicht mit einer öffentlichen Cloud.
Die beiden Blöcke data "docker_network" lesen vorhandene Netzwerke. Eine Datenquelle fragt ein Objekt ab, übernimmt aber nicht dessen Erstellung oder Löschung. city und venue sind lokale Bezeichnungen für Referenzen. Die Netzwerknamen kennzeichnen tatsächliche Docker-Objekte. Die Image-Datenquellen lesen ebenfalls vorbereitete Image-IDs. Eine echte ID verhindert, dass Tag und aufgelöste ID wiederholt als unterschiedliche Images behandelt werden.
cat reference.tf
Eine Ressource deklariert ein Objekt, das diese Root verwaltet. docker_container.reference ist eine Terraform-Adresse aus Ressourcentyp und lokaler Bezeichnung. Ihr Docker-Name lautet tide-reference. Der Container bedient intern Port 80 und veröffentlicht ihn auf Instanzport 8083. Der Ausdruck data.docker_image.reference.id liest das Attribut id der Image-Datenquelle. Da er ein Ausdruck ist, steht er nicht in Anführungszeichen.
Lass main.tf und reference.tf unverändert. Beide Netzwerke, sämtliche Image-Einträge und der Livecontainer liegen außerhalb der von dieser Root verwalteten Zuständigkeit. Die Root verwaltet zwei Container: die Referenz und die fehlende Vorschau.
Der Zustand ordnet Terraform-Adressen tatsächlichen Objekt-IDs zu. Die vorbereitete terraform.tfstate merkt sich beide Container, einschließlich des verschwundenen. Zustand ist weder Konfiguration noch Website-Backup. Bearbeite oder lösche ihn nicht. Ein späterer Plan fragt Docker nach der Realität, statt allein der gespeicherten ID zu vertrauen.
Die fehlende Ressource deklarieren
Erstelle preview.tf. Terraform verbindet sie mit den übrigen .tf-Dateien dieser Root; der Dateiname erzeugt keine eigene Umgebung. cat > preview.tf ersetzt nur diese Datei. Das zitierte HCL beginnt ein Here-Dokument: Füge den gesamten Block einschließlich des abschließenden HCL auf eigener Zeile ein. Die Anführungszeichen bewahren den wörtlichen Inhalt.
cat > preview.tf <<'HCL'
resource "docker_container" "preview" {
name = "tide-preview"
image = data.docker_image.site.id
ports {
internal = 80
external = 8082
}
networks_advanced {
name = data.docker_network.venue.name
}
}
HCL
Das deklariert einen Container aus dem vollständigen Courtyard-Image. Der verschachtelte Block ports veröffentlicht HTTP; networks_advanced verbindet den Container mit dem vorhandenen Veranstaltungsnetzwerk. Live verwendet 8081 und die Referenz 8083, daher vermeidet 8082 einen Konflikt. Ein Netzwerkverweis macht das Netzwerk nicht zu einer verwalteten Ressource.
Initialisiere diese Root. init bereitet das Provider-Plugin vor und erstellt keine Infrastruktur:
terraform init
Erwarte Terraform has been successfully initialized!. Der lokale Spiegel liefert Version 3.0.2. .terraform enthält den initialisierten Provider, .terraform.lock.hcl hält Auswahl und Prüfsummen fest. Bewahre die Sperrdatei mit der Konfiguration auf. terraform state list zeigt die gespeicherten Adressen:
terraform state list
Die Ausgabe enthält docker_container.preview, docker_container.reference sowie Image- und Netzwerkdatenquellen. Ein Eintrag der Vorschauadresse beweist nicht, dass ihr Container noch existiert.
fmt formatiert HCL-Abstände; validate prüft Syntax und Argumenttypen des Providers. Beide beweisen nicht, dass die Website läuft:
terraform fmt
terraform validate
Erwarte Success! The configuration is valid.. Bei Syntaxfehlern lies Dateiname und Zeile, vergleiche preview.tf mit dem vollständigen Block oben, korrigiere ihn und wiederhole fmt und validate. Lösche weder Zustand noch gemeinsame Konfiguration, um Fehler zu beseitigen. Deine Deklaration kann jetzt das Ziel neu erstellen und die Referenz unverändert lassen.
Eine gezielte Wiederherstellung prüfen und anwenden
In diesem Schritt unterscheidest du gespeicherten Zustand von realer Infrastruktur, stellst den vollständigen Courtyard-Besucherweg wieder her und bestätigst, dass sonst nichts geändert wird. Beginne in Workstation in derselben Root.
Änderungen vorher ansehen
terraform plan aktualisiert seine Sicht durch Lesen von Docker, vergleicht die Realität mit der Deklaration und schlägt Änderungen vor. -out=recovery.tfplan speichert diesen Vorschlag als binären Plan, damit apply den geprüften Plan ausführen kann. Gespeicherte Pläne können sensible Konfiguration enthalten; in dieser Übung gibt es keine Zugangsdaten. Lass die Datei im Projektverzeichnis.
terraform plan -out=recovery.tfplan
Achte auf die Aktualisierung der gespeicherten Vorschau-ID und anschließend auf:
## docker_container.preview will be created
...
Plan: 1 to add, 0 to change, 0 to destroy.
+ bedeutet Erstellung. ~ wäre eine Änderung am vorhandenen Objekt, - eine Löschung und -/+ ein Ersatz. Die fehlende Vorschau benötigt genau eine Erstellung. Die Referenz darf keine vorgeschlagenen Änderungen haben. Kein Netzwerk darf erstellt, ersetzt oder gelöscht werden: Es sind vorhandene gemeinsame Datenquellen, keine hier verwalteten Ressourcen.
Wenn du Löschung, Ersatz oder eine weitere Ressource siehst, halte vor apply an. Prüfe pwd, preview.tf und eine versehentliche Änderung an reference.tf. Korrigiere nur deinen Fehler anhand des Beispiels und erstelle einen neuen Plan. Ein falscher Netzwerkname kann network not found auslösen; vergleiche die vorhandenen data-Blöcke, statt ein gemeinsames Ersatznetzwerk zu erstellen. Lösche keine Container nach Namenspräfix und verwende terraform destroy nicht als Wiederherstellungsabkürzung.
Den geprüften Plan ausführen
terraform apply recovery.tfplan führt die gespeicherten Änderungen aus. Anders als apply ohne Plandatei fragt es nicht nochmals nach yes; das Speichern allein ist keine Freigabe zur Ausführung. Prüfe daher vor diesem Befehl:
terraform apply recovery.tfplan
Apply complete! Resources: 1 added, 0 changed, 0 destroyed.
Meldet Terraform einen veralteten Plan, hat eine andere Operation den Zustand nach der Planung verändert. Erstelle und prüfe einen neuen Plan vor apply. Ist Port 8082 belegt, untersuche den konkreten konkurrierenden Container, statt alle Container zu löschen. In dieser vorbereiteten Umgebung sollte er frei sein; prüfe den externen Port erneut und erhalte 8081 und 8083.
Wechsle zu Venue Preview. Lade die Seite nach Containerstart neu. Sie sollte VENUE PREVIEW / Courtyard zeigen. Folge Meet the two studios → Find directions and the programme → Download the day programme. Öffne die Datei und bestätige Courtyard und beide Vorführungszeiten. Vollständige Seiten, Stile, Illustration und Download stammen aus dem bereitgestellten Image, nicht aus einer neuen leeren Nginx-Willkommensseite.
Wechsle zu Live Studios und Reference Preview. Beide ursprünglichen Besucherwege müssen weiter funktionieren und City beziehungsweise Riverside zeigen. Verschiedene Startseitennamen allein beweisen keine Erhaltung; die zugrunde liegenden Objekte müssen dieselben bleiben.
Konvergenz und Erhaltung bestätigen
Kehre zu Workstation zurück. Ein zweiter Plan beobachtet Deklaration und Docker-Realität erneut:
terraform plan
No changes. Your infrastructure matches the configuration.
Das ist Konvergenz: Die gewünschten Ressourcen existieren mit den deklarierten Einstellungen. Terraform überwacht und repariert Container nicht fortlaufend; nach späteren Änderungen muss ein Mensch oder eine Automatisierung den Ablauf erneut ausführen. Diese Wiederherstellung betrifft ersetzbare Infrastruktur und bereitgestellte Website-Inhalte, nicht verlorene Nutzerdaten oder einen gesamten Host.
terraform state show zeigt die gespeicherten Attribute einer Ressource. Vergleiche ihre id mit der tatsächlichen Docker-ID. Dockers Option --format wählt ein Feld; einfache Anführungszeichen bewahren die Vorlage wörtlich:
terraform state show docker_container.preview
docker inspect --format '{{.Id}}' tide-preview
Beide müssen denselben neuen Container identifizieren. IDs variieren; kopiere keine Beispiel-ID in den Zustand. Lies die ursprünglichen Nachbarn und beide vorhandenen Netzwerke, ohne sie zu ändern:
docker inspect --format '{{.Name}} {{.Id}} {{.State.StartedAt}}' tide-live tide-reference
docker network inspect --format '{{.Name}} {{.Id}}' tide-city tide-courtyard
Der Kurs vergleicht diese Identitäten mit den ursprünglichen Werten. Der Livecontainer liegt außerhalb dieser Root, während die Referenz bewusst als verwaltete Ressource erhalten bleibt. Beide Grenzen sind wichtig. Du hast eine fehlende Vorschau wiederhergestellt und die übrigen Websites sowie gemeinsame Infrastruktur erhalten.
Zusammenfassung
Du hast mit HCL und einem festgelegten Docker-Provider den fehlenden Veranstaltungscontainer deklariert. Datenquellen hielten gemeinsame Netzwerke und Images außerhalb der verwalteten Zuständigkeit dieser Root. Du hast Konfiguration, Zustand und reale Objekte verglichen, eine geprüfte Erstellung angewendet, den vollständigen Besucherweg geprüft und einen Plan ohne Änderungen erreicht, während Livewebsite und Referenz erhalten blieben.
