Ansible vs Terraform 2026: Infrastructure as Code en DevOps Sollicitatievragen

Uitgebreide vergelijking van Ansible en Terraform voor DevOps sollicitatiegesprekken. State management, declaratieve vs procedurele benaderingen en best practices voor Infrastructure as Code.

Ansible vs Terraform 2026 - Infrastructure as Code Vergelijking

Ansible vs Terraform is een van de meest voorkomende vergelijkingsvragen in DevOps sollicitatiegesprekken, maar de vraagstelling zelf onthult een misverstand: deze tools lossen verschillende problemen op. Ansible 2.20 verzorgt configuration management en application deployment, terwijl Terraform 1.15 infrastructuurresources provisioneert. Begrijpen wanneer elke tool uitblinkt, waar ze overlappen en hoe ze elkaar aanvullen, onderscheidt Senior DevOps Engineers van beginners.

Het Kernonderscheid

Terraform beheert infrastructure state declaratief (VM's, netwerken, databases). Ansible configureert procedureel wat er op die infrastructuur draait (packages, services, bestanden). De meeste productieomgevingen gebruiken beide.

Declaratief vs Procedureel: Het Fundamentele Verschil

Terraform gebruikt een declaratieve benadering. Een configuratiebestand beschrijft de gewenste eindtoestand, en Terraform berekent de noodzakelijke wijzigingen om die te bereiken. Dit werkt goed voor infrastructuur die als eenheid moet worden gecreëerd, gewijzigd of vernietigd.

hcl
# main.tf
resource "aws_instance" "web" {
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "t3.medium"
  
  tags = {
    Name        = "web-server"
    Environment = "production"
  }
}

resource "aws_security_group" "web" {
  name        = "web-sg"
  description = "Allow HTTP and HTTPS"
  
  ingress {
    from_port   = 443
    to_port     = 443
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }
}

Het uitvoeren van terraform apply creëert beide resources als ze niet bestaan, of werkt ze bij om overeen te komen met de configuratie. Het opnieuw uitvoeren zonder wijzigingen produceert geen operaties: Terraform vergelijkt de configuratie met het state bestand en vindt niets te doen.

Ansible gebruikt een procedurele benadering met tasks die in volgorde worden uitgevoerd. Hoewel Ansible modules vaak idempotent zijn (twee keer uitvoeren produceert hetzelfde resultaat), beschrijft het playbook zelf een reeks acties in plaats van een eindtoestand.

yaml
# webserver.yml
- name: Configure web server
  hosts: webservers
  become: true
  
  tasks:
    - name: Install nginx
      ansible.builtin.apt:
        name: nginx
        state: present
        update_cache: true
    
    - name: Copy nginx configuration
      ansible.builtin.template:
        src: nginx.conf.j2
        dest: /etc/nginx/nginx.conf
      notify: Restart nginx
    
    - name: Ensure nginx is running
      ansible.builtin.service:
        name: nginx
        state: started
        enabled: true
  
  handlers:
    - name: Restart nginx
      ansible.builtin.service:
        name: nginx
        state: restarted

Elke task wordt sequentieel uitgevoerd. Het notify/handler patroon biedt enig declaratief gedrag: de handler draait slechts één keer aan het einde, ongeacht hoeveel tasks hem triggeren.

State Management: Een Kritisch Sollicitatieonderwerp

Terraform onderhoudt een state bestand dat configuratie mapt naar echte resources. Deze state houdt resource ID's, afhankelijkheden en metadata bij. Zonder dit kan Terraform niet bepalen wat bestaat of wat moet worden gewijzigd.

AspectTerraformAnsible
State opslagVereist (lokaal bestand of remote backend)Geen standaard
Drift detectieIngebouwd via terraform planVereist expliciete controles
Resource trackingAutomatisch via stateInventory-gebaseerd
RollbackVernietigen en opnieuw creëren vanuit stateGeen native rollback

Ansible heeft geen equivalent state bestand. Het verbindt met doelsystemen en voert tasks uit, vertrouwend op de huidige systeemtoestand en module idempotentie. Dit maakt Ansible eenvoudiger om mee te beginnen maar moeilijker om wijzigingen over tijd te volgen.

Een veelgestelde sollicitatievraag gaat over state bestand beveiliging. Terraform state kan gevoelige data bevatten: databasewachtwoorden, API keys, resource identifiers. Productie deployments slaan state op in remote storage (S3, Azure Blob, Terraform Cloud) met encryptie en toegangscontroles.

hcl
# backend.tf
terraform {
  backend "s3" {
    bucket         = "company-terraform-state"
    key            = "prod/infrastructure.tfstate"
    region         = "us-east-1"
    encrypt        = true
    dynamodb_table = "terraform-locks"
  }
}

De DynamoDB tabel voorziet in locking, waardoor wordt voorkomen dat twee engineers tegelijkertijd de state wijzigen.

Wanneer Welke Tool Gebruiken

Terraform blinkt uit in het provisioneren van cloud infrastructuur: virtuele machines, managed databases, load balancers, IAM rollen, VPC's. Het handelt automatisch afhankelijkheden tussen resources af en ondersteunt alle grote cloud providers via een consistente HCL syntax.

Ansible blinkt uit in het configureren van bestaande systemen: installeren van packages, beheren van gebruikers, deployen van applicatiecode, orchestreren van multi-stap deployments. Het verbindt via SSH (of WinRM voor Windows) zonder agents op de doelsystemen te vereisen.

De overlap zone veroorzaakt verwarring. Beide kunnen software op een VM installeren. Terraform kan provisioners gebruiken om scripts uit te voeren na resource creatie. Ansible kan cloud resources creëren via modules zoals amazon.aws.ec2_instance. Maar het gebruik van elke tool buiten zijn sterkte leidt tot onderhoudsproblemen.

Vermijd Dit Anti-Pattern

Extensief gebruik van Terraform provisioners voor configuration management creëert fragiele infrastructuur. Provisioners draaien alleen bij creatie, niet bij volgende applies. Gebruik Terraform voor infrastructuur, draag dan over aan Ansible voor configuratie.

De Gecombineerde Workflow in Productie

De meeste organisaties gebruiken beide tools samen. Terraform provisioneert de infrastructuur en output verbindingsdetails. Ansible consumeert deze outputs om de systemen te configureren.

hcl
# outputs.tf
output "web_server_ips" {
  value       = aws_instance.web[*].private_ip
  description = "Private IPs of web servers"
}

output "db_endpoint" {
  value       = aws_rds_instance.main.endpoint
  description = "RDS endpoint for application config"
}

Een CI/CD pipeline draait eerst Terraform, vangt outputs op, genereert dynamisch een Ansible inventory, en draait dan playbooks tegen de nieuwe infrastructuur.

yaml
# ansible/inventory/aws_ec2.yml
plugin: amazon.aws.aws_ec2
regions:
  - us-east-1
filters:
  tag:Environment: production
  instance-state-name: running
hostnames:
  - private-ip-address
groups:
  webservers: "'web' in tags.Role"
  databases: "'db' in tags.Role"

Deze dynamische inventory bevraagt AWS direct, groepeert instances op hun tags. Geen handmatig IP beheer vereist.

Klaar om je DevOps gesprekken te halen?

Oefen met onze interactieve simulatoren, flashcards en technische tests.

OpenTofu: De Fork Die Het Landschap Veranderde

HashiCorp heeft Terraform in augustus 2023 onder de Business Source License (BSL) geplaatst. De community reageerde door Terraform 1.5 te forken naar OpenTofu, nu gehost onder de Linux Foundation.

Per augustus 2026 blijft OpenTofu 1.11.6 een drop-in vervanging voor de meeste Terraform workflows. Dezelfde HCL syntax, hetzelfde provider ecosysteem, hetzelfde state formaat. OpenTofu heeft features toegevoegd die niet aanwezig zijn in Terraform's open-source binary: state encryptie, provider for_each, en early variable evaluation.

Voor sollicitatievoorbereiding is het belangrijk het licentieonderscheid te begrijpen. BSL staat intern gebruik toe maar beperkt het bouwen van concurrerende producten. Organisaties bezorgd over vendor lock-in of met specifieke compliance vereisten kunnen de voorkeur geven aan OpenTofu's MPL 2.0 licentie. IBM's overname van HashiCorp in december 2024 voegde nog een variabele toe aan discussies over leveranciersrelaties.

Veelgestelde DevOps Sollicitatievragen

Vraag: Kan Ansible Terraform vervangen?

Niet effectief. Ansible kan cloud resources creëren, maar mist state management. Het twee keer draaien van hetzelfde playbook kan dubbele resources creëren. Terraform's state bestand houdt bij wat bestaat en berekent minimale wijzigingen. Gebruik Ansible voor waar het het beste in is: configuration management.

Vraag: Hoe worden secrets afgehandeld in Terraform?

Commit nooit secrets naar version control. Gebruik omgevingsvariabelen, Vault integratie, of cloud provider secret managers. Markeer variabelen als sensitive om te voorkomen dat ze in logs verschijnen:

hcl
# variables.tf
variable "db_password" {
  type        = string
  sensitive   = true
  description = "Database password from Vault or environment"
}

Vraag: Wat is Ansible idempotentie?

Een idempotente operatie produceert hetzelfde resultaat of deze nu één keer of meerdere keren wordt uitgevoerd. De apt module met state: present installeert een package als het ontbreekt en doet niets als het al geïnstalleerd is. Het schrijven van idempotente playbooks voorkomt onbedoelde wijzigingen bij volgende runs.

Vraag: Hoe wordt Infrastructure code getest?

Terraform: terraform validate controleert syntax, terraform plan toont wijzigingen in preview, en tools zoals Terratest draaien integratietests. Ansible: ansible-lint vangt problemen, --check modus voert dry runs uit, en Molecule test roles tegen containers.

Voor diepere Terraform sollicitatievoorbereiding, zie Terraform Interview Questions: Infrastructure as Code Complete Guide. Praktische oefeningen met Terraform Basics en Ansible Configuration Management modules.

Versie Compatibiliteit en Ecosysteem

Huidige stabiele versies per augustus 2026:

ToolVersieReleasedatumHoofdfeature
Ansible2.20.5April 2026Verbeterd collection management
Terraform1.15.8Juli 2026Windows ARM64 support, convert function
OpenTofu1.11.6April 2026State encryptie, provider for_each

Ansible's collection architectuur scheidt kernfunctionaliteit van provider-specifieke modules. De amazon.aws collection ontvangt updates onafhankelijk van Ansible core. Dit is relevant voor version pinning in CI/CD pipelines.

Terraform's provider versioning volgt vergelijkbare principes. Lock bestanden (terraform.lock.hcl) zorgen voor consistente provider versies tussen teamleden en CI systemen.

hcl
# versions.tf
terraform {
  required_version = ">= 1.15.0"
  
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.60"
    }
  }
}

