Dieser Artikel begleitet dich auf dem direkten Weg zu praxisnahem Terraform-Wissen. Du lernst, wie du mithilfe von Infrastructure as Code deine Infrastruktur wiederholbar, transparent und versionierbar gestaltest. Anhand klarer Beispiele und motivierender Erklärungen führen wir dich von den Basis-Konzepten bis zur ersten funktionsfähigen AWS-Umgebung. Dabei steht dein Lernerfolg im Mittelpunkt: Jeder Schritt wird verständlich erklärt, du erfährst, warum er wichtig ist, worauf du achten solltest und wie du das Gelernte später in der Praxis einsetzt.

⚠️ Wichtige Hinweise und Voraussetzungen: Dieser Artikel richtet sich an erfahrene Linux-Administratoren, Junior DevOps Engineers und IT-Fachkräfte mit soliden Kenntnissen in Linux und Netzwerken. Wenn du dich im Umgang mit der Kommandozeile sicher fühlst und bereits Cloud-Konzepte wie virtuelle Maschinen, Netzwerke und IAM verstanden hast, bist du hier genau richtig. Terraform-Neulinge sind willkommen, doch Linux-Anfänger sollten zuerst grundlegende Tutorials absolvieren, damit du dich auf das Wesentliche konzentrieren kannst.

Verwendete Symbole und Markierungen

💡 Tipps und Hinweise für effizientere Arbeitsweisen
⚠️ Warnungen und Stolperfallen, die dir Probleme ersparen
🔧 Praktische Beispiele zum direkten Nachvollziehen
❗ Typische Fehlerquellen und deren Lösungen

Was ist Terraform?

Terraform ist ein Open-Source-Werkzeug von HashiCorp, das Infrastructure as Code ermöglicht. Du beschreibst in deklarativen Konfigurationsdateien deine gesamte Infrastruktur – von virtuellen Maschinen über Netzwerke bis hin zu DNS-Einträgen. Terraform übersetzt diese Beschreibungen in API-Aufrufe bei Cloud-Anbietern oder anderen Services und führt sie in der richtigen Reihenfolge aus. So wird jeder Schritt dokumentiert, versioniert und automatisierbar.

Mit Terraform schreibst du nicht mehr manuell in einer Konsole, sondern definierst deinen gewünschten Infrastruktur-Zustand in Textform. Terraform plant dann die notwendigen Änderungen, zeigt dir in einer Vorschau, welche Ressourcen angelegt, geändert oder gelöscht werden, und führt anschließend die Aktionen aus.

Warum solltest du Terraform kennen?

In modernen IT-Teams ist Geschwindigkeit genauso wichtig wie Zuverlässigkeit. Manuelles Einrichten über Web-Oberflächen ist fehleranfällig, zeitintensiv und nicht reproduzierbar. Terraform beseitigt diese Hürden, indem es deine Infrastruktur beschreibbar, testbar und auditierbar macht. Teams profitieren von weniger Überraschungen in der Produktion und mehr Konsistenz, across Development, Staging und Produktionsumgebungen.

Terraform ist darüber hinaus cloud-agnostisch. Mit demselben Ansatz kannst du Ressourcen in AWS, Azure, Google Cloud oder On-Premises verwalten. Die große Zahl an Providern erlaubt dir, nicht nur Cloud-Instanzen, sondern auch DNS-Services, Monitoring-Tools oder sogar GitHub-Repos mit Terraform zu steuern. Das macht Terraform zum universellen Werkzeug in einer heterogenen Infrastrukturwelt.

Ziele dieses Artikels: Am Ende dieses Artikels wirst du in der Lage sein, Terraform-Projekte strukturiert aufzusetzen und die grundlegenden Konzepte zu verstehen. Du beherrschst die HCL-Syntax für realistische Infrastruktur-Szenarien und kannst deine erste AWS-Infrastruktur mit Terraform aufbauen. Praktische Beispiele und motivierende Erklärungen helfen dir dabei, das Gelernte sofort in deinem Alltag anzuwenden. Nach diesem Grundlagen-Artikel bist du bereit für fortgeschrittene Themen wie State Management, Best Practices und komplexe Multi-Cloud-Szenarien.

Bereit, deine Infrastruktur in Code zu verwandeln? Dann steigen wir im nächsten Abschnitt in das Fundament von Infrastructure as Code ein und zeigen dir, wie sich die manuelle Verwaltung von modernen DevOps-Ansätzen unterscheidet.

Infrastructure as Code

Traditionelle vs. moderne Infrastrukturverwaltung

Lass uns ehrlich sein: Wir alle haben schon mal um 2 Uhr nachts versucht, einen Server zu reparieren, den wir vor sechs Monaten „schnell mal“ über die Web-Konsole aufgesetzt haben. Und wir alle haben uns gefragt: „Wie zum Teufel hatte ich das damals konfiguriert?“ Genau hier setzt Infrastructure as Code an und löst fundamental die Probleme, die wir täglich mit traditioneller Infrastrukturverwaltung haben.

Der traditionelle Weg: Klicken, hoffen, vergessen

Wie funktioniert traditionelle Infrastrukturverwaltung?

Du loggst dich in die AWS-Konsole, Azure-Portal oder vSphere-Client ein und klickst durch endlose Menüs. Für eine einfache Webserver-Infrastruktur bedeutet das: EC2-Instanz erstellen, Security Groups konfigurieren, Load Balancer einrichten, RDS-Datenbank aufsetzen, Route 53 für DNS. Jeder Schritt wird manuell ausgeführt, oft mit vielen Klicks und Dropdown-Menüs.

💡 Was passiert dabei in der Praxis? Du machst einen Screenshot von den wichtigsten Einstellungen (wenn du daran denkst), schreibst dir vielleicht ein paar Notizen in ein Wiki oder eine Textdatei, und hoffst, dass du beim nächsten Mal noch weißt, was du gemacht hast. Often wird auch gar nicht dokumentiert – "das mache ich später" ist der Klassiker.

🔧 Praktisches Beispiel:

Du richtest eine Staging-Umgebung für dein Team ein. Das bedeutet:

┌ In die AWS-Konsole einloggen
├ VPC erstellen: Name eingeben, CIDR-Block auswählen, DNS-Auflösung aktivieren
├ Subnets erstellen: Public-Subnet 10.0.1.0/24, Private-Subnet 10.0.2.0/24
├ Internet Gateway erstellen und an VPC anhängen
├ Route Tables konfigurieren
├ Security Groups definieren: Web-Traffic auf Port 80/443, SSH auf Port 22
├ EC2-Instanz starten: AMI auswählen, Instance-Type festlegen, Key-Pair zuweisen
├ Load Balancer konfigurieren: Application Load Balancer, Target Groups, Health Checks
└ RDS-Instanz erstellen: Engine auswählen, Instance-Class, Storage, Backup-Einstellungen

Warum ist das problematisch? Nach drei Stunden Klickerei hast du eine funktionierende Umgebung. Aber was passiert, wenn dein Kollege eine identische Entwicklungsumgebung braucht? Er muss jeden Schritt wiederholen, und garantiert macht er dabei andere Einstellungen. Das Ergebnis: Umgebungen, die sich subtil unterscheiden und zu mysteriösen Fehlern führen.

Traditioneller Workflow:

┌ Tag 1: Klicken, konfigurieren, testen ✓
├ Tag 30: "Wie hatte ich das nochmal gemacht?" ❌
├ Tag 60: "Kollege braucht dasselbe" → 3 Stunden Klickarbeit ❌
└ Tag 90: "Backup-Region aufbauen" → 6 Stunden Klickarbeit ❌

⚠️ Typische Stolperfallen der traditionellen Herangehensweise:

┌ Schneeflocken-Server: Jeder Server ist einzigartig und nicht reproduzierbar
├ Undokumentierte Änderungen: Wer hat wann was geändert? Keine Ahnung!
├ Inkonsistente Umgebungen: Dev, Staging und Prod sind subtil verschieden
├ Lange Wiederherstellungszeiten: Bei Ausfällen muss alles manuell neu gebaut werden
└ Wissenssilos: Nur eine Person weiß, wie die Infrastruktur funktioniert

Der moderne Weg: Code schreiben, versionieren, automatisieren

Wie funktioniert Infrastructure as Code?

Du beschreibst deine gewünschte Infrastruktur in Textdateien. Diese Dateien enthalten alle Informationen über deine Server, Netzwerke, Datenbanken und andere Ressourcen. Ein Tool wie Terraform liest diese Dateien, vergleicht sie mit dem aktuellen Zustand und führt automatisch die notwendigen Änderungen durch.

💡 Der entscheidende Unterschied: Du beschreibst das Was, nicht das Wie. Statt "Gehe zu EC2, klicke auf Launch Instance, wähle Ubuntu…" schreibst du "Ich möchte eine Ubuntu-Instanz mit 2 GB RAM in der us-west-2 Region".

🔧 Dasselbe Beispiel mit Infrastructure as Code:

# VPC erstellen
resource "aws_vpc" "main" {
  cidr_block           = "10.0.0.0/16"
  enable_dns_hostnames = true
  enable_dns_support   = true
  
  tags = {
    Name = "staging-vpc"
  }
}

# Public Subnet
resource "aws_subnet" "public" {
  vpc_id                  = aws_vpc.main.id
  cidr_block              = "10.0.1.0/24"
  availability_zone       = "us-west-2a"
  map_public_ip_on_launch = true
  
  tags = {
    Name = "staging-public-subnet"
  }
}

# VPC erstellen
resource "aws_vpc" "main" {
  cidr_block           = "10.0.0.0/16"
  enable_dns_hostnames = true
  enable_dns_support   = true
  
  tags = {
    Name = "staging-vpc"
  }
}

# Public Subnet
resource "aws_subnet" "public" {
  vpc_id                  = aws_vpc.main.id
  cidr_block              = "10.0.1.0/24"
  availability_zone       = "us-west-2a"
  map_public_ip_on_launch = true
  
  tags = {
    Name = "staging-public-subnet"
  }
}

❗Was passiert hier? Du schreibst einmal diese Konfiguration, commitest sie in Git, und jeder kann mit einem einzigen Befehl terraform apply eine identische Umgebung erstellen. Die Infrastruktur wird exakt so gebaut, wie du sie beschrieben hast.

IaC-Workflow:

┌ Tag 1: Code schreiben, testen, committen ✓
├ Tag 30: Git-History anschauen → sofort verstehen ✓
├ Tag 60: Kollege führt `terraform apply` aus → 5 Minuten ✓
└ Tag 90: Backup-Region → Variable ändern → 10 Minuten ✓

💡 Die fundamentalen Vorteile:

┌ Deklarativ: Du sagst, was du willst, nicht wie du es bekommst
├ Versioniert: Jede Änderung wird in Git getrackt
├ Reproduzierbar: Identische Umgebungen garantiert
├ Testbar: Infrastruktur-Code kann wie Application-Code getestet werden
└ Dokumentiert: Der Code ist die Dokumentation

Warum ist dieser Paradigmenwechsel so wichtig?

Speed: Neue Umgebungen entstehen in Minuten statt Stunden. Dein Team kann sich auf die Anwendungsentwicklung konzentrieren, statt Zeit mit repetitiver Infrastruktur-Arbeit zu verschwenden.

Consistency: Alle Umgebungen werden aus demselben Code erstellt. Development, Staging und Production sind garantiert identisch konfiguriert. Das eliminiert die berüchtigten „Works on my machine“-Probleme.

Auditability: Du siehst in Git, wer wann welche Infrastruktur-Änderung gemacht hat. Bei Problemen kannst du sofort zur vorherigen Version zurückkehren.

🔧 Praktisches Beispiel für den Paradigmenwechsel:

