Terraform: Infrastructure as Code

Während Ansible Server konfiguriert, beschäftigt sich Terraform mit der Stufe davor: das Erstellen der Server selbst – und der ganzen Cloud-Infrastruktur drumherum. Du beschreibst „ich brauche 3 EC2-Instanzen, einen Load Balancer, eine RDS-Datenbank, ein S3-Bucket" – Terraform erstellt das alles automatisch auf AWS, Azure, GCP oder bei dutzenden anderen Anbietern.

Diese Lektion zeigt dir Infrastructure as Code (IaC) mit Terraform: HCL-Syntax, Providers, Resources, State-Management, der typische plan/apply-Workflow, Variables und Modules. Pflicht-Skill für Cloud-Operations und einer der gefragtesten IT-Kompetenzen heute.

1) Was ist Infrastructure as Code?

Klassisch wurden Server im Cloud-Konsolen-Interface erstellt: AWS-Console aufrufen, „Launch EC2 Instance" klicken, Region wählen, AMI auswählen, Instance-Typ wählen, Storage konfigurieren, Security Group setzen, … nach 30 Klicks läuft eine Maschine. Bei 50 Servern wird das mühsam, fehleranfällig, undokumentiert.

Infrastructure as Code 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)

Konsolen-Klicken in AWS/Azure/GCP-UI
Nicht reproduzierbar, nicht dokumentiert
Wer hat was geändert? Schwer nachvollziehbar
Manuelle Fehler bei jedem neuen Setup
Inkonsistente Umgebungen (dev/staging/prod)
Disaster Recovery? Wochenarbeit.

✓ Infrastructure as Code

Code-Dateien beschreiben Infrastruktur
In Git versioniert, Code-Review möglich
Reproduzierbar – gleicher Code = gleiche Infra
Audit-Trail durch Git-History
Identische Dev/Staging/Prod-Umgebungen
Disaster Recovery in Minuten möglich

IaC ist eines der Kernkonzepte von DevOps. Tools im Bereich: Terraform (am beliebtesten, multi-cloud), AWS CloudFormation (nur AWS), Azure ARM Templates (nur Azure), Google Cloud Deployment Manager, Pulumi (in echten Programmiersprachen statt eigener Syntax).

2) Hello Terraform: eine erste Ressource

Terraform-Konfigurationen schreibst du in HCL (HashiCorp Configuration Language) – einer eigenen, deklarativen Sprache. Hier eine minimale Konfig die einen AWS-Server (EC2) erstellt:

main.tfHCL (Terraform)

1terraform {
2  required_providers {
3    aws = {
4      source  = "hashicorp/aws"
5      version = "~> 5.0"
6    }
7  }
8}
9
10provider "aws" {
11  region = "eu-central-1"
12}
13
14resource "aws_instance" "webserver" {
15  ami           = "ami-0faab6bdbac9486fb"  # Ubuntu 22.04
16  instance_type = "t3.micro"
17
18  tags = {
19    Name = "my-webserver"
20  }
21}

Drei Blöcke: terraform (welche Provider werden benötigt), provider (Konfig des Cloud-Anbieters), resource (was soll erstellt werden). Mit terraform apply baut Terraform diese EC2-Instanz auf AWS. Mit terraform destroy löschst du sie wieder.

3) Der Terraform-Workflow

Terraform folgt einem klaren 4-Schritte-Workflow. Klick die Schritte für Details:

Der Standard-Workflow

📦

init

🔍

plan

🚀

apply

💥

destroy

📦 terraform init
Initialisiert das Arbeitsverzeichnis. Lädt die benötigten Provider-Plugins (z.B. AWS-Provider) herunter, erstellt das State-Backend, prüft die Konfiguration. Einmaliger Schritt pro Projekt (oder bei Provider-Updates).

$ terraform init

Der wichtigste Befehl ist plan – er zeigt dir was Terraform tun würde, ohne es tatsächlich zu machen. So vermeidest du böse Überraschungen. Bei produktiven Systemen IMMER zuerst plan, dann apply.

4) Der State: Terraforms Gedächtnis

Das wichtigste interne Konzept von Terraform: der State. Terraform speichert in einer Datei (terraform.tfstate), welche Ressourcen es verwaltet und in welchem Zustand. Beim nächsten plan vergleicht es:

State-Vergleich: Code vs. Realität

resource "aws_instance" "web"
instance_type = "t3.small"

= same

EC2 i-abc123
instance_type = "t3.small"

