Warum Maison Code darüber spricht

Bei Maison Code Paris fungieren wir als das architektonische Gewissen unserer Kunden. Wir übernehmen oft „moderne“ Stacks, die ohne grundlegendes Verständnis für Skalierung gebaut wurden.

Wir diskutieren dieses Thema, weil es einen kritischen Wendepunkt in der technischen Reife darstellt. Die korrekte Implementierung unterscheidet ein fragiles MVP von einer widerstandsfähigen Plattform auf Unternehmensniveau.

Der „Snowflake“-Server und die ClickOps-Katastrophe

In den alten Tagen der SysAdmin-Kultur war ein Server ein Haustier. Sie haben es „Gandalf“ oder „Zeus“ genannt. Ein Entwickler würde eine SSH-Verbindung zum Server herstellen, „apt-get install nginx“ ausführen, eine Konfigurationsdatei mit „vi“ bearbeiten, den Dienst neu starten und möglicherweise einen Kernel-Parameter („sysctl.conf“) optimieren, um den Netzwerkdurchsatz zu optimieren. Sie würden dies fünf Jahre lang tun. Der Server wurde zu einer Schneeflocke. Einzigartig. Schön. Zerbrechlich. Wenn „Gandalf“ starb (Hardwarefehler), kam es zu Panik. „Wie bauen wir es wieder auf?“ „Ich weiß nicht, Bob hat es 2018 gegründet und das Unternehmen verlassen.“ „Wie war die Konfiguration?“ „Es war auf der Festplatte, die gerade gebrannt hat.“ Dies ist ClickOps (Konfiguration über Konsole/GUI) und manuelle Verwaltung. Es ist eine Katastrophe, die darauf wartet, passiert zu werden. Im Cloud-Zeitalter sind Server Vieh und keine Haustiere. Sie nennen sie „web-worker-01“, „web-worker-02“. Wenn einer krank wird, schießt man ihn ab und bringt einen neuen hervor. Infrastructure as Code (IaC) ist die Methodik, die dies ermöglicht. Sie definieren Ihre Infrastruktur in Textdateien („.tf“). Sie übergeben sie an Git. Sie überprüfen sie. Sie wenden sie über eine CLI an. Die Maschine baut den Server auf. Im Idealfall meldet sich nie wieder ein Mensch per SSH bei einer Maschine an.

Warum Maison Code Terraform diskutiert

Bei Maison Code verwalten wir die Infrastruktur für mehrere wachstumsstarke Kunden. Ein Kunde kümmert sich um Flash Sales (100-fache Traffic-Spitzen). Ein anderer verwaltet medizinische Daten (HIPAA-Konformität, strikte Verschlüsselung). Wir können uns nicht auf das menschliche Gedächtnis verlassen, um sicherzustellen, dass diese Umgebungen korrekt sind. „Habe ich die Verschlüsselung für diesen S3-Bucket aktiviert?“ Wenn Sie sich auf das Gedächtnis verlassen, lautet die Antwort „Vielleicht“. Wir verwenden Terraform, um sicherzustellen, dass die Antwort „Ja, es befindet sich in Zeile 42 von „storage.tf““ lautet. Wir bauen wiederverwendbare Module. Wir verfügen über ein Standardmodul „Maison Code Safe Bucket“, das Verschlüsselung, Protokollierung und Versionierung erzwingt. Wir verwenden dies für jeden Kunden. Dies gewährleistet Standardisierung und Security at Scale. Wir lösen das gleiche Problem nicht zweimal. Wir lösen es einmal in Terraform und stellen es überall bereit.

Das Tool: HashiCorp Terraform

Terraform ist der Goldstandard, da es Cloud-agnostisch ist. Sie können damit AWS, Google Cloud, Azure, Cloudflare, GitHub und sogar Ihre Domino’s Pizza-Bestellung verwalten (ja, es gibt einen Anbieter). Vergleichen Sie dies mit CloudFormation (nur AWS) oder ARM-Vorlagen (nur Azure). Das Erlernen von Terraform verleiht Ihnen in der gesamten Branche Superkräfte. Es verwendet HCL (HashiCorp Configuration Language). Es ist deklarativ. Sie beschreiben das Ziel, nicht die Reise. „Ich möchte 5 Server.“ (Terraform findet heraus, wie man von 2 auf 5 kommt). Anstelle von „3 Server erstellen“. (Imperativ).