┌ Traditionell: "Kannst du mir zeigen, wie du den Load Balancer konfiguriert hast?"
└ Modern: "Schau dir die Datei `load-balancer.tf` an, da steht alles drin."

⚠️ Wichtige Erkenntnis: Der Wechsel zu IaC ist nicht nur ein technisches Upgrade, sondern ein kultureller Wandel. Teams arbeiten kollaborativer, Änderungen werden reviewt wie Code, und Infrastruktur wird zum Teil des Entwicklungsprozesses.

Bereit für die konkreten Vorteile? Jetzt kennst du den fundamentalen Unterschied zwischen alter und neuer Infrastrukturverwaltung. Schauen wir uns an, wie sich diese theoretischen Konzepte in deinem Arbeitsalltag auszahlen.

Vorteile von IaC in der Praxis

Jetzt wo du den grundlegenden Unterschied zwischen traditioneller und moderner Infrastrukturverwaltung verstehst, schauen wir uns die konkreten Vorteile an, die Infrastructure as Code in deinem Arbeitsalltag bringt. Diese Vorteile sind nicht nur theoretische Konzepte, sondern lösen echte Probleme, mit denen du als Linux-Administrator oder DevOps-Engineer täglich konfrontiert bist.

Reproduzierbarkeit: Identische Umgebungen garantiert

💡 Warum ist das so wichtig? Du kennst das Problem: Deine Anwendung funktioniert perfekt in der Entwicklungsumgebung, aber in der Produktion treten mysteriöse Fehler auf. Often liegt das an subtilen Unterschieden in der Infrastruktur-Konfiguration – andere Betriebssystem-Versionen, verschiedene Netzwerk-Einstellungen oder abweichende Security-Group-Regeln.

🔧 Praktisches Beispiel:

┌ Development: Schnell mal eine t2.micro-Instanz mit MySQL 5.7 aufsetzen
├ Staging: t2.small-Instanz mit MySQL 8.0 (weil das gerade verfügbar war)
└ Production: t3.medium-Instanz mit MySQL 8.0 und RDS Multi-AZ

❗Resultat: Drei verschiedene Umgebungen, drei verschiedene Problemquellen.

Mit Infrastructure as Code definierst du einmal die gewünschte Konfiguration:

resource "aws_db_instance" "main" {
  engine         = "mysql"
  engine_version = "8.0"
  instance_class = var.db_instance_class
  allocated_storage = var.db_storage
  
  db_name  = var.db_name
  username = var.db_username
  password = var.db_password
  
  vpc_security_group_ids = [aws_security_group.db.id]
  db_subnet_group_name   = aws_db_subnet_group.main.name
  
  backup_retention_period = var.backup_retention
  backup_window          = "03:00-04:00"
  
  tags = {
    Name = "${var.environment}-database"
  }
}

resource "aws_db_instance" "main" {
  engine         = "mysql"
  engine_version = "8.0"
  instance_class = var.db_instance_class
  allocated_storage = var.db_storage
  
  db_name  = var.db_name
  username = var.db_username
  password = var.db_password
  
  vpc_security_group_ids = [aws_security_group.db.id]
  db_subnet_group_name   = aws_db_subnet_group.main.name
  
  backup_retention_period = var.backup_retention
  backup_window          = "03:00-04:00"
  
  tags = {
    Name = "${var.environment}-database"
  }
}

Der Unterschied: Durch Variablen (var.db_instance_class) kannst du die Umgebungen in der Größe anpassen, aber die grundlegende Konfiguration bleibt identisch. Development bekommt eine kleine Instanz, Production eine größere – aber beide verwenden dieselbe MySQL-Version, dieselben Backup-Einstellungen und dieselben Security-Konfigurationen.

💡 Warum funktioniert das so gut? Terraform erstellt einen Execution Plan, der deterministisch ist. Das bedeutet, dass derselbe Code immer zur selben Infrastruktur führt, egal wer ihn ausführt oder wann er ausgeführt wird.

Versionierung: Deine Infrastruktur in Git

Was bedeutet Versionierung für Infrastruktur? Deine Terraform-Dateien werden genauso in Git verwaltet wie dein Anwendungscode. Jede Änderung wird getrackt, du siehst, wer wann was geändert hat, und kannst bei Problemen einfach zur vorherigen Version zurückkehren.

Warum ist das revolutionär? Stell dir vor, du änderst die Security-Group-Regeln für deine Produktionsumgebung und plötzlich können sich Benutzer nicht mehr einloggen. Mit traditioneller Verwaltung würdest du panisch durch die AWS-Konsole klicken und versuchen, dich daran zu erinnern, welche Einstellungen du geändert hast.

🔧 Praktisches Beispiel mit Git-Workflow:

# Aktuelle Änderungen anzeigen
git log --oneline -10
a1b2c3d Update security group rules for web tier
d4e5f6g Add new RDS instance for analytics
g7h8i9j Update ALB target group health check

# Problem in der Produktion? Zurück zur vorherigen Version
git revert a1b2c3d
terraform plan   # Zeigt, was rückgängig gemacht wird
terraform apply  # Führt das Rollback aus

# Aktuelle Änderungen anzeigen
git log --oneline -10
a1b2c3d Update security group rules for web tier
d4e5f6g Add new RDS instance for analytics
g7h8i9j Update ALB target group health check

# Problem in der Produktion? Zurück zur vorherigen Version
git revert a1b2c3d
terraform plan   # Zeigt, was rückgängig gemacht wird
terraform apply  # Führt das Rollback aus

Der Workflow sieht so aus:

┌ Du änderst die Terraform-Konfiguration
├ Du commitest die Änderung mit einer aussagekräftigen Commit-Message
├ Ein Kollege reviewt deine Änderung (Pull Request)
├ Nach dem Merge wird die Infrastruktur automatisch aktualisiert
└ Bei Problemen: git revert und die Infrastruktur ist wieder im alten Zustand

⚠️ Wichtiger Hinweis: Versionierung funktioniert nur, wenn alle Infrastruktur-Änderungen über Code gemacht werden. Manuelle Änderungen in der Konsole umgehen das Versionssystem und können zu Problemen führen.

Dokumentation: Der Code ist die Wahrheit

Was ist das Problem mit traditioneller Dokumentation? Wiki-Seiten werden nie aktualisiert, Confluence-Dokumente sind veraltet, und die Notizen in der Textdatei sind kryptisch. Die Realität weicht immer von der Dokumentation ab.

Wie löst IaC das? Der Code ist die Dokumentation. Wenn du wissen willst, wie deine Infrastruktur konfiguriert ist, schaust du dir die Terraform-Dateien an. Sie sind immer aktuell, weil sie die Infrastruktur definieren.

🔧 Praktisches Beispiel:

# Web-Tier Security Group
resource "aws_security_group" "web" {
  name_prefix = "${var.environment}-web-"
  vpc_id      = aws_vpc.main.id

  # HTTP-Traffic von überall
  ingress {
    from_port   = 80
    to_port     = 80
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }

  # HTTPS-Traffic von überall
  ingress {
    from_port   = 443
    to_port     = 443
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }

  # SSH nur aus dem Management-Subnet
  ingress {
    from_port   = 22
    to_port     = 22
    protocol    = "tcp"
    cidr_blocks = [aws_subnet.management.cidr_block]
  }

  # Ausgehender Traffic komplett erlaubt
  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }

  tags = {
    Name = "${var.environment}-web-sg"
    Tier = "web"
  }
}

# Web-Tier Security Group
resource "aws_security_group" "web" {
  name_prefix = "${var.environment}-web-"
  vpc_id      = aws_vpc.main.id

  # HTTP-Traffic von überall
  ingress {
    from_port   = 80
    to_port     = 80
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }

  # HTTPS-Traffic von überall
  ingress {
    from_port   = 443
    to_port     = 443
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }

  # SSH nur aus dem Management-Subnet
  ingress {
    from_port   = 22
    to_port     = 22
    protocol    = "tcp"
    cidr_blocks = [aws_subnet.management.cidr_block]
  }

  # Ausgehender Traffic komplett erlaubt
  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }

  tags = {
    Name = "${var.environment}-web-sg"
    Tier = "web"
  }
}

Warum ist das so viel besser?

Dieser Code-Block zeigt dir auf einen Blick:

┌ Welche Ports geöffnet sind und warum
├ Woher der Traffic kommen darf
├ Wie die Ressourcen benannt und getaggt sind
└ Wie sie mit anderen Ressourcen verbunden sind

💡 Zusätzlicher Vorteil: Moderne IDEs können Terraform-Code analysieren und dir sofort zeigen, welche Ressourcen voneinander abhängen. Das ist besser als jede traditionelle Dokumentation.

Automatisierung und CI/CD-Integration

Was bedeutet Infrastruktur in CI/CD? Deine Infrastruktur-Änderungen durchlaufen denselben Qualitätssicherungsprozess wie dein Anwendungscode. Pull Requests, Code Reviews, automatische Tests und stufenweise Deployments werden zur Norm.

Warum ist das so wertvoll? Infrastruktur-Änderungen sind often riskanter als Code-Änderungen. Ein Fehler in der Netzwerk-Konfiguration kann deine gesamte Anwendung lahmlegen. Mit CI/CD-Integration kannst du diese Risiken minimieren.

🔧 Praktisches Beispiel einer GitLab CI Pipeline:

stages:
  - validate
  - plan
  - apply

terraform-validate:
  stage: validate
  script:
    - terraform init
    - terraform validate
    - terraform fmt -check

terraform-plan:
  stage: plan
  script:
    - terraform plan -out=tfplan
  artifacts:
    paths:
      - tfplan

terraform-apply:
  stage: apply
  script:
    - terraform apply tfplan
  when: manual
  only:
    - main

stages:
  - validate
  - plan
  - apply

terraform-validate:
  stage: validate
  script:
    - terraform init
    - terraform validate
    - terraform fmt -check

terraform-plan:
  stage: plan
  script:
    - terraform plan -out=tfplan
  artifacts:
    paths:
      - tfplan

terraform-apply:
  stage: apply
  script:
    - terraform apply tfplan
  when: manual
  only:
    - main

Der Workflow:

┌ Du pushst deine Terraform-Änderungen
├ Die Pipeline validiert die Syntax automatisch
├ Ein Plan wird erstellt und als Artifact gespeichert
└ Ein Maintainer reviewt den Plan und löst das Deployment manuell aus

⚠️ Sicherheitsaspekt: Automatische Deployments in die Produktion sind möglich, aber sollten gut durchdacht sein. Often ist ein manueller Approval-Schritt für kritische Umgebungen sinnvoll.

Kostenkontrolle: Sichtbarkeit und Aufräumen

Warum ist Kostenkontrolle mit IaC einfacher? Mit Terraform siehst du auf einen Blick, welche Ressourcen provisioniert sind. Du kannst Entwicklungsumgebungen am Feierabend herunterfahren und am nächsten Morgen wieder hochfahren.

🔧 Praktisches Beispiel:

# Entwicklungsumgebung am Feierabend herunterfahren
terraform destroy -target=aws_instance.dev_servers

# Am nächsten Morgen wieder hochfahren
terraform apply -target=aws_instance.dev_servers

# Entwicklungsumgebung am Feierabend herunterfahren
terraform destroy -target=aws_instance.dev_servers

# Am nächsten Morgen wieder hochfahren
terraform apply -target=aws_instance.dev_servers

Erweiterte Kostenkontrolle:

┌ Terraform kann mit Tools wie Infracost integriert werden, um Kosten vor dem Deployment zu schätzen
├ Automatische Cleanup-Jobs können ungenutzte Ressourcen identifizieren
└ Resource-Tagging wird konsistent durchgesetzt

