Terraform vs. Ansible: Welke heb je eigenlijk nodig?

Mensen die nieuw zijn bij Infrastructure as Code stellen dit meestal op een van twee manieren: "welk tool moet ik eerst leren" of "waarom gebruiken teams beide." Het korte antwoord is dat Terraform en Ansible verschillende problemen oplossen, en de meeste productieomgevingen gebruiken ze samen in plaats van er één te kiezen.

Waar Terraform werkelijk voor is

Terraform is een provisioning tool. Het declareert welke infrastructuur zou moeten bestaan: een VPC, drie EC2-instanties, een RDS-database, een S3-bucket met een specifiek beleid. Je schrijft HCL die de eindtoestand beschrijft, voert terraform plan uit om te zien wat er zal veranderen, en dan terraform apply om het te doen. Terraform houdt een state file bij (lokaal of in een backend zoals een S3-bucket met DynamoDB-locking) die je config toewijst aan echte resource-ID's bij de cloudprovider.

De sterkte hier is dependency resolution over providers heen. Als je Terraform vertelt een security group te maken en deze vervolgens aan een EC2-instantie te koppelen, berekent het automatisch de volgorde. Het werkt ook over AWS, Azure, GCP, Cloudflare, Datadog en tientallen andere providers via dezelfde workflow, wat belangrijk is als je infrastructuur meer dan één vendor omvat.

Terraform is slecht in alles wat op de machine gebeurt zodra deze bestaat. Het installeert geen pakketten, bewerkt geen config files of herstart services op een betekenisvolle manier. Provisioners zoals remote-exec bestaan, maar HashiCorp zelf raadt aan ze te vermijden voor iets anders dan bootstrapping.

Waar Ansible werkelijk voor is

Ansible is een configuration management tool. Het maakt verbinding via SSH (of WinRM voor Windows) en voert taken uit op machines die al bestaan: nginx installeren, een config file templaten, een gebruiker maken, een service herstarten, ervoor zorgen dat een cron job aanwezig is. Playbooks zijn YAML, en modules zijn van ontwerp idempotent, dus dezelfde playbook twee keer uitvoeren mag de tweede keer niets veranderen als het systeem al in de gewenste staat is.

Ansible hoeft geen agents op doelmachines geïnstalleerd te hebben, alleen Python en SSH-toegang, wat het makkelijk maakt om aan bestaande infrastructuur vast te plakken. Het is ook geschikt voor orchestratietaken die niet strikt "provisioning" zijn — rolling restarts over een vloot heen, blue-green deploy-stappen, een databasemigratie op één host uitvoeren en vervolgens een load balancer bijwerken.

Waar ze overlappen en waar mensen verward raken

Beiden tools kunnen technisch gezien wat van elkaars werk doen. Ansible heeft cloud modules (amazon.aws.ec2_instance, azure.azcollection.azure_rm_virtualmachine) die infrastructuur kunnen opstarten. Terraform heeft provisioners die shell-commando's op een nieuwe instantie kunnen uitvoeren. Maar Ansible gebruiken voor provisioning betekent dat je Terraform's state tracking en plan/diff workflow opgeeft, en Terraform provisioners gebruiken voor configuratie betekent dat je idempotente, herhaalbare configuratiebeheer opgeeft.

De praktische verdeling waar de meeste teams op uitkomen:

• Terraform bouwt de infrastructuur: netwerken, compute-instanties, load balancers, beheerde databases, IAM-rollen.
• Ansible configureert wat erop staat: software-installaties, gebruikers, config files, servicetoestand, stappen voor applicatiedeployment.

Een concreet voorbeeld van de overdracht

Stel je voor dat je drie webservers achter een load balancer op AWS opricht.

resource "aws_instance" "web" {
  count         = 3
  ami           = data.aws_ami.ubuntu.id
  instance_type = "t3.medium"
  tags = { Name = "web-${count.index}" }
}

output "web_ips" {
  value = aws_instance.web[*].public_ip
}

Terraform maakt de instanties aan en voert hun IP's uit. Je kunt die output in een dynamische Ansible-inventaris voeren (de amazon.aws.aws_ec2 inventory plugin leest EC2-tags rechtstreeks, geen handmatig copy-paste nodig) en voer dan uit:

ansible-playbook -i aws_ec2.yml site.yml

waar site.yml nginx installeert, de app config inzet en de service start. Terraform raakt nginx nooit aan. Ansible raakt de VPC nooit aan. Elk tool blijft in zijn spoor, en elk heeft zijn eigen state/idempotency model dat niet conflicteert met het model van de ander.

Veelgemaakte fouten die je moet vermijden

Terraform state in git opslaan is de meest voorkomende vroege fout — state files kunnen secrets in plaintext bevatten en merge conflicts veroorzaken die je infrastructuurmodel corrumperen. Gebruik van dag één een remote backend.

Bij Ansible is de fout playbooks schrijven die eigenlijk niet idempotent zijn — shell of command modules gebruiken voor dingen die een eigen module hebben (ansible.builtin.apt, ansible.builtin.copy, ansible.builtin.systemd) die al de check-then-act logica correct afhandelen.

Als je beslist wat je eerst leert: leer Terraform als je cloud provisioning en multi-environment setups doet, leer Ansible als je config drift op servers die je al hebt beheert. De meeste DevOps-rollen verwachten vertrouwdheid met beide binnen het eerste jaar.

Voor meer informatie over state management, dynamische inventarissen en het bouwen van een volledige CI/CD-pipeline rond deze tools, bekijk de gerelateerde DevOps- en Cloud-segmenten op Korra Studio.