Kiezen Tussen Beide: Een Beslissingsframework

De vraag is zelden Ansible of Terraform. De vraag is welke tool welke verantwoordelijkheid draagt.

Use CaseAanbevolen Tool
Provisioneren VM's, databases, netwerkenTerraform
OS configureren, packages installerenAnsible
Kubernetes resources beherenTerraform of kubectl/Helm
Applicatiecode deployenAnsible of CI/CD native
IAM rollen en policies creërenTerraform
Gebruikersaccounts op servers beherenAnsible
Monitoring infrastructuur opzettenTerraform (resources creëren) + Ansible (agents configureren)

Voor een compleet beeld van hoe deze tools passen in moderne deployment workflows, zie CI/CD Pipeline Interview Questions.

Wat Senior Engineers Moeten Weten Over Ansible en Terraform

  • Terraform beheert infrastructure state declaratief; Ansible configureert systemen procedureel. Beide samen gebruiken produceert onderhoudbare infrastructuur.
  • State bestand beveiliging is belangrijk. Sla Terraform state remote op met encryptie en locking ingeschakeld.
  • OpenTofu biedt een MPL-gelicenseerd alternatief voor Terraform met extra features. Migratie is eenvoudig voor de meeste workflows.
  • Idempotentie is niet automatisch. Schrijf playbooks die consistente resultaten produceren bij herhaalde runs.
  • Dynamische inventory elimineert handmatig host beheer. Bevraag cloud providers direct voor huidige infrastructuur.
  • Version pinning voorkomt verrassingen. Lock provider versies in Terraform; pin collection versies in Ansible.
  • Het testen van Infrastructure code vereist verschillende benaderingen: terraform plan voor het bekijken van wijzigingen, --check modus voor Ansible dry runs, integratie test frameworks voor beide.

Begin met oefenen!

Test je kennis met onze gespreksimulatoren en technische tests.

Dagelijkse challenge

Zie jij de bug in DevOps?

Een echt codefragment, een verborgen bug, één poging per dag. Zonder account uit te proberen.

Anthony Fillion-Maillet

Geschreven door

Anthony Fillion-Maillet

Oprichter van SharpSkill

Al meer dan 10 jaar fullstack-ontwikkelaar. Hij leidt SharpSkill en staat in voor alles wat hier verschijnt.

Bijgewerkt op 22 augustus 2026

Tags

#ansible
#terraform
#infrastructure-as-code
#devops
#interview

Delen

Gerelateerde artikelen