💡 Praxis-Tipp: Verwende Terraform-Workspaces für verschiedene Umgebungen. So kannst du gezielt einzelne Umgebungen verwalten, ohne andere zu beeinflussen.

Du siehst die Vorteile von Infrastructure as Code. Aber welches Tool sollst du wählen? Lass uns Terraform mit seinen wichtigsten Konkurrenten vergleichen.

Terraform vs. andere IaC-Tools

Ansible, CloudFormation, Pulumi

Du fragst dich sicher, warum ausgerechnet Terraform und nicht eines der anderen verfügbaren Infrastructure as Code Tools. Die Landschaft ist groß, und jedes Tool hat seine Berechtigung. Lass uns die wichtigsten Alternativen ehrlich vergleichen, damit du verstehst, wo Terraform glänzt und wo andere Tools möglicherweise besser geeignet sind.

Terraform vs. Ansible: Infrastructure vs. Configuration Management

Was ist der grundlegende Unterschied? Terraform und Ansible lösen verschiedene Probleme: Terraform erstellt und verwaltet Infrastruktur (Server, Netzwerke, Datenbanken), während Ansible diese Infrastruktur konfiguriert (Software installieren, Services starten, Configs anpassen).

Typische Aufgabenteilung in der Praxis:

┌ Terraform erstellt:
├ AWS VPC und Subnets
├ EC2-Instanzen
├ RDS-Datenbank
├ Load Balancer
└ EC2-Instanzen

┌ Ansible konfiguriert:
├ Docker Installation
├ Application Deployment
├ SSL-Zertifikate
├ Monitoring Agents
└ Backup Scripts

Warum ergänzen sich beide Tools perfekt? In der Praxis verwendest du often beide: Terraform für die Infrastruktur-Bereitstellung, Ansible für die Konfiguration danach. Terraform kann sogar Ansible-Playbooks nach der Ressourcenerstellung ausführen.

🔧 Praktisches Beispiel – Integration:

resource "aws_instance" "web" {
  ami           = "ami-0c55b159cbfafe1d0"
  instance_type = "t3.micro"
  
  provisioner "remote-exec" {
    inline = [
      "sudo apt update",
      "sudo apt install -y python3"
    ]
  }
  
  provisioner "local-exec" {
    command = "ansible-playbook -i '${self.public_ip},' webserver.yml"
  }
}

resource "aws_instance" "web" {
  ami           = "ami-0c55b159cbfafe1d0"
  instance_type = "t3.micro"
  
  provisioner "remote-exec" {
    inline = [
      "sudo apt update",
      "sudo apt install -y python3"
    ]
  }
  
  provisioner "local-exec" {
    command = "ansible-playbook -i '${self.public_ip},' webserver.yml"
  }
}

Wann solltest du was verwenden?

💡 Praxis-Tipp: Viele Teams verwenden einen "Terraform-first"-Ansatz für die Infrastruktur und nutzen Ansible nur für komplexe Konfigurationsaufgaben, die Terraform nicht elegant abdeckt.

⚠️ Wichtige Abgrenzung: Verwende Terraform nicht für Konfigurationsmanagement und Ansible nicht für Infrastruktur-Bereitstellung. Jedes Tool in seinem Spezialgebiet ist deutlich effektiver.

Terraform vs. CloudFormation: Multi-Cloud vs. AWS-Native

Was ist CloudFormation? AWS CloudFormation ist Amazon’s natives Infrastructure as Code Tool. Es ist tief in die AWS-Welt integriert und unterstützt praktisch jeden AWS-Service sofort nach dessen Veröffentlichung.

Performance-Vergleich:

🔧 Syntax-Vergleich:

CloudFormation (YAML):

Resources:
  WebServer:
    Type: AWS::EC2::Instance
    Properties:
      ImageId: ami-0c55b159cbfafe1d0
      InstanceType: t3.micro
      KeyName: !Ref KeyName
      SecurityGroups:
        - !Ref WebServerSecurityGroup
      Tags:
        - Key: Name
          Value: WebServer

Resources:
  WebServer:
    Type: AWS::EC2::Instance
    Properties:
      ImageId: ami-0c55b159cbfafe1d0
      InstanceType: t3.micro
      KeyName: !Ref KeyName
      SecurityGroups:
        - !Ref WebServerSecurityGroup
      Tags:
        - Key: Name
          Value: WebServer

Terraform (HCL):

resource "aws_instance" "web" {
  ami           = "ami-0c55b159cbfafe1d0"
  instance_type = "t3.micro"
  key_name      = var.key_name
  security_groups = [aws_security_group.web.name]
  
  tags = {
    Name = "WebServer"
  }
}

resource "aws_instance" "web" {
  ami           = "ami-0c55b159cbfafe1d0"
  instance_type = "t3.micro"
  key_name      = var.key_name
  security_groups = [aws_security_group.web.name]
  
  tags = {
    Name = "WebServer"
  }
}

Multi-Cloud-Beispiel mit Terraform:

# AWS-Ressourcen
resource "aws_instance" "web" {
  provider = aws.us_east_1
  ami           = "ami-0c55b159cbfafe1d0"
  instance_type = "t3.micro"
}

# Azure-Ressourcen
resource "azurerm_virtual_machine" "web" {
  provider = azurerm.west_europe
  name     = "web-vm"
  location = "West Europe"
}

# DNS bei Cloudflare
resource "cloudflare_record" "web" {
  zone_id = var.cloudflare_zone_id
  name    = "web"
  value   = aws_instance.web.public_ip
  type    = "A"
}

# AWS-Ressourcen
resource "aws_instance" "web" {
  provider = aws.us_east_1
  ami           = "ami-0c55b159cbfafe1d0"
  instance_type = "t3.micro"
}

# Azure-Ressourcen
resource "azurerm_virtual_machine" "web" {
  provider = azurerm.west_europe
  name     = "web-vm"
  location = "West Europe"
}

# DNS bei Cloudflare
resource "cloudflare_record" "web" {
  zone_id = var.cloudflare_zone_id
  name    = "web"
  value   = aws_instance.web.public_ip
  type    = "A"
}

Entscheidungsmatrix:

💡 Migrationsstrategie: Viele Unternehmen starten mit CloudFormation, wechseln aber zu Terraform, sobald sie zusätzliche Cloud-Provider oder Services außerhalb von AWS einsetzen. Der Wechsel ist möglich, aber aufwendig.

Terraform vs. Pulumi: HCL vs. echte Programmiersprachen

Was macht Pulumi anders? Pulumi verwendet echte Programmiersprachen wie Python, TypeScript, Go oder C# für Infrastructure as Code. Du schreibst deine Infrastruktur in der Sprache, die du bereits kennst.

Entwicklungserfahrung:

🔧 Praktisches Beispiel – Komplexe Logik:

import pulumi_aws as aws

# Dynamisch Subnets für alle AZs erstellen
azs = aws.get_availability_zones()
subnets = []

for i, az in enumerate(azs.names):
    if i < 3:  # Nur erste 3 AZs
        subnet = aws.ec2.Subnet(f"subnet-{i}",
            vpc_id=vpc.id,
            cidr_block=f"10.0.{i+1}.0/24",
            availability_zone=az,
            tags={
                "Name": f"subnet-{az}",
                "Tier": "public" if i % 2 == 0 else "private"
            }
        )
        subnets.append(subnet)

# Conditional Logic für Environment
if pulumi.get_stack() == "production":
    instance_type = "t3.large"
    instance_count = 3
else:
    instance_type = "t3.micro"
    instance_count = 1

import pulumi_aws as aws

# Dynamisch Subnets für alle AZs erstellen
azs = aws.get_availability_zones()
subnets = []

for i, az in enumerate(azs.names):
    if i < 3:  # Nur erste 3 AZs
        subnet = aws.ec2.Subnet(f"subnet-{i}",
            vpc_id=vpc.id,
            cidr_block=f"10.0.{i+1}.0/24",
            availability_zone=az,
            tags={
                "Name": f"subnet-{az}",
                "Tier": "public" if i % 2 == 0 else "private"
            }
        )
        subnets.append(subnet)

# Conditional Logic für Environment
if pulumi.get_stack() == "production":
    instance_type = "t3.large"
    instance_count = 3
else:
    instance_type = "t3.micro"
    instance_count = 1

Terraform HCL:

data "aws_availability_zones" "available" {}

locals {
  azs = slice(data.aws_availability_zones.available.names, 0, 3)
}

resource "aws_subnet" "main" {
  count = length(local.azs)
  
  vpc_id            = aws_vpc.main.id
  cidr_block        = "10.0.${count.index + 1}.0/24"
  availability_zone = local.azs[count.index]
  
  tags = {
    Name = "subnet-${local.azs[count.index]}"
    Tier = count.index % 2 == 0 ? "public" : "private"
  }
}

locals {
  instance_config = {
    production = {
      type  = "t3.large"
      count = 3
    }
    staging = {
      type  = "t3.micro"
      count = 1
    }
  }
}

data "aws_availability_zones" "available" {}

locals {
  azs = slice(data.aws_availability_zones.available.names, 0, 3)
}

resource "aws_subnet" "main" {
  count = length(local.azs)
  
  vpc_id            = aws_vpc.main.id
  cidr_block        = "10.0.${count.index + 1}.0/24"
  availability_zone = local.azs[count.index]
  
  tags = {
    Name = "subnet-${local.azs[count.index]}"
    Tier = count.index % 2 == 0 ? "public" : "private"
  }
}

locals {
  instance_config = {
    production = {
      type  = "t3.large"
      count = 3
    }
    staging = {
      type  = "t3.micro"
      count = 1
    }
  }
}

Testing-Vergleich:

Pulumi Unit Test:

import unittest
import pulumi

class TestInfrastructure(unittest.TestCase):
    @pulumi.runtime.test
    def test_vpc_cidr(self):
        def check_cidr(args):
            vpc, = args
            self.assertEqual(vpc.cidr_block, "10.0.0.0/16")
        
        return pulumi.Output.all(vpc).apply(check_cidr)

import unittest
import pulumi

class TestInfrastructure(unittest.TestCase):
    @pulumi.runtime.test
    def test_vpc_cidr(self):
        def check_cidr(args):
            vpc, = args
            self.assertEqual(vpc.cidr_block, "10.0.0.0/16")
        
        return pulumi.Output.all(vpc).apply(check_cidr)

Team-Adoption:

Hybrid-Ansätze: Wann du Tools kombinierst

Warum nicht nur ein Tool? In der Realität nutzen viele Teams eine Kombination von Tools, weil jedes seine Stärken hat.

🔧 Praktisches Beispiel – Terraform + Ansible Pipeline:

# Terraform erstellt die Infrastruktur
resource "aws_instance" "web" {
  count = var.instance_count
  ami           = "ami-0c55b159cbfafe1d0"
  instance_type = "t3.micro"
  
  tags = {
    Name = "web-${count.index}"
  }
}

# Ansible-Inventar generieren
resource "local_file" "ansible_inventory" {
  content = templatefile("inventory.tpl", {
    web_servers = aws_instance.web[*].public_ip
  })
  filename = "ansible/inventory"
}

# Ansible-Playbook ausführen
resource "null_resource" "configure_servers" {
  depends_on = [local_file.ansible_inventory]
  
  provisioner "local-exec" {
    command = "cd ansible && ansible-playbook -i inventory site.yml"
  }
  
  triggers = {
    instance_ids = join(",", aws_instance.web[*].id)
  }
}

# Terraform erstellt die Infrastruktur
resource "aws_instance" "web" {
  count = var.instance_count
  ami           = "ami-0c55b159cbfafe1d0"
  instance_type = "t3.micro"
  
  tags = {
    Name = "web-${count.index}"
  }
}