resource "aws_s3_bucket" "data"
versioning = true

~ diff

S3 my-data
versioning = false

resource "aws_security_group" "fw"
(neu im Code)

+ new

(noch nicht in AWS)

Terraform plant dann genau die Aktionen: S3 bucket-Versioning aktivieren, neue Security Group erstellen, EC2-Instance lassen. State-Lock: in Teams muss der State zentral liegen (S3, Terraform Cloud) – sonst überschreiben sich Kollegen gegenseitig. Locks verhindern parallele Änderungen.

5) Variables und Outputs

Hardcoded Werte sind Anti-Pattern. Mit Variables machst du deine Konfig parametrisierbar:

variables.tfHCL

1variable "environment" {
2  type        = string
3  description = "Umgebung: dev, staging, prod"
4  default     = "dev"
5}
6
7variable "instance_count" {
8  type    = number
9  default = 2
10}
11
12# Nutzung in main.tf
13resource "aws_instance" "web" {
14  count = var.instance_count
15  tags = {
16    Name = "web-${var.environment}-${count.index}"
17  }
18}
19
20# Outputs zeigen Werte nach apply
21output "public_ips" {
22  value = aws_instance.web[*].public_ip
23}

Beim Apply kannst du Variablen überschreiben: terraform apply -var="environment=prod" -var="instance_count=5". Oder du legst eine terraform.tfvars-Datei an wo alle Werte stehen. Mit Outputs zeigt Terraform am Ende wichtige Werte (z.B. die generierten IP-Adressen).

6) Ressourcen-Abhängigkeiten

Terraform erkennt automatisch Abhängigkeiten zwischen Ressourcen. Wenn Resource A auf Resource B referenziert, wird B zuerst erstellt. So entsteht ein Dependency Graph:

Terraform Dependency Graph (vereinfacht)

VPC

my_vpc

↓

Subnet

public_subnet

Security Group

web_sg

↓

EC2 Instance

webserver

EC2 Instance

webserver

↓

Load Balancer

web_lb

Terraform erstellt zuerst die VPC, dann Subnetze und Security Groups, dann die EC2-Instanzen, zuletzt den Load Balancer. Wenn möglich parallelisiert – Subnet und Security Group werden gleichzeitig erstellt, da sie unabhängig sind. Mit terraform graph kannst du den kompletten Graph visualisieren.

7) Providers: Cloud-Unterstützung

Terraforms wahre Stärke ist die Provider-Bibliothek: hunderte Plugins für verschiedene Cloud-Anbieter und Services. Hier die wichtigsten:

Terraform-Provider Auswahl

AWS

Amazon Cloud

Azure

Microsoft Cloud

GCP

Google Cloud

Kubernetes

K8s-Ressourcen

Helm

K8s-Pakete

Docker

Container

GitHub

Repos, Teams

Hetzner Cloud

Beliebt in DE

DigitalOcean

Indie-Cloud

Cloudflare

DNS, CDN

Datadog

Monitoring

PostgreSQL

DB-Setup

Du kannst mehrere Provider in einer Konfig kombinieren: AWS-Server erstellen, Cloudflare-DNS konfigurieren, GitHub-Repo anlegen, Datadog-Monitoring einrichten – alles in einer terraform apply. So baust du komplette Plattformen aus einem Guss.

8) Modules: Wiederverwendung

Wie Ansible-Roles bietet Terraform Modules – wiederverwendbare Konfig-Bausteine. Statt eine Webapp-Infrastruktur immer wieder zu schreiben, machst du daraus ein Module und nutzt es mehrfach:

main.tfHCL

1# Eigenes Module aus lokalem Verzeichnis
2module "webapp_staging" {
3  source      = "./modules/webapp"
4  environment = "staging"
5  instance_count = 2
6}
7
8module "webapp_production" {
9  source      = "./modules/webapp"
10  environment = "production"
11  instance_count = 10
12}
13
14# Module aus Terraform Registry
15module "vpc" {
16  source  = "terraform-aws-modules/vpc/aws"
17  version = "5.0.0"
18  cidr    = "10.0.0.0/16"
19}

Die Terraform Registry (registry.terraform.io) ist wie ein App-Store für Module – tausende geprüfte Module für AWS-VPC, EKS-Cluster, RDS-Datenbanken, Azure-Setups, GCP-Komponenten. Die meisten von HashiCorp oder den Cloud-Anbietern selbst.

9) State-Backends

