Infrastructure as Code: Terraform Überblick

Infrastructure as Code: Terraform-Überblick

Wer Software ausrollt, braucht irgendwo Server auf die ausgerollt wird. Diese Server (in der Cloud oder on-prem) müssen auch erstmal entstehen – mit Netzwerk, Storage, Firewall-Regeln, Datenbanken. Infrastructure as Code (IaC) ist die Antwort auf die Frage: wie erschaffe ich diese Infrastruktur automatisiert und reproduzierbar?

recapDiese Lektion ist eine Kurzübersicht

Terraform – das beliebteste IaC-Tool – wird in K55 L8 Terraform-Grundlagen umfassend behandelt: HCL-Syntax, Providers, Resources, State-Management, plan/apply-Workflow, Variables, Modules, Backends. Diese Lektion gibt einen Überblick im Kontext Software-Deployment und stellt die Verbindung zu den anderen K56-Themen her.

1) Was ist Infrastructure as Code?

Klassisch wurden Server in der Cloud manuell erstellt: AWS-Console aufrufen, „Launch EC2 Instance" klicken, Region wählen, Instance-Typ wählen, Storage konfigurieren, Security Group setzen – das alles für jeden Server, jedes Mal. Bei 50 Servern wird das mühsam, fehleranfällig, undokumentiert.

Infrastructure as Code (IaC) löst das: deine Infrastruktur wird als Code-Datei beschrieben. Mit einem Befehl wird sie erzeugt. Mit demselben Befehl in einer anderen Region kannst du sie identisch nochmal aufbauen. In Git versioniert. Code-Review wie normale Software.

Klick-Ops vs. Infrastructure as Code

⚠ ClickOps (manuell)

Klicken in AWS/Azure/GCP-UI
Nicht reproduzierbar
Keine Dokumentation
Drift zwischen Umgebungen
Disaster Recovery? Wochenarbeit.
Wer hat was geändert? Unklar.

✓ Infrastructure as Code

Code-Dateien beschreiben Infra
Reproduzierbar (gleicher Code = gleiche Infra)
In Git versioniert
Code-Reviews möglich
Disaster Recovery in Minuten
Audit-Trail durch Git-History

IaC ist ein zentrales DevOps-Prinzip. Es macht Infrastruktur versionierbar, teilbar, automatisierbar – genauso wie Anwendungs-Code.

2) Die wichtigsten IaC-Tools

Verschiedene Tools mit unterschiedlichen Stärken. Hier ein Überblick:

IaC-Tool-Landschaft

Terraform

Marktführer, multi-cloud, deklarativ mit HCL. Von HashiCorp.

OpenTofu

Open-Source-Fork von Terraform, Apache-2.0-Lizenz, API-kompatibel.

CloudFormation

AWS-spezifisch, YAML/JSON, in AWS-Konsole integriert.

ARM Templates / Bicep

Azure-spezifisch. Bicep = neue Sprache statt JSON.

Deployment Manager

Google Cloud Platform, YAML-basiert.

Pulumi

IaC in echten Programmiersprachen (Python, TS, Go).

Crossplane

Kubernetes-native IaC. Ressourcen als K8s-Objekte.

Ansible

Primär für Config, aber auch IaC-Module für AWS/Azure.

Cloud-spezifische Tools (CloudFormation, ARM) sind tief integriert, aber lock-in. Terraform und OpenTofu sind multi-cloud – ein Tool, alle Anbieter. Das macht sie zum De-facto-Standard in DevOps-Stellenanzeigen.

3) Terraform: ein erster Blick

Da Terraform der Marktführer ist und in den meisten Bewerbungsgesprächen vorkommt, schauen wir uns kurz an wie es aussieht. Ein einfaches Beispiel – eine EC2-Instanz auf AWS erstellen:

main.tfHCL (Terraform)

1provider "aws" {
2  region = "eu-central-1"
3}
4
5resource "aws_instance" "webserver" {
6  ami           = "ami-0faab6bdbac9486fb"  # Ubuntu 22.04
7  instance_type = "t3.micro"
8
9  tags = {
10    Name = "my-webserver"
11  }
12}

Zwei Blöcke: provider (welcher Cloud-Anbieter, welche Region) und resource (was soll erstellt werden). Terraform liest diese Datei und macht über die AWS-API genau das was beschrieben ist. terraform apply – fertig, EC2 läuft.