# Ansible-Inventar generieren
resource "local_file" "ansible_inventory" {
  content = templatefile("inventory.tpl", {
    web_servers = aws_instance.web[*].public_ip
  })
  filename = "ansible/inventory"
}

# Ansible-Playbook ausführen
resource "null_resource" "configure_servers" {
  depends_on = [local_file.ansible_inventory]
  
  provisioner "local-exec" {
    command = "cd ansible && ansible-playbook -i inventory site.yml"
  }
  
  triggers = {
    instance_ids = join(",", aws_instance.web[*].id)
  }
}

Terraform’s Alleinstellungsmerkmale

Warum ist Terraform often die beste Wahl?

🔧 Plan-Funktion Beispiel:

terraform plan

Terraform will perform the following actions:

  # aws_instance.web will be created
  + resource "aws_instance" "web" {
      + ami           = "ami-0c55b159cbfafe1d0"
      + instance_type = "t3.micro"
      + key_name      = "my-key"
      + public_ip     = (known after apply)
      + tags          = {
          + "Name" = "web-server"
        }
    }

  # aws_security_group.web will be modified
  ~ resource "aws_security_group" "web" {
        id = "sg-12345678"
      ~ ingress {
          + from_port = 443
          + to_port   = 443
            protocol  = "tcp"
            cidr_blocks = ["0.0.0.0/0"]
        }
    }

Plan: 1 to add, 1 to change, 0 to destroy.

terraform plan

Terraform will perform the following actions:

  # aws_instance.web will be created
  + resource "aws_instance" "web" {
      + ami           = "ami-0c55b159cbfafe1d0"
      + instance_type = "t3.micro"
      + key_name      = "my-key"
      + public_ip     = (known after apply)
      + tags          = {
          + "Name" = "web-server"
        }
    }

  # aws_security_group.web will be modified
  ~ resource "aws_security_group" "web" {
        id = "sg-12345678"
      ~ ingress {
          + from_port = 443
          + to_port   = 443
            protocol  = "tcp"
            cidr_blocks = ["0.0.0.0/0"]
        }
    }

Plan: 1 to add, 1 to change, 0 to destroy.

Konkrete Entscheidungshilfen

Entscheidungsmatrix für Tool-Auswahl:

Legende: ✅✅ = Excellent, ✅ = Good, ⚠️ = Acceptable, ❌ = Poor, 💰 = Paid

Konkrete Empfehlungen:

💡 Fazit: Terraform ist nicht immer die beste Wahl, aber often der beste Kompromiss. Es ist mächtig genug für komplexe Infrastrukturen, aber einfach genug für Teams ohne tiefe Programmierkenntnisse. Die Kombination aus Flexibilität, Community-Support und bewährten Patterns macht es zur sicheren Wahl für die meisten Infrastruktur-Projekte.

⚠️ Wichtiger Hinweis: Unabhängig von der Toolwahl ist die wichtigste Entscheidung, überhaupt mit Infrastructure as Code zu beginnen. Der Wechsel von manueller zu automatisierter Infrastruktur-Verwaltung bringt mehr Vorteile als die Wahl zwischen verschiedenen IaC-Tools.

Jetzt kennst du die Tool-Landschaft und weißt, warum Terraform für die meisten Teams die richtige Wahl ist. Zeit, dass wir unter die Haube schauen und verstehen, wie Terraform wirklich funktioniert.

Terraform Konzepte und Architektur

Kernkomponenten

Terraform besteht aus vier zentralen Komponenten, die zusammenarbeiten, um deine Infrastruktur zu verwalten. Jede Komponente hat eine spezifische Rolle, und das Verständnis ihrer Zusammenarbeit ist entscheidend für den erfolgreichen Einsatz von Terraform. Lass uns jede Komponente im Detail durchgehen.

Provider und ihre Rolle

Was sind Provider? Provider sind Plugins, die Terraform mit verschiedenen APIs verbinden. Sie übersetzen deine HCL-Konfiguration in API-Aufrufe an Cloud-Anbieter, SaaS-Services oder lokale Systeme. Ohne Provider wäre Terraform nur ein Parser für Konfigurationsdateien.

Warum sind Provider so wichtig? Provider sind das Herzstück von Terraform’s Flexibilität. Sie ermöglichen es einem einzigen Tool, mit tausenden verschiedenen Services zu kommunizieren. Jeder Provider weiß, wie er mit seinem spezifischen Service kommunizieren muss.

Provider-Authentifizierung im Detail:

AWS Provider – Authentifizierungsmethoden:

# Methode 1: Direkte Konfiguration (nicht empfohlen für Produktion)
provider "aws" {
  region     = "us-west-2"
  access_key = "AKIA..."
  secret_key = "..."
}

# Methode 2: Umgebungsvariablen
provider "aws" {
  region = "us-west-2"
  # AWS_ACCESS_KEY_ID und AWS_SECRET_ACCESS_KEY aus Environment
}

# Methode 3: AWS Profile
provider "aws" {
  region  = "us-west-2"
  profile = "default"
}

# Methode 4: IAM Roles (empfohlen für EC2/ECS)
provider "aws" {
  region = "us-west-2"
  # Automatisch von Instance Metadata Service
}

# Methode 5: Assume Role
provider "aws" {
  region = "us-west-2"
  
  assume_role {
    role_arn = "arn:aws:iam::123456789012:role/TerraformRole"
  }
}

# Methode 1: Direkte Konfiguration (nicht empfohlen für Produktion)
provider "aws" {
  region     = "us-west-2"
  access_key = "AKIA..."
  secret_key = "..."
}

# Methode 2: Umgebungsvariablen
provider "aws" {
  region = "us-west-2"
  # AWS_ACCESS_KEY_ID und AWS_SECRET_ACCESS_KEY aus Environment
}

# Methode 3: AWS Profile
provider "aws" {
  region  = "us-west-2"
  profile = "default"
}

# Methode 4: IAM Roles (empfohlen für EC2/ECS)
provider "aws" {
  region = "us-west-2"
  # Automatisch von Instance Metadata Service
}

# Methode 5: Assume Role
provider "aws" {
  region = "us-west-2"
  
  assume_role {
    role_arn = "arn:aws:iam::123456789012:role/TerraformRole"
  }
}

Multi-Provider-Konfiguration:

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
    cloudflare = {
      source  = "cloudflare/cloudflare"
      version = "~> 4.0"
    }
    github = {
      source  = "integrations/github"
      version = "~> 5.0"
    }
  }
}

# Mehrere AWS-Regionen
provider "aws" {
  alias  = "us_east_1"
  region = "us-east-1"
}

provider "aws" {
  alias  = "us_west_2"
  region = "us-west-2"
}

# Cloudflare für DNS
provider "cloudflare" {
  api_token = var.cloudflare_api_token
}

# GitHub für Repository Management
provider "github" {
  token = var.github_token
  owner = var.github_organization
}

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
    cloudflare = {
      source  = "cloudflare/cloudflare"
      version = "~> 4.0"
    }
    github = {
      source  = "integrations/github"
      version = "~> 5.0"
    }
  }
}

# Mehrere AWS-Regionen
provider "aws" {
  alias  = "us_east_1"
  region = "us-east-1"
}

provider "aws" {
  alias  = "us_west_2"
  region = "us-west-2"
}

# Cloudflare für DNS
provider "cloudflare" {
  api_token = var.cloudflare_api_token
}

# GitHub für Repository Management
provider "github" {
  token = var.github_token
  owner = var.github_organization
}

Provider-Performance und Caching:

🔧 Praktisches Beispiel – Provider-Optimierung:

provider "aws" {
  region = "us-west-2"
  
  # Performance-Optimierungen
  max_retries = 3
  
  # Request-Timeouts
  http_timeout = "30s"
  
  # Für große Deployments
  skip_metadata_api_check = true
  skip_region_validation  = true
  
  # Default Tags für alle Ressourcen
  default_tags {
    tags = {
      Environment = var.environment
      Project     = var.project_name
      ManagedBy   = "terraform"
      CreatedAt   = timestamp()
    }
  }
}

provider "aws" {
  region = "us-west-2"
  
  # Performance-Optimierungen
  max_retries = 3
  
  # Request-Timeouts
  http_timeout = "30s"
  
  # Für große Deployments
  skip_metadata_api_check = true
  skip_region_validation  = true
  
  # Default Tags für alle Ressourcen
  default_tags {
    tags = {
      Environment = var.environment
      Project     = var.project_name
      ManagedBy   = "terraform"
      CreatedAt   = timestamp()
    }
  }
}

Provider-Versionierung und Upgrades:

💡 Praxis-Tipp: Verwende immer Versionsconstraints für Provider. ~> 5.0 ist often der beste Kompromiss zwischen Stabilität und Updates.

⚠️ Häufige Provider-Probleme und Lösungen:

Ressourcen (Resources) – Das Herzstück der Infrastruktur

Was sind Ressourcen? Ressourcen sind die eigentlichen Infrastruktur-Objekte, die Terraform verwaltet. Jede Ressource repräsentiert ein spezifisches Objekt in deiner Infrastruktur – eine EC2-Instanz, eine Datenbank, ein DNS-Eintrag.

Warum sind Ressourcen das Herzstück? Ressourcen definieren den gewünschten Zustand deiner Infrastruktur. Terraform vergleicht diesen gewünschten Zustand mit der Realität und führt die notwendigen Änderungen durch.

Ressourcen-Kategorien und ihre Eigenschaften:

Ressourcen-Lifecycle im Detail:

┌───────────────────────────────────────────────────────┐
│                   Resource Lifecycle                  │                                                                                            │																											  │		
├───────────────────────────────────────────────────────┤
│  CREATE → READ → UPDATE → DELETE (CRUD)               │
│     ↓       ↓       ↓        ↓                        │
│   apply   refresh  apply   destroy                    │
│                                                       │
│  Zusätzliche Aktionen:                                │
│  • Import (bestehende Ressourcen übernehmen)          │
│  • Taint (Ressource zum Neuerstellen markieren)       │
│  • Untaint (Taint-Markierung entfernen)               │
│  • Replace (Ressource ersetzen)                       │
└───────────────────────────────────────────────────────┘

┌───────────────────────────────────────────────────────┐
│                   Resource Lifecycle                  │                                                                                            │																											  │		
├───────────────────────────────────────────────────────┤
│  CREATE → READ → UPDATE → DELETE (CRUD)               │
│     ↓       ↓       ↓        ↓                        │
│   apply   refresh  apply   destroy                    │
│                                                       │
│  Zusätzliche Aktionen:                                │
│  • Import (bestehende Ressourcen übernehmen)          │
│  • Taint (Ressource zum Neuerstellen markieren)       │
│  • Untaint (Taint-Markierung entfernen)               │
│  • Replace (Ressource ersetzen)                       │
└───────────────────────────────────────────────────────┘

🔧 Praktisches Beispiel – Komplexe Ressourcen-Konfiguration:

# EC2-Instanz mit erweiterten Eigenschaften
resource "aws_instance" "web" {
  ami           = data.aws_ami.ubuntu.id
  instance_type = var.instance_type
  key_name      = aws_key_pair.deployer.key_name
  
  # Netzwerk-Konfiguration
  vpc_security_group_ids = [
    aws_security_group.web.id,
    aws_security_group.ssh.id
  ]
  subnet_id                   = aws_subnet.public.id
  associate_public_ip_address = true
  
  # Storage-Konfiguration
  root_block_device {
    volume_type           = "gp3"
    volume_size           = 20
    encrypted             = true
    delete_on_termination = true
    
    tags = {
      Name = "root-volume"
    }
  }
  
  # Zusätzliche EBS-Volumes
  ebs_block_device {
    device_name           = "/dev/sdb"
    volume_type           = "gp3"
    volume_size           = 100
    encrypted             = true
    delete_on_termination = false
    
    tags = {
      Name = "data-volume"
    }
  }
  
  # Monitoring
  monitoring = true
  
  # Placement
  availability_zone = data.aws_availability_zones.available.names[0]
  
  # User Data Script
  user_data = base64encode(templatefile("${path.module}/userdata.sh", {
    db_host = aws_db_instance.main.endpoint
    app_env = var.environment
  }))
  
  # Lifecycle-Regeln
  lifecycle {
    create_before_destroy = true
    ignore_changes = [
      ami,  # AMI-Updates ignorieren
      user_data,  # User Data Änderungen ignorieren
    ]
  }
  
  # Detaillierte Tags
  tags = {
    Name        = "${var.project}-web-${var.environment}"
    Environment = var.environment
    Project     = var.project
    Role        = "webserver"
    Backup      = "daily"
    Monitoring  = "enabled"
  }
}

