Terraform-architectuur: state, providers en de plan/apply-cyclus
Terraform beheert infrastructuur als code. De sleutel om dit echt te begrijpen zit in het state-bestand en de plan/apply-cyclus.
Terraform beschrijft infrastructuur declaratief: je schrijft op wat je wilt hebben (een server, een netwerk, een DNS-record), en Terraform zoekt uit hoe dat te bereiken is. De motor achter dat proces bestaat uit een paar kernonderdelen.
Het state-bestand: het geheugen van Terraform
Terraform houdt in een state-bestand (standaard terraform.tfstate) bij welke resources het beheert en wat hun laatst bekende, werkelijke configuratie is. Zonder state zou Terraform bij elke run alles opnieuw moeten uitvinden â met state weet het precies wat er al bestaat en wat er moet veranderen.
Providers: de vertalers
Een provider (bijvoorbeeld voor AWS, Azure, of Kubernetes) vertaalt de generieke Terraform-configuratie naar concrete API-aanroepen bij die specifieke leverancier. Dankzij dit providermodel kan dezelfde Terraform-taal gebruikt worden voor tientallen verschillende platformen.
De plan/apply-cyclus
- terraform plan â vergelijkt de gewenste configuratie (.tf-bestanden) met de huidige state, en toont exact welke resources aangemaakt, gewijzigd of verwijderd zouden worden. Er verandert nog niets.
- terraform apply â voert het plan daadwerkelijk uit via de providers, en werkt daarna het state-bestand bij zodat het weer overeenkomt met de nieuwe werkelijkheid.
Waarom een remote backend belangrijk is
Werkt een team samen aan dezelfde infrastructuur, dan moet het state-bestand centraal en met locking worden opgeslagen (bijvoorbeeld in een cloud-opslagdienst met een lock-mechanisme). Zonder locking kunnen twee gelijktijdige apply-runs elkaars wijzigingen overschrijven of corrupte state veroorzaken.
Examentip: Een vraag over "waarom denkt Terraform dat een resource niet meer bestaat, terwijl hij er handmatig wÊl bijgemaakt is" wijst op state drift â het state-bestand komt niet meer overeen met de echte wereld.