4) Der Terraform-Workflow

Terraform folgt einem klaren 4-Schritte-Workflow. Hier kurz:

Der Terraform-Workflow auf einen Blick

📦

init

Provider laden

▶

🔍

plan

Vorschau

▶

🚀

apply

Ausführen

▶

💥

destroy

Aufräumen

plan ist der wichtigste Schritt – er zeigt dir was Terraform tun würde, ohne es tatsächlich zu machen. Bei produktiven Systemen IMMER zuerst plan, dann apply. Mehr Details und visuelle Erklärung in K55 L8.

5) State: Terraforms Gedächtnis

Ein zentrales Konzept: State. Terraform speichert in einer Datei (terraform.tfstate), welche Ressourcen es erstellt hat und wie sie aktuell aussehen. Beim nächsten plan vergleicht es:

Was ist im Code beschrieben (Soll)?
Was steht im State (vorher erzeugt)?
Was ist tatsächlich in der Cloud (Ist)?

Daraus errechnet Terraform die nötigen Aktionen: erstellen (+), ändern (~), löschen (-). Bei Teams muss der State zentral gespeichert werden (Remote Backend in S3, Azure Storage, GCS, Terraform Cloud) – sonst überschreiben sich Kollegen gegenseitig.

6) Cloud-Anbieter und Provider

Terraform unterstützt hunderte Cloud-Anbieter über sogenannte Provider:

AWS: hashicorp/aws – größter Provider
Azure: hashicorp/azurerm
GCP: hashicorp/google
Hetzner Cloud: hetznercloud/hcloud – populär in Deutschland
DigitalOcean, Linode: für kleinere Setups
Kubernetes: hashicorp/kubernetes – K8s-Ressourcen als Code
Cloudflare: cloudflare/cloudflare – DNS, CDN, Workers
GitHub: integrations/github – Repos, Teams, Webhooks

Du kannst in einer Konfig mehrere Provider kombinieren: EC2-Instanz auf AWS, DNS-Eintrag bei Cloudflare, GitHub-Repo anlegen – alles in einem terraform apply. So baust du komplette Plattformen aus einem Guss.

7) Terraform vs. Ansible – wann was?

Häufige Verwechslung: Terraform und Ansible sind ähnliche Werkzeuge, aber mit unterschiedlichem Fokus:

Die saubere Abgrenzung

🏗 Terraform

Fokus: Infrastruktur erschaffen

Was: Server, Netzwerk, Datenbanken, Storage

Modell: deklarativ („was")

State: ja, mit State-Datei

Architektur: API-Aufrufe an Cloud-APIs

Sprache: HCL

⚙ Ansible

Fokus: Server konfigurieren

Was: Pakete, Configs, Services auf existierenden Servern

Modell: prozedural („wie")

State: stateless

Architektur: SSH zu Servern

Sprache: YAML

Typischer Workflow: Terraform erstellt die Infrastruktur (EC2 + RDS + Load Balancer). Dann übernimmt Ansible und konfiguriert die Server (installiert Software, kopiert Configs, startet Services). Beide werden oft in derselben CI/CD-Pipeline orchestriert.

8) Beispiel: Server für ein App-Deployment

Hier ein realistisches Mini-Beispiel: drei EC2-Instanzen und ein Load Balancer für eine Webapp:

webapp.tfHCL

1# 3 Webserver erstellen
2resource "aws_instance" "web" {
3  count         = 3
4  ami           = "ami-0faab6bdbac9486fb"
5  instance_type = "t3.small"
6  tags = { Name = "web-${count.index}" }
7}
8
9# Load Balancer davor
10resource "aws_lb" "main" {
11  name     = "webapp-lb"
12  subnets  = ["subnet-abc123", "subnet-def456"]
13}
14
15# DB dazu
16resource "aws_db_instance" "db" {
17  engine         = "postgres"
18  instance_class = "db.t3.medium"
19  allocated_storage = 20
20}

Nach terraform apply: AWS erstellt 3 Webserver + 1 Load Balancer + 1 Postgres-DB. Dann übergibt die Pipeline an Ansible, das die Webserver konfiguriert und die Webapp deployt. Sauberer Split: Terraform für Infra, Ansible für Software.

9) IaC und CI/CD: GitOps-Pattern