# Security Group mit detaillierten Regeln
resource "aws_security_group" "web" {
  name_prefix = "${var.project}-web-"
  description = "Security group for web servers"
  vpc_id      = aws_vpc.main.id
  
  # HTTP von überall
  ingress {
    description = "HTTP from internet"
    from_port   = 80
    to_port     = 80
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }
  
  # HTTPS von überall
  ingress {
    description = "HTTPS from internet"
    from_port   = 443
    to_port     = 443
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }
  
  # SSH nur von Management-Subnet
  ingress {
    description = "SSH from management"
    from_port   = 22
    to_port     = 22
    protocol    = "tcp"
    cidr_blocks = [aws_subnet.management.cidr_block]
  }
  
  # Application Port von Load Balancer
  ingress {
    description     = "App port from ALB"
    from_port       = 8080
    to_port         = 8080
    protocol        = "tcp"
    security_groups = [aws_security_group.alb.id]
  }
  
  # Ausgehender Traffic
  egress {
    description = "All outbound traffic"
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }
  
  # Lifecycle-Regeln
  lifecycle {
    create_before_destroy = true
  }
  
  tags = {
    Name = "${var.project}-web-sg"
  }
}

# EC2-Instanz mit erweiterten Eigenschaften
resource "aws_instance" "web" {
  ami           = data.aws_ami.ubuntu.id
  instance_type = var.instance_type
  key_name      = aws_key_pair.deployer.key_name
  
  # Netzwerk-Konfiguration
  vpc_security_group_ids = [
    aws_security_group.web.id,
    aws_security_group.ssh.id
  ]
  subnet_id                   = aws_subnet.public.id
  associate_public_ip_address = true
  
  # Storage-Konfiguration
  root_block_device {
    volume_type           = "gp3"
    volume_size           = 20
    encrypted             = true
    delete_on_termination = true
    
    tags = {
      Name = "root-volume"
    }
  }
  
  # Zusätzliche EBS-Volumes
  ebs_block_device {
    device_name           = "/dev/sdb"
    volume_type           = "gp3"
    volume_size           = 100
    encrypted             = true
    delete_on_termination = false
    
    tags = {
      Name = "data-volume"
    }
  }
  
  # Monitoring
  monitoring = true
  
  # Placement
  availability_zone = data.aws_availability_zones.available.names[0]
  
  # User Data Script
  user_data = base64encode(templatefile("${path.module}/userdata.sh", {
    db_host = aws_db_instance.main.endpoint
    app_env = var.environment
  }))
  
  # Lifecycle-Regeln
  lifecycle {
    create_before_destroy = true
    ignore_changes = [
      ami,  # AMI-Updates ignorieren
      user_data,  # User Data Änderungen ignorieren
    ]
  }
  
  # Detaillierte Tags
  tags = {
    Name        = "${var.project}-web-${var.environment}"
    Environment = var.environment
    Project     = var.project
    Role        = "webserver"
    Backup      = "daily"
    Monitoring  = "enabled"
  }
}

# Security Group mit detaillierten Regeln
resource "aws_security_group" "web" {
  name_prefix = "${var.project}-web-"
  description = "Security group for web servers"
  vpc_id      = aws_vpc.main.id
  
  # HTTP von überall
  ingress {
    description = "HTTP from internet"
    from_port   = 80
    to_port     = 80
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }
  
  # HTTPS von überall
  ingress {
    description = "HTTPS from internet"
    from_port   = 443
    to_port     = 443
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }
  
  # SSH nur von Management-Subnet
  ingress {
    description = "SSH from management"
    from_port   = 22
    to_port     = 22
    protocol    = "tcp"
    cidr_blocks = [aws_subnet.management.cidr_block]
  }
  
  # Application Port von Load Balancer
  ingress {
    description     = "App port from ALB"
    from_port       = 8080
    to_port         = 8080
    protocol        = "tcp"
    security_groups = [aws_security_group.alb.id]
  }
  
  # Ausgehender Traffic
  egress {
    description = "All outbound traffic"
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }
  
  # Lifecycle-Regeln
  lifecycle {
    create_before_destroy = true
  }
  
  tags = {
    Name = "${var.project}-web-sg"
  }
}

Resource-Abhängigkeiten und Dependency-Graph:

┌─────────────────────────────────────────────────────────────┐
│                 Dependency Resolution                       │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│   VPC ──────────────────────────────────────────────────┐   │
│    │                                                    │   │
│    ├─→ Internet Gateway                                 │   │
│    │                                                    │   │
│    ├─→ Subnets ──────────────────────────────────────┐  │   │
│    │    │                                            │  │   │
│    │    ├─→ Route Tables                             │  │   │
│    │    │                                            │  │   │
│    │    └─→ NAT Gateways                             │  │   │
│    │                                                 │  │   │
│    └─→ Security Groups ──────────────────────────────┼──┘   │
│                     │                                │      │
│                     └─→ EC2 Instances ←──────────────┘      │
│                              │                              │
│                              └─→ Load Balancer              │
│                                                             │
└─────────────────────────────────────────────────────────────┘

┌─────────────────────────────────────────────────────────────┐
│                 Dependency Resolution                       │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│   VPC ──────────────────────────────────────────────────┐   │
│    │                                                    │   │
│    ├─→ Internet Gateway                                 │   │
│    │                                                    │   │
│    ├─→ Subnets ──────────────────────────────────────┐  │   │
│    │    │                                            │  │   │
│    │    ├─→ Route Tables                             │  │   │
│    │    │                                            │  │   │
│    │    └─→ NAT Gateways                             │  │   │
│    │                                                 │  │   │
│    └─→ Security Groups ──────────────────────────────┼──┘   │
│                     │                                │      │
│                     └─→ EC2 Instances ←──────────────┘      │
│                              │                              │
│                              └─→ Load Balancer              │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Implizite vs. Explizite Abhängigkeiten:

Resource-Metaargumente:

🔧 Praktisches Beispiel – Count und For_Each:

# Count-basierte Ressourcen
resource "aws_instance" "web" {
  count = var.instance_count
  
  ami           = data.aws_ami.ubuntu.id
  instance_type = "t3.micro"
  
  tags = {
    Name = "web-${count.index + 1}"
  }
}

# For_Each-basierte Ressourcen (flexibler)
resource "aws_instance" "app" {
  for_each = var.applications
  
  ami           = data.aws_ami.ubuntu.id
  instance_type = each.value.instance_type
  
  tags = {
    Name        = "app-${each.key}"
    Application = each.key
    Environment = each.value.environment
  }
}

# Variable für For_Each
variable "applications" {
  type = map(object({
    instance_type = string
    environment   = string
  }))
  
  default = {
    frontend = {
      instance_type = "t3.micro"
      environment   = "production"
    }
    backend = {
      instance_type = "t3.small"
      environment   = "production"
    }
    worker = {
      instance_type = "t3.medium"
      environment   = "production"
    }
  }
}

# Count-basierte Ressourcen
resource "aws_instance" "web" {
  count = var.instance_count
  
  ami           = data.aws_ami.ubuntu.id
  instance_type = "t3.micro"
  
  tags = {
    Name = "web-${count.index + 1}"
  }
}

# For_Each-basierte Ressourcen (flexibler)
resource "aws_instance" "app" {
  for_each = var.applications
  
  ami           = data.aws_ami.ubuntu.id
  instance_type = each.value.instance_type
  
  tags = {
    Name        = "app-${each.key}"
    Application = each.key
    Environment = each.value.environment
  }
}

# Variable für For_Each
variable "applications" {
  type = map(object({
    instance_type = string
    environment   = string
  }))
  
  default = {
    frontend = {
      instance_type = "t3.micro"
      environment   = "production"
    }
    backend = {
      instance_type = "t3.small"
      environment   = "production"
    }
    worker = {
      instance_type = "t3.medium"
      environment   = "production"
    }
  }
}

Lifecycle-Management:

⚠️ Häufige Ressourcen-Probleme und Lösungen:

Datenquellen (Data Sources) – Externe Informationen einbinden

Was sind Data Sources? Data Sources ermöglichen es dir, Informationen aus deiner bestehenden Infrastruktur abzufragen, ohne sie zu verwalten. Sie sind schreibgeschützt und dienen dazu, externe Daten in deine Terraform-Konfiguration einzubinden.

Warum brauchst du Data Sources? Nicht alles in deiner Infrastruktur wird von Terraform verwaltet. Data Sources erlauben es dir, auf bestehende Ressourcen zu verweisen oder dynamische Informationen abzufragen.

Data Source-Kategorien:

🔧 Praktisches Beispiel – Erweiterte Data Sources:

# Bestehende VPC mit komplexen Filtern
data "aws_vpc" "existing" {
  filter {
    name   = "tag:Environment"
    values = ["production"]
  }
  
  filter {
    name   = "tag:Team"
    values = ["platform"]
  }
  
  filter {
    name   = "state"
    values = ["available"]
  }
}

# Verfügbare Availability Zones mit Filtern
data "aws_availability_zones" "available" {
  state = "available"
  
  filter {
    name   = "zone-type"
    values = ["availability-zone"]
  }
  
  exclude_names = ["us-west-2d"]  # Problematische AZ ausschließen
}

# Neueste AMI mit komplexen Kriterien
data "aws_ami" "ubuntu" {
  most_recent = true
  owners      = ["099720109477"]  # Canonical
  
  filter {
    name   = "name"
    values = ["ubuntu/images/hvm-ssd/ubuntu-focal-20.04-amd64-server-*"]
  }
  
  filter {
    name   = "virtualization-type"
    values = ["hvm"]
  }
  
  filter {
    name   = "state"
    values = ["available"]
  }
  
  filter {
    name   = "architecture"
    values = ["x86_64"]
  }
}

# Subnets mit dynamischer Auswahl
data "aws_subnets" "private" {
  filter {
    name   = "vpc-id"
    values = [data.aws_vpc.existing.id]
  }
  
  filter {
    name   = "tag:Type"
    values = ["private"]
  }
  
  filter {
    name   = "availability-zone"
    values = data.aws_availability_zones.available.names
  }
}

# Security Groups mit komplexen Filtern
data "aws_security_groups" "web" {
  filter {
    name   = "vpc-id"
    values = [data.aws_vpc.existing.id]
  }
  
  filter {
    name   = "tag:Purpose"
    values = ["web", "frontend"]
  }
  
  filter {
    name   = "group-name"
    values = ["*-web-*"]
  }
}

# Externe API-Aufrufe
data "http" "my_public_ip" {
  url = "https://ifconfig.me/ip"
  
  request_headers = {
    Accept = "text/plain"
  }
}

# Externe Skripte ausführen
data "external" "vault_token" {
  program = ["bash", "${path.module}/scripts/get_vault_token.sh"]
  
  query = {
    vault_addr = var.vault_addr
    role_id    = var.vault_role_id
  }
}