Per Default liegt die State-Datei lokal auf deiner Festplatte. Schlecht für Teams: jeder hätte einen eigenen State, Konflikte vorprogrammiert. Lösung: Remote Backends – State liegt zentral:

backend.tfHCL

1terraform {
backend "s3" {
  bucket         = "my-tf-state-bucket"
  key            = "prod/terraform.tfstate"
  region         = "eu-central-1"
  dynamodb_table = "terraform-locks"  # für Locking
  encrypt        = true
}
9}

State liegt in S3, DynamoDB sorgt für Locking (verhindert dass zwei Personen gleichzeitig apply machen). Alternative Backends: Terraform Cloud (managed Service von HashiCorp), Azure Storage, GCS, Consul, eigene HTTP-Backends. Für Teams unbedingt verwenden – nicht in Git committen!

10) Terraform vs. Ansible

Häufige Frage: wann nehme ich was? Die Kurzantwort: beide – sie ergänzen sich.

Aspekt	Terraform	Ansible
Fokus	Infrastruktur (Server, Netzwerk, DB)	Configuration (Pakete, Files, Services)
Modell	Deklarativ („was")	Prozedural („wie")
State	Mit State-Datei	Stateless
Sprache	HCL	YAML
Architektur	API-Aufrufe an Cloud-APIs	SSH zu Servern
Lifecycle	Provisionierung + Lifecycle	Konfiguration nach Provisionierung

Typische Workflow-Kombination: Terraform erstellt die EC2-Instanzen, Netzwerk, Datenbank. Dann übernimmt Ansible und installiert Software, kopiert Configs, startet Services. Beide Tools werden in CI/CD-Pipelines orchestriert.

11) Best Practices

Was du beachten solltest in produktiven Terraform-Projekten:

State niemals in Git: enthält Secrets! Immer Remote Backend mit Verschlüsselung
State-Locking: DynamoDB (AWS), Blob Lease (Azure), GCS Lock (GCP)
Verschiedene Workspaces für dev/staging/prod: getrennte States
Variablen für alles: keine hardcoded Werte, alles parametrisierbar
terraform fmt: automatische Formatierung, vor jedem Commit
terraform validate: Syntax-Check
tflint und checkov: Linter und Security-Scanner
Modules für Wiederverwendung: vor allem für identische Patterns (Webapp, DB-Cluster)
plan vor apply – immer reviewen was passieren würde
Code-Reviews für Terraform-Code wie für jeden anderen Code
Versionspinning: required_version = "~> 1.5" verhindert Surprises
Secrets nicht in tfvars: lieber AWS Secrets Manager, Vault, oder Variables aus Umgebungs-Variablen

12) Terraform in CI/CD

Wie Ansible wird Terraform oft in CI/CD-Pipelines integriert. Klassisches Muster:

PR opened: terraform plan läuft, Ergebnis als Kommentar im PR
PR merged: terraform apply -auto-approve wendet Änderungen an
Bei Fehler: Alarmierung, ggf. Rollback

Tools wie Atlantis oder Terraform Cloud automatisieren diesen Workflow. Bei größeren Setups Standard – Infrastructure-Änderungen gehen durch denselben Review-Prozess wie Code-Änderungen.

13) OpenTofu: der Open-Source-Fork

Kurz erwähnt: HashiCorp hat 2023 Terraforms Lizenz von Open Source auf eine restriktivere Business-Source-Lizenz 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. Eine Bewegung die Beachtung verdient, gerade in Europa wo Open-Source-Compliance wichtig ist.

Zusammenfassung

Terraform ist das führende Tool für Infrastructure as Code (IaC). Du beschreibst Cloud-Infrastruktur in HCL (HashiCorp Configuration Language), Terraform setzt es um. Workflow: init (Provider laden) → plan (Vorschau) → apply (Ausführen) → destroy (Aufräumen). State ist Terraforms Gedächtnis – Vergleich zwischen Konfig und Realität. Variables und Outputs für Parametrisierung. Resources sind die Bausteine (EC2, S3, RDS, ...), Providers die Cloud-Plugins (AWS, Azure, GCP, hunderte mehr). Modules für Wiederverwendung – Registry mit fertigen Modulen. Remote State Backends (S3+DynamoDB) für Teams – mit Locking. Plan-vor-Apply ist Pflicht. Ergänzt sich gut mit Ansible: Terraform provisioniert Infra, Ansible konfiguriert sie. OpenTofu ist der Open-Source-Fork seit Lizenzänderung. In CI/CD wichtig – Infrastructure-Änderungen via PR und Pipeline.