Beispiel: Erstellen eines S3-Buckets

„hcl Anbieter „aws“ { Region = “us-east-1” }

Ressource „aws_s3_bucket“ „assets“ { Bucket = „maison-code-assets-prod“

Tags = { Umwelt = „Produktion“ Projekt = „Maison“ ManagedBy = “Terraform” } }

Ressource „aws_s3_bucket_public_access_block“ „block“ { Bucket = aws_s3_bucket.assets.id

block_public_acls = true block_public_policy = true ignore_public_acls = true strict_public_buckets = true }

Ressource „aws_s3_bucket_versioning“ „versioning“ { Bucket = aws_s3_bucket.assets.id versioning_configuration { Status = „Aktiviert“ } } „ Dieser Code ist Dokumentation. Jeder, der es liest, weiß: „Wir haben einen Bucket. Er ist explizit privat. Die Versionierung ist aktiviert (damit wir gelöschte Dateien wiederherstellen können).“ Das ist besser als ein 50-seitiges Word-Dokument, das das Server-Setup beschreibt (das immer veraltet ist).

The State File: Das Gehirn von Terraform

Terraform verfolgt, was es in einer Datei namens „terraform.tfstate“ erstellt hat. Dies ist eine JSON-Datei, die Ihre Coderessourcen („resource „aws_instance“ „app“) realen Bezeichnern (i-0a1b2c3d4e5f`) zuordnet. Aktueller Status vs. gewünschter Status. Wenn Sie „Terraform Plan“ ausführen, führt Terraform Folgendes aus:

Liest Ihren Code (Gewünschter Zustand).
Liest die Statusdatei (letzter bekannter Status).
Aktualisiert den Status (überprüft die AWS-APIs, um festzustellen, ob sich etwas geändert hat).
Berechnet das „Delta“ (Diff). Dann heißt es: „Ich habe vor, 1 Ressource hinzuzufügen, 2 Ressourcen zu ändern und 0 Ressourcen zu zerstören.“ Gefahr: Die Statusdatei enthält Geheimnisse (Passwörter, private Schlüssel) im Klartext. Best Practice: Übertragen Sie „terraform.tfstate“ niemals an Git. Verwenden Sie ein Remote-Backend. Speichern Sie den Status in einem S3-Bucket mit aktivierter serverseitiger Verschlüsselung. Verwenden Sie eine DynamoDB-Tabelle für Statussperre. Dies verhindert, dass zwei Entwickler gleichzeitig „terraform apply“ ausführen und den Status beschädigen.

Module: Das DON’T REPEAT YOURSELF (DRY)-Prinzip

Wenn Sie den Block „aws_instance“ zehnmal für zehn Server kopieren und einfügen, machen Sie einen Fehler. Erstellen Sie ein Modul.

Moduldefinition (modules/web-server/main.tf): „hcl Variable „Größe“ { Typ = Zeichenfolge default = „t2.micro“ } Variable „Name“ { Typ = String }

Ressource „aws_instance“ „app“ { ami = “ami-12345678” Instanztyp = var.size Tags = { Name = var.name } } „

Verwendung (main.tf): „hcl Modul „Frontend“ { source = ”./modules/web-server” Größe = „t3.small“ name = “Frontend-01” }

Modul „Backend“ { source = ”./modules/web-server” Größe = „m5.large“ name = “Backend-API” } „ Wenn Sie sich entscheiden, die AMI-ID zu ändern (Ubuntu-Version aktualisieren), ändern Sie sie an einer Stelle (im Modul) und alle Server werden aktualisiert.

Drifterkennung: Der Realitätscheck

Was passiert, wenn sich ein betrügerischer Entwickler bei der AWS-Konsole anmeldet und die Sicherheitsgruppe manuell ändert, um Port 22 (SSH) für die Welt zu öffnen? Dies ist Konfigurationsdrift. Die Realität stimmt nicht mehr mit dem Kodex überein. Wenn Sie „Terraform Plan“ das nächste Mal ausführen, wird Terraform dies sehen. „Ausgabe: Die Eingangsregel der Sicherheitsgruppe wurde von Port 22 (0.0.0.0/0) auf NULL geändert.“ Es wird vorgeschlagen, die Umgebung wieder in den im Code definierten Zustand zu reparieren. Dies erzwingt Disziplin. „ClickOps“-Änderungen sind vorübergehend und werden bei der nächsten Bereitstellung gelöscht.

Terraform-Arbeitsbereiche: Multi-Umgebung

Sie benötigen Entwicklung, Staging und Produktion. Replizieren Sie keine Ordnerstrukturen („/dev“, „/prod“). Verwenden Sie Arbeitsbereiche. „Terraform Workspace New Staging“. „Terraform Workspace neues Produkt“. Sie verwenden dieselben „.tf“-Dateien, aber unterschiedliche Statusdateien („terraform.tfstate.d/staging“, „terraform.tfstate.d/prod“). In Ihrem Code können Sie Logik verwenden: count = terraform.workspace == "prod" ? 5 : 1. Prod erhält 5 Server. Dev erhält 1.

Richtlinie als Kodex (Sentinel / OPA)

In großen Organisationen möchten Sie verhindern, dass Entwickler Fehler machen. „Niemand kann einen öffentlichen S3-Bucket erstellen.“ „Niemand kann eine Instanz bereitstellen, die größer als „groß“ ist (zu teuer).“ Sie können Open Policy Agent (OPA) oder HashiCorp Sentinel verwenden. Es wird vor „Terraform Apply“ ausgeführt. Wenn der Plan gegen die Richtlinie verstößt, blockiert er die Bereitstellung. Das ist Automatisierte Governance.

Die Sicht des Skeptikers

„Das ist zu viel Boilerplate. Ich kann einfach schneller auf die Schaltfläche klicken.“ Gegenpunkt: Das Klicken ist einmal schneller. Aber man muss es für immer aufrechterhalten. Wenn Sie die Umgebung in einer anderen Region replizieren müssen (Disaster Recovery), dauert das Klicken Tage und ist fehleranfällig. Terraform dauert Minuten („region = „eu-west-1““). Außerdem kann für „ClickOps“ keine Codeüberprüfung durchgeführt werden. Sie können einen Pull Request nicht per Mausklick öffnen. Sie können einen Mausklick nicht (einfach) rückgängig machen. Code ist Überprüfbarkeit. Code ist Vernunft.

FAQ

F: Terraform vs. Ansible? A: Terraform stellt Infrastruktur bereit (Hardware: VPC, EC2, RDS). Ansible konfiguriert Software (Die Software: Apache, MySQL Config, Benutzer). In der modernen Welt der „Immutable Infrastructure“ (Docker) wird Ansible weniger benötigt. Wir backen die Software in das Docker-Image. Terraform stellt den Containerdienst (ECS/EKS) bereit. Nutzen Sie Terraform für die Cloud. Verwenden Sie Ansible für das Betriebssystem (wenn Sie keine Container verwenden).

F: Was ist „main.tf“, „variables.tf“, „outputs.tf“? A: Es ist eine Konvention. Terraform liest alle „.tf“-Dateien im Verzeichnis.

main.tf: Die Ressourcen.
variables.tf: Eingabeargumente.
„outputs.tf“: Was am Ende gedruckt werden soll (z. B. Load Balancer-URL).

F: Terraform Cloud vs. Jenkins/GitHub-Aktionen? A: Terraform Cloud bietet nette Funktionen:

Remote-Statusverwaltung (integriert).
Private Modulregistrierung.
Kostenschätzung („Diese Änderung erhöht Ihre Rechnung um 50 €“). Sie können Terraform CLI jedoch kostenlos in GitHub Actions mit einem S3-Backend ausführen. Terraform Cloud ist kostenpflichtig (pro Benutzer). Wir beginnen normalerweise mit GitHub-Aktionen und führen bei Bedarf ein Upgrade durch.

Fazit

Infrastructure as Code macht aus „Ops“ „Dev“. Es bringt die Disziplin des Software-Engineerings (Versionskontrolle, Codeüberprüfung, Tests, CI/CD) in die Welt der Hardware. Wenn es nicht in Git ist, existiert es nicht. Hören Sie auf, Schneeflocken zu bauen. Fangen Sie an, Legos zu bauen.

Schaltflächen manuell anklicken?

Wenn Ihre Infrastruktur eine empfindliche Schneeflocke ist, die Sie nicht berühren möchten, kann Maison Code sie terraformieren. Wir entwickeln Ihr bestehendes „ClickOps“-Setup zurück und kodieren es in robuste, wiederverwendbare Terraform-Module. Wir implementieren Workflows für Zustandssperrung, Drifterkennung und Notfallwiederherstellung.

Beauftragen Sie unsere Architekten.