# SSL-Zertifikat-Informationen
data "aws_acm_certificate" "main" {
  domain      = "*.${var.domain_name}"
  statuses    = ["ISSUED"]
  most_recent = true
}

# Route53 Hosted Zone
data "aws_route53_zone" "main" {
  name         = var.domain_name
  private_zone = false
}

# Bestehende VPC mit komplexen Filtern
data "aws_vpc" "existing" {
  filter {
    name   = "tag:Environment"
    values = ["production"]
  }
  
  filter {
    name   = "tag:Team"
    values = ["platform"]
  }
  
  filter {
    name   = "state"
    values = ["available"]
  }
}

# Verfügbare Availability Zones mit Filtern
data "aws_availability_zones" "available" {
  state = "available"
  
  filter {
    name   = "zone-type"
    values = ["availability-zone"]
  }
  
  exclude_names = ["us-west-2d"]  # Problematische AZ ausschließen
}

# Neueste AMI mit komplexen Kriterien
data "aws_ami" "ubuntu" {
  most_recent = true
  owners      = ["099720109477"]  # Canonical
  
  filter {
    name   = "name"
    values = ["ubuntu/images/hvm-ssd/ubuntu-focal-20.04-amd64-server-*"]
  }
  
  filter {
    name   = "virtualization-type"
    values = ["hvm"]
  }
  
  filter {
    name   = "state"
    values = ["available"]
  }
  
  filter {
    name   = "architecture"
    values = ["x86_64"]
  }
}

# Subnets mit dynamischer Auswahl
data "aws_subnets" "private" {
  filter {
    name   = "vpc-id"
    values = [data.aws_vpc.existing.id]
  }
  
  filter {
    name   = "tag:Type"
    values = ["private"]
  }
  
  filter {
    name   = "availability-zone"
    values = data.aws_availability_zones.available.names
  }
}

# Security Groups mit komplexen Filtern
data "aws_security_groups" "web" {
  filter {
    name   = "vpc-id"
    values = [data.aws_vpc.existing.id]
  }
  
  filter {
    name   = "tag:Purpose"
    values = ["web", "frontend"]
  }
  
  filter {
    name   = "group-name"
    values = ["*-web-*"]
  }
}

# Externe API-Aufrufe
data "http" "my_public_ip" {
  url = "https://ifconfig.me/ip"
  
  request_headers = {
    Accept = "text/plain"
  }
}

# Externe Skripte ausführen
data "external" "vault_token" {
  program = ["bash", "${path.module}/scripts/get_vault_token.sh"]
  
  query = {
    vault_addr = var.vault_addr
    role_id    = var.vault_role_id
  }
}

# SSL-Zertifikat-Informationen
data "aws_acm_certificate" "main" {
  domain      = "*.${var.domain_name}"
  statuses    = ["ISSUED"]
  most_recent = true
}

# Route53 Hosted Zone
data "aws_route53_zone" "main" {
  name         = var.domain_name
  private_zone = false
}

Data Source-Performance und Caching:

Data Sources vs. Resources – Detaillierter Vergleich:

🔧 Praktisches Beispiel – Data Sources in Action:

# Lokale Werte für bessere Performance
locals {
  vpc_id = data.aws_vpc.existing.id
  subnet_ids = data.aws_subnets.private.ids
  
  # Berechnete Werte
  az_count = length(data.aws_availability_zones.available.names)
  
  # Conditional Logic
  use_existing_vpc = var.vpc_id != "" ? var.vpc_id : data.aws_vpc.existing.id
}

# Ressourcen mit Data Source-Referenzen
resource "aws_instance" "web" {
  count = local.az_count
  
  ami           = data.aws_ami.ubuntu.id
  instance_type = "t3.micro"
  subnet_id     = local.subnet_ids[count.index]
  
  vpc_security_group_ids = data.aws_security_groups.web.ids
  
  tags = {
    Name = "web-${count.index + 1}"
    AZ   = data.aws_availability_zones.available.names[count.index]
  }
}

# Load Balancer mit Data Source-Konfiguration
resource "aws_lb" "main" {
  name               = "main-alb"
  internal           = false
  load_balancer_type = "application"
  
  subnets = data.aws_subnets.private.ids
  
  security_groups = data.aws_security_groups.web.ids
  
  tags = {
    VPC = data.aws_vpc.existing.tags.Name
  }
}

# Route53 Record mit externen Daten
resource "aws_route53_record" "api" {
  zone_id = data.aws_route53_zone.main.zone_id
  name    = "api.${data.aws_route53_zone.main.name}"
  type    = "A"
  
  alias {
    name                   = aws_lb.main.dns_name
    zone_id                = aws_lb.main.zone_id
    evaluate_target_health = true
  }
}c

# Lokale Werte für bessere Performance
locals {
  vpc_id = data.aws_vpc.existing.id
  subnet_ids = data.aws_subnets.private.ids
  
  # Berechnete Werte
  az_count = length(data.aws_availability_zones.available.names)
  
  # Conditional Logic
  use_existing_vpc = var.vpc_id != "" ? var.vpc_id : data.aws_vpc.existing.id
}

# Ressourcen mit Data Source-Referenzen
resource "aws_instance" "web" {
  count = local.az_count
  
  ami           = data.aws_ami.ubuntu.id
  instance_type = "t3.micro"
  subnet_id     = local.subnet_ids[count.index]
  
  vpc_security_group_ids = data.aws_security_groups.web.ids
  
  tags = {
    Name = "web-${count.index + 1}"
    AZ   = data.aws_availability_zones.available.names[count.index]
  }
}

# Load Balancer mit Data Source-Konfiguration
resource "aws_lb" "main" {
  name               = "main-alb"
  internal           = false
  load_balancer_type = "application"
  
  subnets = data.aws_subnets.private.ids
  
  security_groups = data.aws_security_groups.web.ids
  
  tags = {
    VPC = data.aws_vpc.existing.tags.Name
  }
}

# Route53 Record mit externen Daten
resource "aws_route53_record" "api" {
  zone_id = data.aws_route53_zone.main.zone_id
  name    = "api.${data.aws_route53_zone.main.name}"
  type    = "A"
  
  alias {
    name                   = aws_lb.main.dns_name
    zone_id                = aws_lb.main.zone_id
    evaluate_target_health = true
  }
}c

💡 Praxis-Tipps für Data Sources:

┌ Verwende lokale Variablen für häufig referenzierte Data Sources
├ Nutze spezifische Filter, um API-Calls zu reduzieren
├ Berücksichtige, dass Data Sources bei jedem Plan abgefragt werden
└ Verwende depends_on nur wenn nötig, da es die Parallelisierung verhindert

⚠️ Häufige Data Source-Probleme:

Module – Wiederverwendbare Infrastruktur-Komponenten

Was sind Module? Module sind wiederverwendbare Terraform-Konfigurationen. Sie fassen zusammengehörige Ressourcen in logische Einheiten zusammen und ermöglichen es, bewährte Patterns zu kapseln und zu teilen.

Warum sind Module wichtig? Module reduzieren Code-Duplikation, erhöhen die Konsistenz und machen komplexe Infrastrukturen wartbarer. Sie sind das Äquivalent zu Funktionen in Programmiersprachen.

Module-Hierarchie und -Typen:

Module-Architektur:

┌─────────────────────────────────────────────────────────────┐
│                    Module Architecture                      │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  Root Module (main.tf)                                      │
│  ├─── Local Module (./modules/vpc)                          │
│  │    ├─── variables.tf                                     │
│  │    ├─── main.tf                                          │
│  │    ├─── outputs.tf                                       │
│  │    └─── versions.tf                                      │
│  │                                                          │
│  ├─── Remote Module (terraform-aws-modules/eks/aws)         │
│  │    └─── Version: 19.0.0                                  │
│  │                                                          │
│  └─── Private Module (company.com/modules/security)         │
│       └─── Version: 1.2.3                                   │
│                                                             │
└─────────────────────────────────────────────────────────────┘

┌─────────────────────────────────────────────────────────────┐
│                    Module Architecture                      │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  Root Module (main.tf)                                      │
│  ├─── Local Module (./modules/vpc)                          │
│  │    ├─── variables.tf                                     │
│  │    ├─── main.tf                                          │
│  │    ├─── outputs.tf                                       │
│  │    └─── versions.tf                                      │
│  │                                                          │
│  ├─── Remote Module (terraform-aws-modules/eks/aws)         │
│  │    └─── Version: 19.0.0                                  │
│  │                                                          │
│  └─── Private Module (company.com/modules/security)         │
│       └─── Version: 1.2.3                                   │
│                                                             │
└─────────────────────────────────────────────────────────────┘

🔧 Praktisches Beispiel – Komplexes VPC-Modul:

Module-Struktur:

modules/vpc/
├── main.tf                   # Hauptkonfiguration
├── variables.tf            # Input-Variablen
├── outputs.tf              # Output-Werte
├── versions.tf             # Provider-Anforderungen
├── locals.tf                  # Lokale Berechnungen
└── README.md        # Dokumentation

variables.tf:

variable "name" {
  description = "Name for the VPC and related resources"
  type        = string
  validation {
    condition     = length(var.name) > 0 && length(var.name) <= 32
    error_message = "VPC name must be between 1 and 32 characters."
  }
}

variable "cidr_block" {
  description = "CIDR block for the VPC"
  type        = string
  validation {
    condition     = can(cidrhost(var.cidr_block, 0))
    error_message = "CIDR block must be a valid IPv4 CIDR."
  }
}

variable "availability_zones" {
  description = "List of availability zones"
  type        = list(string)
  validation {
    condition     = length(var.availability_zones) >= 2
    error_message = "At least 2 availability zones are required."
  }
}

variable "public_subnets" {
  description = "List of public subnet CIDR blocks"
  type        = list(string)
  default     = []
}

variable "private_subnets" {
  description = "List of private subnet CIDR blocks"
  type        = list(string)
  default     = []
}

variable "enable_nat_gateway" {
  description = "Enable NAT gateway for private subnets"
  type        = bool
  default     = true
}

variable "single_nat_gateway" {
  description = "Use single NAT gateway for all private subnets"
  type        = bool
  default     = false
}

variable "enable_dns_hostnames" {
  description = "Enable DNS hostnames in the VPC"
  type        = bool
  default     = true
}

variable "enable_dns_support" {
  description = "Enable DNS support in the VPC"
  type        = bool
  default     = true
}

variable "tags" {
  description = "Additional tags for all resources"
  type        = map(string)
  default     = {}
}

variable "name" {
  description = "Name for the VPC and related resources"
  type        = string
  validation {
    condition     = length(var.name) > 0 && length(var.name) <= 32
    error_message = "VPC name must be between 1 and 32 characters."
  }
}

variable "cidr_block" {
  description = "CIDR block for the VPC"
  type        = string
  validation {
    condition     = can(cidrhost(var.cidr_block, 0))
    error_message = "CIDR block must be a valid IPv4 CIDR."
  }
}

variable "availability_zones" {
  description = "List of availability zones"
  type        = list(string)
  validation {
    condition     = length(var.availability_zones) >= 2
    error_message = "At least 2 availability zones are required."
  }
}

variable "public_subnets" {
  description = "List of public subnet CIDR blocks"
  type        = list(string)
  default     = []
}

variable "private_subnets" {
  description = "List of private subnet CIDR blocks"
  type        = list(string)
  default     = []
}

variable "enable_nat_gateway" {
  description = "Enable NAT gateway for private subnets"
  type        = bool
  default     = true
}

variable "single_nat_gateway" {
  description = "Use single NAT gateway for all private subnets"
  type        = bool
  default     = false
}

variable "enable_dns_hostnames" {
  description = "Enable DNS hostnames in the VPC"
  type        = bool
  default     = true
}

