Terraform Provider

main.tf:

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
  }
}

provider "aws" {
  region = "eu-central-1"
}

Dann terraform init. Er lädt .terraform/providers/registry.terraform.io/hashicorp/aws/....

1. Provider Aliases (Multi-Region)

Du willst eine Ressource in Frankfurt (eu-central-1) und das Backup in USA (us-east-1) erstellen. Innerhalb eines Terraform Runs. Du definierst den Provider zweimal, mit Alias:

provider "aws" {
  alias  = "usa"
  region = "us-east-1"
}

resource "aws_s3_bucket" "backup" {
  provider = aws.usa  # Nutze den USA-Provider
  bucket   = "my-backup"
}

Ohne Alias nutzt er den Default-Provider.

2. Dependency Lock File

Die .terraform.lock.hcl ist heilig. Sie speichert den genauen Hash des Providers (z. B. AWS v5.12.0). Warum? Wenn AWS v5.13.0 einen Bug einführt oder Breaking Changes hat, schützt dich der Lockfile. Jeder Kollege nutzt exakt dieselbe Binary-Version. Committe diese Datei immer!

3. Custom Providers

Terraform ist offen. Du hast eine interne Firmen-API ("Order Pizza API")? Du kannst einen eigenen Provider in Go schreiben (terraform-plugin-sdk). Dann kannst du Pizza per Terraform bestellen:

resource "pizza_order" "margherita" {
  cheese = true
}

Das macht Terraform zum Universal-Tool für alles, was eine API hat (nicht nur Server).

Die Terraform-to-Provider gRPC Brücke

Wie sprechen die Core-Binary terraform und der externe AWS-Provider (auch ein Binary) überhaupt miteinander? Sie nutzen gRPC über lokalen TCP/Unix-Sockets. Wenn du terraform apply eintippst, startet Terraform im Hintergrund unsichtbar das AWS-Provider-Binary als Child-Prozess. Der Provider öffnet einen lokalen RPC-Server und gibt den Port an Core zurück. Core kommuniziert fortan via Protocol Buffers (Protobuf) mit dem Plugin. Das bedeutet absolute Prozess-Trennung: Wenn der Provider abstürzt (weil er schlampig in Go geschrieben wurde), reißt er nicht die Terraform Core-Binary in den Kernel-Panic. Core meldet sauber: "Provider crashed".

Das Stateful CRUD (Create, Read, Update, Delete) Lifecycle

Jeder Provider muss für jede Resource (z.B. aws_instance) einen brutalen, strikt vorgegebenen Lifecycle im Plugin-Code (Read(), Create(), Update(), Delete()) definieren. Der wichtigste ist Read(). Bevor Terraform entscheidet, etwas upzudaten oder zu erstellen, führt der Provider immer zwingend ein Read() gegen die Cloud API aus. Das Resultat vergleicht er mit der .tfstate. Findet er Differenzen (Drift), weiß er, dass jemand in der physischen Cloud manuell gepfuscht hat. Liefert Read() einen 404 zurück, nimmt der Provider sofort an: Die Instanz wurde gelöscht, wir müssen den State purgen und sie neu bauen (Destroy and then Create).

Eigene Provider entwickeln (Terraform Plugin Framework)

Firmen entwickeln oft intern eigene Provider für ihr IPAM (IP Address Management) oder VMware-Instanzen ohne offizielle REST-Schnittstelle. Bis 2022 nutzte man das terraform-plugin-sdk/v2 (mit wilden Type-Conversions). Heute ist das Terraform Plugin Framework der Standard. Es zwingt den Go-Entwickler, sauberes Type-System-Mapping (HCL Typen zu Go-Typen) zu definieren. Die Kunst beim Provider-Schreiben: Das Abfangen von Cloud-API Eventual Consistencies (AWS braucht oft Sekunden, bis ein Bucket wirklich da ist, die API sagt aber sofort "200 OK"). Gute Provider implementieren heftige Retry-Logs (d.Timeout()) in ihren C-Reads.