Ein moderner Workflow heißt GitOps – Infrastruktur-Änderungen laufen über Pull Requests:

Dev ändert die Terraform-Datei im Git-Repo
Macht einen Pull Request
CI-Pipeline läuft terraform plan automatisch und kommentiert den PR mit den Änderungen
Reviewer prüft den Plan: passt das?
Merge: Pipeline läuft terraform apply – Änderungen sind live

So passieren keine Infra-Änderungen mehr direkt in der Cloud-Konsole. Jede Änderung geht durch Code-Review, ist dokumentiert und reversibel. Das ist der Goldstandard für moderne Cloud-Operations.

10) Vorteile für Software-Deployment

Warum ist IaC im Deployment-Kontext so wichtig? Drei konkrete Szenarien:

Reproduzierbare Environments: Dev, Staging, Production identisch aufbauen. Mehr in L8 Umgebungen.
Disaster Recovery: Cloud-Region fällt aus → terraform apply in anderer Region, Infra ist in 15 Minuten wieder da.
Skalierung: Black-Friday-Traffic erwartet? Variable von count = 3 auf count = 30, Terraform-Apply, fertig.
Test-Umgebungen: Feature-Branch bekommt eigene Test-Umgebung – per Pipeline aufgebaut, nach dem Merge wieder zerstört (terraform destroy).
Cost Management: nachts Dev-Server runterfahren mit destroy, morgens wieder hoch – spart 50% Cloud-Kosten.

11) OpenTofu – der Open-Source-Fork

Eine wichtige Entwicklung der letzten Jahre: 2023 hat HashiCorp Terraforms Lizenz von Open Source auf eine restriktivere „Business Source License" geändert. Daraufhin wurde OpenTofu als Community-Fork unter der Apache-2.0-Lizenz geboren.

OpenTofu ist:

API-kompatibel mit Terraform – die meisten Konfigs laufen identisch
Open Source unter Apache 2.0
Von der Linux Foundation verwaltet
Wird unterstützt von vielen Cloud-Anbietern und Großunternehmen

In Europa und besonders bei Compliance-relevanten Unternehmen ist OpenTofu zunehmend Standard. Wer Terraform kann, kann auch OpenTofu.

12) Was du als Nächstes lernen solltest

Wenn dich IaC und Terraform interessieren, hier der Lernpfad:

Lies K55 L8 Terraform-Grundlagen – komplette Vertiefung mit Workflow-Stepper, State-Vergleich, Resource-Graph
Erstelle einen AWS-Free-Tier-Account (12 Monate kostenlos) und installiere Terraform
Schreibe dein erstes main.tf – eine simple EC2-Instanz starten
Lerne terraform state-Kommandos – wichtig für Troubleshooting
Erkunde die Terraform Registry – fertige Module für AWS-VPC, EKS, RDS und vieles mehr
Lerne Ansible dazu – die zweite Hälfte des Bildes
Verstehe Cloud-Computing (K31) – ohne Cloud-Wissen kein IaC

Zusammenfassung

Infrastructure as Code (IaC) beschreibt Cloud-Infrastruktur als Code-Datei – reproduzierbar, versionierbar, code-reviewbar. Löst die Probleme von ClickOps (manuelle Konsolen-Klickerei). Hauptwerkzeuge: Terraform (Marktführer, multi-cloud, HCL), OpenTofu (Open-Source-Fork), CloudFormation (AWS), ARM/Bicep (Azure), Pulumi (echte Programmiersprachen). Terraform-Workflow: init → plan → apply → destroy. State als zentrales Konzept – speichert was erzeugt wurde. Multi-Provider: AWS, Azure, GCP, Cloudflare, GitHub, Kubernetes in einer Konfig. Terraform vs. Ansible: Terraform für Infra (Server erstellen), Ansible für Konfig (Server einrichten). GitOps: Infra-Änderungen via PRs in Git. Im Deployment-Kontext: reproduzierbare Environments, Disaster Recovery, Skalierung, ephemere Test-Umgebungen. Diese Lektion ist nur eine Übersicht – für die vollständige Vertiefung siehe 👉 K55 L8 Terraform-Grundlagen.