variable "enable_dns_support" {
  description = "Enable DNS support in the VPC"
  type        = bool
  default     = true
}

variable "tags" {
  description = "Additional tags for all resources"
  type        = map(string)
  default     = {}
}

locals.tf:

locals {
  # Berechne Anzahl der AZs
  az_count = length(var.availability_zones)
  
  # NAT Gateway-Anzahl
  nat_gateway_count = var.single_nat_gateway ? 1 : local.az_count
  
  # Gemeinsame Tags
  common_tags = merge(
    var.tags,
    {
      ManagedBy = "terraform"
      Module    = "vpc"
    }
  )
  
  # Subnet-Berechnungen
  public_subnet_count  = length(var.public_subnets)
  private_subnet_count = length(var.private_subnets)
  
  # Validierung
  has_public_subnets  = local.public_subnet_count > 0
  has_private_subnets = local.private_subnet_count > 0
  
  # Route Table-Zuordnungen
  private_route_table_ids = var.single_nat_gateway ? [aws_route_table.private[0].id] : aws_route_table.private[*].id
}

locals {
  # Berechne Anzahl der AZs
  az_count = length(var.availability_zones)
  
  # NAT Gateway-Anzahl
  nat_gateway_count = var.single_nat_gateway ? 1 : local.az_count
  
  # Gemeinsame Tags
  common_tags = merge(
    var.tags,
    {
      ManagedBy = "terraform"
      Module    = "vpc"
    }
  )
  
  # Subnet-Berechnungen
  public_subnet_count  = length(var.public_subnets)
  private_subnet_count = length(var.private_subnets)
  
  # Validierung
  has_public_subnets  = local.public_subnet_count > 0
  has_private_subnets = local.private_subnet_count > 0
  
  # Route Table-Zuordnungen
  private_route_table_ids = var.single_nat_gateway ? [aws_route_table.private[0].id] : aws_route_table.private[*].id
}

main.tf:

# VPC erstellen
resource "aws_vpc" "main" {
  cidr_block           = var.cidr_block
  enable_dns_hostnames = var.enable_dns_hostnames
  enable_dns_support   = var.enable_dns_support
  
  tags = merge(
    local.common_tags,
    {
      Name = var.name
    }
  )
}

# Internet Gateway
resource "aws_internet_gateway" "main" {
  count = local.has_public_subnets ? 1 : 0
  
  vpc_id = aws_vpc.main.id
  
  tags = merge(
    local.common_tags,
    {
      Name = "${var.name}-igw"
    }
  )
}

# Public Subnets
resource "aws_subnet" "public" {
  count = local.public_subnet_count
  
  vpc_id                  = aws_vpc.main.id
  cidr_block              = var.public_subnets[count.index]
  availability_zone       = var.availability_zones[count.index]
  map_public_ip_on_launch = true
  
  tags = merge(
    local.common_tags,
    {
      Name = "${var.name}-public-${count.index + 1}"
      Type = "public"
    }
  )
}

# Private Subnets
resource "aws_subnet" "private" {
  count = local.private_subnet_count
  
  vpc_id            = aws_vpc.main.id
  cidr_block        = var.private_subnets[count.index]
  availability_zone = var.availability_zones[count.index]
  
  tags = merge(
    local.common_tags,
    {
      Name = "${var.name}-private-${count.index + 1}"
      Type = "private"
    }
  )
}

# Elastic IPs für NAT Gateways
resource "aws_eip" "nat" {
  count = local.has_private_subnets && var.enable_nat_gateway ? local.nat_gateway_count : 0
  
  domain = "vpc"
  
  depends_on = [aws_internet_gateway.main]
  
  tags = merge(
    local.common_tags,
    {
      Name = "${var.name}-nat-eip-${count.index + 1}"
    }
  )
}

# NAT Gateways
resource "aws_nat_gateway" "main" {
  count = local.has_private_subnets && var.enable_nat_gateway ? local.nat_gateway_count : 0
  
  allocation_id = aws_eip.nat[count.index].id
  subnet_id     = aws_subnet.public[count.index].id
  
  depends_on = [aws_internet_gateway.main]
  
  tags = merge(
    local.common_tags,
    {
      Name = "${var.name}-nat-${count.index + 1}"
    }
  )
}

# Public Route Table
resource "aws_route_table" "public" {
  count = local.has_public_subnets ? 1 : 0
  
  vpc_id = aws_vpc.main.id
  
  route {
    cidr_block = "0.0.0.0/0"
    gateway_id = aws_internet_gateway.main[0].id
  }
  
  tags = merge(
    local.common_tags,
    {
      Name = "${var.name}-public-rt"
    }
  )
}

# Private Route Tables
resource "aws_route_table" "private" {
  count = local.has_private_subnets ? local.nat_gateway_count : 0
  
  vpc_id = aws_vpc.main.id
  
  dynamic "route" {
    for_each = var.enable_nat_gateway ? [1] : []
    content {
      cidr_block     = "0.0.0.0/0"
      nat_gateway_id = aws_nat_gateway.main[count.index].id
    }
  }
  
  tags = merge(
    local.common_tags,
    {
      Name = "${var.name}-private-rt-${count.index + 1}"
    }
  )
}

# Public Route Table Associations
resource "aws_route_table_association" "public" {
  count = local.public_subnet_count
  
  subnet_id      = aws_subnet.public[count.index].id
  route_table_id = aws_route_table.public[0].id
}

# Private Route Table Associations
resource "aws_route_table_association" "private" {
  count = local.private_subnet_count
  
  subnet_id      = aws_subnet.private[count.index].id
  route_table_id = local.private_route_table_ids[var.single_nat_gateway ? 0 : count.index]
}

# VPC erstellen
resource "aws_vpc" "main" {
  cidr_block           = var.cidr_block
  enable_dns_hostnames = var.enable_dns_hostnames
  enable_dns_support   = var.enable_dns_support
  
  tags = merge(
    local.common_tags,
    {
      Name = var.name
    }
  )
}

# Internet Gateway
resource "aws_internet_gateway" "main" {
  count = local.has_public_subnets ? 1 : 0
  
  vpc_id = aws_vpc.main.id
  
  tags = merge(
    local.common_tags,
    {
      Name = "${var.name}-igw"
    }
  )
}

# Public Subnets
resource "aws_subnet" "public" {
  count = local.public_subnet_count
  
  vpc_id                  = aws_vpc.main.id
  cidr_block              = var.public_subnets[count.index]
  availability_zone       = var.availability_zones[count.index]
  map_public_ip_on_launch = true
  
  tags = merge(
    local.common_tags,
    {
      Name = "${var.name}-public-${count.index + 1}"
      Type = "public"
    }
  )
}

# Private Subnets
resource "aws_subnet" "private" {
  count = local.private_subnet_count
  
  vpc_id            = aws_vpc.main.id
  cidr_block        = var.private_subnets[count.index]
  availability_zone = var.availability_zones[count.index]
  
  tags = merge(
    local.common_tags,
    {
      Name = "${var.name}-private-${count.index + 1}"
      Type = "private"
    }
  )
}

# Elastic IPs für NAT Gateways
resource "aws_eip" "nat" {
  count = local.has_private_subnets && var.enable_nat_gateway ? local.nat_gateway_count : 0
  
  domain = "vpc"
  
  depends_on = [aws_internet_gateway.main]
  
  tags = merge(
    local.common_tags,
    {
      Name = "${var.name}-nat-eip-${count.index + 1}"
    }
  )
}

# NAT Gateways
resource "aws_nat_gateway" "main" {
  count = local.has_private_subnets && var.enable_nat_gateway ? local.nat_gateway_count : 0
  
  allocation_id = aws_eip.nat[count.index].id
  subnet_id     = aws_subnet.public[count.index].id
  
  depends_on = [aws_internet_gateway.main]
  
  tags = merge(
    local.common_tags,
    {
      Name = "${var.name}-nat-${count.index + 1}"
    }
  )
}

# Public Route Table
resource "aws_route_table" "public" {
  count = local.has_public_subnets ? 1 : 0
  
  vpc_id = aws_vpc.main.id
  
  route {
    cidr_block = "0.0.0.0/0"
    gateway_id = aws_internet_gateway.main[0].id
  }
  
  tags = merge(
    local.common_tags,
    {
      Name = "${var.name}-public-rt"
    }
  )
}

# Private Route Tables
resource "aws_route_table" "private" {
  count = local.has_private_subnets ? local.nat_gateway_count : 0
  
  vpc_id = aws_vpc.main.id
  
  dynamic "route" {
    for_each = var.enable_nat_gateway ? [1] : []
    content {
      cidr_block     = "0.0.0.0/0"
      nat_gateway_id = aws_nat_gateway.main[count.index].id
    }
  }
  
  tags = merge(
    local.common_tags,
    {
      Name = "${var.name}-private-rt-${count.index + 1}"
    }
  )
}

# Public Route Table Associations
resource "aws_route_table_association" "public" {
  count = local.public_subnet_count
  
  subnet_id      = aws_subnet.public[count.index].id
  route_table_id = aws_route_table.public[0].id
}

# Private Route Table Associations
resource "aws_route_table_association" "private" {
  count = local.private_subnet_count
  
  subnet_id      = aws_subnet.private[count.index].id
  route_table_id = local.private_route_table_ids[var.single_nat_gateway ? 0 : count.index]
}

outputs.tf:

output "vpc_id" {
  description = "ID of the VPC"
  value       = aws_vpc.main.id
}

output "vpc_cidr_block" {
  description = "CIDR block of the VPC"
  value       = aws_vpc.main.cidr_block
}

output "public_subnet_ids" {
  description = "IDs of the public subnets"
  value       = aws_subnet.public[*].id
}

output "private_subnet_ids" {
  description = "IDs of the private subnets"
  value       = aws_subnet.private[*].id
}

output "internet_gateway_id" {
  description = "ID of the internet gateway"
  value       = local.has_public_subnets ? aws_internet_gateway.main[0].id : null
}

output "nat_gateway_ids" {
  description = "IDs of the NAT gateways"
  value       = aws_nat_gateway.main[*].id
}

output "public_route_table_id" {
  description = "ID of the public route table"
  value       = local.has_public_subnets ? aws_route_table.public[0].id : null
}

output "private_route_table_ids" {
  description = "IDs of the private route tables"
  value       = aws_route_table.private[*].id
}

output "availability_zones" {
  description = "List of availability zones used"
  value       = var.availability_zones
}

output "vpc_id" {
  description = "ID of the VPC"
  value       = aws_vpc.main.id
}

output "vpc_cidr_block" {
  description = "CIDR block of the VPC"
  value       = aws_vpc.main.cidr_block
}

output "public_subnet_ids" {
  description = "IDs of the public subnets"
  value       = aws_subnet.public[*].id
}

output "private_subnet_ids" {
  description = "IDs of the private subnets"
  value       = aws_subnet.private[*].id
}

output "internet_gateway_id" {
  description = "ID of the internet gateway"
  value       = local.has_public_subnets ? aws_internet_gateway.main[0].id : null
}

output "nat_gateway_ids" {
  description = "IDs of the NAT gateways"
  value       = aws_nat_gateway.main[*].id
}

output "public_route_table_id" {
  description = "ID of the public route table"
  value       = local.has_public_subnets ? aws_route_table.public[0].id : null
}

output "private_route_table_ids" {
  description = "IDs of the private route tables"
  value       = aws_route_table.private[*].id
}

output "availability_zones" {
  description = "List of availability zones used"
  value       = var.availability_zones
}

Module-Verwendung:

# Entwicklungsumgebung
module "vpc_dev" {
  source = "./modules/vpc"
  
  name               = "dev-vpc"
  cidr_block         = "10.0.0.0/16"
  availability_zones = ["us-west-2a", "us-west-2b"]
  
