Inhoudsopgave
Servers handmatig aanmaken via een cloudconsole werkt prima voor een enkel project, maar schaalt slecht. Je klikt je omgeving in elkaar, onthoudt (of vergeet) welke instellingen je hebt gekozen en hoopt dat je het op de testomgeving net zo hebt gedaan als op productie. Infrastructure as Code (IaC) lost dat op door je infrastructuur te beschrijven in configuratiebestanden die je versiebeheert, reviewt en automatisch uitrolt. Terraform is daarin de meest gebruikte tool en werkt met vrijwel elke cloud provider via hetzelfde principe.
Hoe Terraform werkt
Terraform werkt met declaratieve configuratiebestanden in de HCL-taal (HashiCorp Configuration Language). Je beschrijft de gewenste eindsituatie (“ik wil een server met deze specs en een database met deze configuratie”) en Terraform berekent wat er moet gebeuren om daar te komen. Met terraform plan zie je vooraf precies welke resources worden aangemaakt, gewijzigd of verwijderd. Met terraform apply voer je die wijzigingen uit. Die scheiding tussen plannen en uitvoeren geeft je controle en voorkomt verrassingen in productie.
State en de state file
Terraform houdt bij wat er is uitgerold via een state file. Die file beschrijft de huidige situatie van je infrastructuur en is de basis waartegen Terraform nieuwe configuraties vergelijkt. Lokaal opslaan werkt voor solo projecten, maar in een team wil je de state file op een gedeelde locatie zoals een S3-bucket of Terraform Cloud bewaren zodat iedereen met dezelfde staat werkt. Vergrendeling van de state file (via DynamoDB of ingebouwd in Terraform Cloud) voorkomt dat twee mensen tegelijk wijzigingen doorvoeren en elkaars werk overschrijven.
Modules voor herbruikbaarheid
Wie meerdere omgevingen (development, staging, productie) beheert merkt al snel dat veel configuratie identiek is op een paar variabelen na. Terraform modules lossen dat op: je definieert een herbruikbaar blok configuratie (een module voor een standaard webserver setup, een module voor een databasecluster) en roept die aan met omgevingsspecifieke variabelen. Modules zijn te delen via een eigen registry of via de publieke Terraform Registry waar providers zoals AWS, Google Cloud en Azure kant-en-klare modules aanbieden voor veelgebruikte configuraties.
Wijzigingen veilig doorvoeren
Infrastructuurwijzigingen zijn risicovoller dan codewijzigingen omdat een fout direct impact heeft op draaiende systemen. Een paar gewoontes verlagen dat risico aanzienlijk. Voer altijd eerst terraform plan uit en lees de output kritisch door voordat je apply uitvoert. Gebruik workspaces of aparte state files per omgeving zodat een wijziging in development nooit automatisch productie raakt. Integreer Terraform in je CI/CD pipeline zodat wijzigingen via een pull request lopen, gereviewed worden en pas na goedkeuring worden toegepast.
Wanneer Terraform niet de juiste keuze is
Terraform is krachtig maar niet altijd de beste oplossing. Voor kleine projecten met een enkelvoudige omgeving is de overhead van state management en HCL-configuratie mogelijk groter dan de winst. In dat geval zijn lichtere alternatieven zoals Pulumi (waarbij je infrastructuur beschrijft in een reguliere programmeertaal zoals Python of TypeScript) of cloudspecifieke tools zoals AWS CDK een betere keuze. Terraform blinkt uit als je meerdere omgevingen, meerdere providers of een team hebt dat samen infrastructuur beheert en daar consistentie en reproduceerbaarheid in wil.