  public_subnets  = ["10.0.1.0/24", "10.0.2.0/24"]
  private_subnets = ["10.0.10.0/24", "10.0.20.0/24"]
  
  enable_nat_gateway  = true
  single_nat_gateway  = true  # Kosteneinsparung
  
  tags = {
    Environment = "development"
    Project     = "my-app"
  }
}

# Produktionsumgebung
module "vpc_prod" {
  source = "./modules/vpc"
  
  name               = "prod-vpc"
  cidr_block         = "10.1.0.0/16"
  availability_zones = ["us-west-2a", "us-west-2b", "us-west-2c"]
  
  public_subnets  = ["10.1.1.0/24", "10.1.2.0/24", "10.1.3.0/24"]
  private_subnets = ["10.1.10.0/24", "10.1.20.0/24", "10.1.30.0/24"]
  
  enable_nat_gateway  = true
  single_nat_gateway  = false  # Hochverfügbarkeit
  
  tags = {
    Environment = "production"
    Project     = "my-app"
  }
}

# Remote Module aus Registry
module "eks" {
  source = "terraform-aws-modules/eks/aws"
  version = "19.0.0"
  
  cluster_name    = "my-cluster"
  cluster_version = "1.24"
  
  vpc_id     = module.vpc_prod.vpc_id
  subnet_ids = module.vpc_prod.private_subnet_ids
  
  eks_managed_node_groups = {
    main = {
      instance_types = ["t3.medium"]
      min_size       = 1
      max_size       = 3
      desired_size   = 2
    }
  }
  
  tags = {
    Environment = "production"
  }
}

# Entwicklungsumgebung
module "vpc_dev" {
  source = "./modules/vpc"
  
  name               = "dev-vpc"
  cidr_block         = "10.0.0.0/16"
  availability_zones = ["us-west-2a", "us-west-2b"]
  
  public_subnets  = ["10.0.1.0/24", "10.0.2.0/24"]
  private_subnets = ["10.0.10.0/24", "10.0.20.0/24"]
  
  enable_nat_gateway  = true
  single_nat_gateway  = true  # Kosteneinsparung
  
  tags = {
    Environment = "development"
    Project     = "my-app"
  }
}

# Produktionsumgebung
module "vpc_prod" {
  source = "./modules/vpc"
  
  name               = "prod-vpc"
  cidr_block         = "10.1.0.0/16"
  availability_zones = ["us-west-2a", "us-west-2b", "us-west-2c"]
  
  public_subnets  = ["10.1.1.0/24", "10.1.2.0/24", "10.1.3.0/24"]
  private_subnets = ["10.1.10.0/24", "10.1.20.0/24", "10.1.30.0/24"]
  
  enable_nat_gateway  = true
  single_nat_gateway  = false  # Hochverfügbarkeit
  
  tags = {
    Environment = "production"
    Project     = "my-app"
  }
}

# Remote Module aus Registry
module "eks" {
  source = "terraform-aws-modules/eks/aws"
  version = "19.0.0"
  
  cluster_name    = "my-cluster"
  cluster_version = "1.24"
  
  vpc_id     = module.vpc_prod.vpc_id
  subnet_ids = module.vpc_prod.private_subnet_ids
  
  eks_managed_node_groups = {
    main = {
      instance_types = ["t3.medium"]
      min_size       = 1
      max_size       = 3
      desired_size   = 2
    }
  }
  
  tags = {
    Environment = "production"
  }
}

Module-Versionierung und Lifecycle:

Module-Testing-Strategien:

💡 Module-Best-Practices:

┌ Verwende semantische Versionierung für öffentliche Module
├ Implementiere Input-Validierung für kritische Parameter
├ Dokumentiere alle Input- und Output-Variablen
├ Nutze lokale Module für projekt-spezifische Patterns
└ Teste Module in isolierten Umgebungen

⚠️ Häufige Module-Probleme:

Zusammenspiel aller Komponenten:

┌─────────────────────────────────────────────────────────────┐
│                Component Interaction Flow                   │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  1. Provider ←── Authentication ──→ Cloud APIs              │
│      ↓                                                      │
│  2. Data Sources ←── Query ──→ Existing Infrastructure      │
│      ↓                                                      │
│  3. Resources ←── Create/Update/Delete ──→ Infrastructure   │
│      ↓                                                      │
│  4. Modules ←── Encapsulate ──→ Reusable Components         │
│      ↓                                                      │
│  5. State File ←── Track ──→ Current State                  │
│                                                             │
└─────────────────────────────────────────────────────────────┘

┌─────────────────────────────────────────────────────────────┐
│                Component Interaction Flow                   │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  1. Provider ←── Authentication ──→ Cloud APIs              │
│      ↓                                                      │
│  2. Data Sources ←── Query ──→ Existing Infrastructure      │
│      ↓                                                      │
│  3. Resources ←── Create/Update/Delete ──→ Infrastructure   │
│      ↓                                                      │
│  4. Modules ←── Encapsulate ──→ Reusable Components         │
│      ↓                                                      │
│  5. State File ←── Track ──→ Current State                  │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Jetzt verstehst du die vier Kernkomponenten von Terraform im Detail. Jede hat ihre spezifische Rolle, aber zusammen bilden sie ein mächtiges System zur Infrastrukturverwaltung. Im nächsten Schritt schauen wir uns an, wie diese Komponenten im typischen Terraform-Workflow zusammenarbeiten.

Terraform Workflow

Nachdem du die Kernkomponenten von Terraform verstanden hast, schauen wir uns den praktischen Workflow an. Terraform folgt einem klaren, wiederholbaren Prozess: Write → Plan → Apply → Destroy. Dieser Workflow ist das Herzstück der Terraform-Arbeitsweise und bestimmt, wie du täglich mit dem Tool arbeitest.

Write → Plan → Apply → Destroy

Was ist der Terraform-Workflow? Der Terraform-Workflow ist ein vierstufiger Prozess, der dich von der Konfiguration bis zur Bereitstellung und Verwaltung deiner Infrastruktur führt. Jeder Schritt hat eine spezifische Aufgabe und baut auf dem vorherigen auf.

Warum ist dieser Workflow so wichtig? Der strukturierte Ansatz verhindert Fehler, ermöglicht Reviews und gibt dir volle Kontrolle über Infrastruktur-Änderungen. Du siehst immer, was passieren wird, bevor es passiert.

Der vollständige Workflow im Detail:

1. WRITE (Konfiguration)                                   
     ├─ .tf Dateien erstellen                               
	 ├─ Variablen definieren                                
	 └─ Module einbinden                                    
              ↓                                        
2. INIT (Initialisierung)                                  
	 ├─ Provider herunterladen                              
	 ├─ Backend konfigurieren                               
	 └─ Module initialisieren                               
               ↓                                        
3. PLAN (Planung)                                         
	 ├─ Änderungen berechnen                               
	 ├─ Dependency Graph erstellen                          
	 └─ Preview anzeigen                                    
             ↓                                        
4. APPLY (Anwendung)                                      
	 ├─ Änderungen ausführen                               
	 ├─ State aktualisieren                                 
	 └─ Outputs anzeigen                                    
             ↓                                        
5. DESTROY (Aufräumen)                                    
	 ├─ Ressourcen löschen                                  
	 ├─ State bereinigen                                    
	 └─ Kosten sparen 

Workflow-Phasen im Detail:

Write-Phase: Konfiguration erstellen

Was passiert in der Write-Phase? Du erstellst und bearbeitest deine Terraform-Konfigurationsdateien. Das umfasst das Schreiben von HCL-Code, das Definieren von Variablen und das Strukturieren deiner Infrastruktur.

Warum ist diese Phase so wichtig? Hier legst du den Grundstein für deine gesamte Infrastruktur. Gute Planung und sauberer Code in dieser Phase sparen dir später viel Zeit und Probleme.

🔧 Praktisches Beispiel – Typische Write-Phase:

Projektstruktur aufbauen:

project/
├── main.tf                        # Hauptkonfiguration
├── variables.tf                 # Input-Variablen
├── outputs.tf                   # Output-Werte
├── versions.tf                   # Provider-Versionen
├── terraform.tfvars         # Variablen-Werte
├── modules/                     # Lokale Module
│   └── vpc/
│       ├── main.tf
│       ├── variables.tf
│       └── outputs.tf
└── environments/             # Umgebungsspezifische Configs
    ├── dev/
    │   └── terraform.tfvars
    └── prod/
        └── terraform.tfvars

versions.tf – Provider-Anforderungen:

terraform {
  required_version = ">= 1.0"
  
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
    random = {
      source  = "hashicorp/random"
      version = "~> 3.1"
    }
  }
  
  # Backend-Konfiguration
  backend "s3" {
    bucket = "my-terraform-state"
    key    = "infrastructure/terraform.tfstate"
    region = "us-west-2"
  }
}
```

**variables.tf - Input-Variablen:**
```hcl
variable "environment" {
  description = "Environment name (dev, staging, prod)"
  type        = string
  validation {
    condition     = contains(["dev", "staging", "prod"], var.environment)
    error_message = "Environment must be dev, staging, or prod."
  }
}

variable "project_name" {
  description = "Name of the project"
  type        = string
  validation {
    condition     = can(regex("^[a-zA-Z0-9-]+$", var.project_name))
    error_message = "Project name must contain only alphanumeric characters and hyphens."
  }
}

variable "vpc_cidr" {
  description = "CIDR block for VPC"
  type        = string
  default     = "10.0.0.0/16"
  validation {
    condition     = can(cidrhost(var.vpc_cidr, 0))
    error_message = "VPC CIDR must be a valid IPv4 CIDR block."
  }
}

variable "availability_zones" {
  description = "List of availability zones"
  type        = list(string)
  default     = ["us-west-2a", "us-west-2b"]
}

variable "instance_type" {
  description = "EC2 instance type"
  type        = string
  default     = "t3.micro"
}

variable "enable_monitoring" {
  description = "Enable CloudWatch monitoring"
  type        = bool
  default     = true
}

variable "tags" {
  description = "Common tags for all resources"
  type        = map(string)
  default     = {}
}

terraform {
  required_version = ">= 1.0"
  
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
    random = {
      source  = "hashicorp/random"
      version = "~> 3.1"
    }
  }
  
  # Backend-Konfiguration
  backend "s3" {
    bucket = "my-terraform-state"
    key    = "infrastructure/terraform.tfstate"
    region = "us-west-2"
  }
}
```

**variables.tf - Input-Variablen:**
```hcl
variable "environment" {
  description = "Environment name (dev, staging, prod)"
  type        = string
  validation {
    condition     = contains(["dev", "staging", "prod"], var.environment)
    error_message = "Environment must be dev, staging, or prod."
  }
}

variable "project_name" {
  description = "Name of the project"
  type        = string
  validation {
    condition     = can(regex("^[a-zA-Z0-9-]+$", var.project_name))
    error_message = "Project name must contain only alphanumeric characters and hyphens."
  }
}

variable "vpc_cidr" {
  description = "CIDR block for VPC"
  type        = string
  default     = "10.0.0.0/16"
  validation {
    condition     = can(cidrhost(var.vpc_cidr, 0))
    error_message = "VPC CIDR must be a valid IPv4 CIDR block."
  }
}

variable "availability_zones" {
  description = "List of availability zones"
  type        = list(string)
  default     = ["us-west-2a", "us-west-2b"]
}

variable "instance_type" {
  description = "EC2 instance type"
  type        = string
  default     = "t3.micro"
}

variable "enable_monitoring" {
  description = "Enable CloudWatch monitoring"
  type        = bool
  default     = true
}

variable "tags" {
  description = "Common tags for all resources"
  type        = map(string)
  default     = {}
}