21 jul 2025·8 min
Terraform en Vagrant: Een brug tussen infrastructuur en levering
Ontdek hoe Mitchell Hashimoto’s HashiCorp-tools—Terraform en Vagrant—teams helpen infrastructuur te standaardiseren en herhaalbare leveringsworkflows op te zetten.
Ontdek hoe Mitchell Hashimoto’s HashiCorp-tools—Terraform en Vagrant—teams helpen infrastructuur te standaardiseren en herhaalbare leveringsworkflows op te zetten.
Herhaalbare levering gaat niet alleen over code uitrollen. Het gaat erom dat je met vertrouwen kunt antwoorden: Wat verandert er? Waarom verandert het? En kunnen we het morgen opnieuw doen? Als infrastructuur met de hand wordt opgebouwd—of ontwikkelaarsmachines in de loop van de tijd afwijken—wordt levering een giswerk: verschillende omgevingen, verschillende resultaten en veel “werkt op mijn laptop.”
Terraform en Vagrant blijven relevant omdat ze die onvoorspelbaarheid van twee kanten verkleinen: gedeelde infrastructuur en gedeelde ontwikkelomgevingen.
Terraform beschrijft infrastructuur (cloudresources, netwerken, managed services en soms zelfs SaaS-configuratie) als code. In plaats van te klikken in een console definieer je wat je wilt, bekijkt je een plan en past je wijzigingen consistent toe.
Het doel is niet “hip zijn.” Het is infrastructuurwijzigingen zichtbaar, reviewbaar en herhaalbaar maken.
Vagrant maakt consistente ontwikkelomgevingen. Het helpt teams dezelfde basisopzet te draaien—OS, pakketten en configuratie—of ze nu op macOS, Windows of Linux werken.
Zelfs als je niet dagelijks virtuele machines gebruikt, blijft het kernidee van Vagrant belangrijk: ontwikkelaars moeten beginnen vanuit een bekende goede omgeving die overeenkomt met hoe de software daadwerkelijk draait.
Dit is een praktische walkthrough gericht op niet-specialisten die minder buzzwords en meer duidelijkheid nodig hebben. We behandelen:
Aan het einde kun je beoordelen of Terraform, Vagrant of beide bij je team passen—en hoe je ze kunt adopteren zonder een nieuwe laag complexiteit te creëren.
Mitchell Hashimoto is vooral bekend als maker van Vagrant en mede-oprichter van HashiCorp. De blijvende bijdrage is niet één product—het is het idee dat tooling de workflow van een team kan vastleggen in iets wat deelbaar, reviewbaar en herhaalbaar is.
Als mensen zeggen “tooling is een brug”, bedoelen ze het overbruggen van de kloof tussen twee groepen die hetzelfde resultaat willen maar verschillende dagelijkse talen spreken:
Hashimoto’s perspectief—weerkaatst in HashiCorp-tools—is dat de brug een workflow is die iedereen kan zien. In plaats van instructies via tickets of tribale kennis over te dragen, leggen teams beslissingen vast in configuratiebestanden, checken die in versiebeheer en draaien dezelfde commando’s in dezelfde volgorde.
Het hulpmiddel wordt de scheidsrechter: het standaardiseert stappen, legt vast wat er veranderde en vermindert “het werkte op mijn machine”-discussies.
Gedeelde workflows veranderen infrastructuur en omgevingen in een productachtige interface:
Deze benadering houdt de focus op levering: tools zijn niet alleen voor automatisering, ze zijn voor afspraak. Terraform en Vagrant passen bij deze denkwijze omdat ze de beoogde staat expliciet maken en praktijken (versiebeheer, review, herhaalbare runs) aanmoedigen die verder gaan dan het geheugen van één persoon.
De meeste pijn in levering wordt niet veroorzaakt door “slechte code.” Het komt door niet-overeenkomende omgevingen en onzichtbare, handmatige stappen die niemand volledig kan beschrijven—totdat er iets kapot gaat.
Teams beginnen vaak met een werkende setup en voeren daarna kleine, redelijke wijzigingen door: een pakketupgrade hier, een firewall-aanpassing daar, een eenmalige hotfix op een server omdat “het dringend is.” Weken later wijken de dev-laptop, de staging-VM en productie allemaal licht van elkaar af.
Die verschillen uiten zich in moeilijk reproduceerbare fouten: tests slagen lokaal maar falen in CI; staging werkt maar productie geeft 500-fouten; een rollback herstelt het vorige gedrag niet omdat het onderliggende systeem veranderd is.
Wanneer omgevingen met de hand worden gemaakt, leeft het echte proces in tribaal geheugen: welke OS-pakketten te installeren, welke services te starten, welke kernelinstellingen te wijzigen, welke poorten te openen—en in welke volgorde.
Nieuwe medewerkers verliezen dagen met het samenstellen van een “goed genoeg” machine. Senior engineers worden een bottleneck voor basisvragen over setup.
De fouten zijn vaak alledaags:
.env-bestand lokaal gekopieerd, maar anders opgehaald in productie—deploys mislukken of, erger, geheimen lekken.Deze problemen vertalen zich naar langzamere onboarding, langere doorlooptijden, verrassingsstoringen en pijnlijke rollbacks. Teams leveren minder vaak, met minder vertrouwen, en besteden meer tijd aan het diagnosticeren van “waarom is deze omgeving anders” dan aan het verbeteren van het product.
Terraform is Infrastructure as Code (IaC): in plaats van te klikken in een cloudconsole en hopen dat je later alles nog weet, beschrijf je je infrastructuur in bestanden.
Die bestanden staan meestal in Git, zodat wijzigingen zichtbaar, reviewbaar en herhaalbaar zijn.
Zie Terraform-configuratie als een “bouwrecept” voor infrastructuur: netwerken, databases, load balancers, DNS-records en permissies. Je documenteert niet wat je achteraf deed—je definieert wat er moet bestaan.
Die definitie is belangrijk omdat ze expliciet is. Als een collega dezelfde omgeving nodig heeft, kan die dezelfde configuratie gebruiken. Als je na een incident een omgeving moet herbouwen, kun je dat uit dezelfde bron doen.
Terraform werkt rond het idee van gewenste staat: je verklaart wat je wilt en Terraform bepaalt welke wijzigingen nodig zijn om daar te komen.
Een typische cyclus ziet er zo uit:
Deze “preview then apply”-aanpak is waar Terraform voor teams uitblinkt: het ondersteunt code review, goedkeuringen en voorspelbare rollouts.
“IaC betekent volledig geautomatiseerd.” Niet per se. Je kunt (en vaak zou je moeten) menselijke checkpoints houden—vooral voor productieveranderingen. IaC gaat over herhaalbaarheid en duidelijkheid, niet over het weghalen van mensen uit het proces.
“Één tool lost alle infrastructuur- en leveringsproblemen op.” Terraform is uitstekend in het provisionen en wijzigen van infrastructuur, maar het vervangt geen goede architectuur, monitoring of operationele discipline. Het beheert ook niet alles even goed, dus het werkt het beste als onderdeel van een breder workflow-beeld.
Vagrant heeft een eenvoudige taak: geef elke ontwikkelaar op aanvraag dezelfde werkende omgeving vanuit één configuratiebestand.
Centraal staat het Vagrantfile, waarin je het basisimage (een “box”), CPU/RAM, netwerk, gedeelde mappen en hoe de machine geconfigureerd moet worden beschrijft.
Omdat het code is, is de omgeving reviewbaar, versioneerbaar en makkelijk te delen. Een nieuwe collega kan de repo clonen, één commando draaien en een voorspelbare setup krijgen met de juiste OS-versie, pakketten, services en defaults.
Containers zijn geweldig om een app en zijn afhankelijkheden te verpakken, maar ze delen de kernel van de host. Daardoor kun je nog steeds verschillen tegenkomen in netwerk, bestandssysteemgedrag, achtergrondservices of OS-niveau tooling—vooral wanneer productie dichter bij een volledige Linux-VM staat dan bij een containerruntime.
Vagrant gebruikt typisch virtuele machines (via providers als VirtualBox, VMware of Hyper-V). Een VM gedraagt zich als een echte computer met een eigen kernel en init-systeem. Daardoor is het beter geschikt wanneer je dingen moet testen die containers niet goed modelleren: systeemservices, kernelinstellingen, iptables-regels, multi-NIC-netwerken of “dit breekt alleen op Ubuntu 22.04” problemen.
Dit is geen wedstrijd: veel teams gebruiken containers voor het packagen van de app en Vagrant voor realistische, volledige-systeem ontwikkeling en testen.
Kortom: Vagrant gaat minder om “virtualisatie om het virtualiseren” en meer om van de dev-omgeving een gedeelde workflow te maken waar het hele team op kan vertrouwen.
Terraform en Vagrant lossen verschillende problemen op, maar samen creëren ze een helder pad van “werkt op mijn machine” naar “draait betrouwbaar voor iedereen.” De brug is parity: het consistent houden van de aannames van de app terwijl de doelomgeving verandert.
Vagrant is de voordeur. Het geeft elke ontwikkelaar een herhaalbare lokale omgeving—zelfde OS, dezelfde pakketten, dezelfde serviceversies—zodat je app vanaf een bekende baseline start.
Terraform is de gedeelde fundering. Het definieert de infrastructuur waarop teams gezamenlijk vertrouwen: netwerken, databases, compute, DNS, load balancers en toegangsregels. Die definitie wordt de bron van waarheid voor test en productie.
De verbinding is simpel: Vagrant helpt je de applicatie te bouwen en valideren in een omgeving die op de werkelijkheid lijkt, en Terraform zorgt dat de werkelijkheid (test/prod) consistent en reviewbaar geprovisioned en gewijzigd wordt.
Je gebruikt niet hetzelfde hulpmiddel voor elk doel—je gebruikt hetzelfde contract.
DATABASE_URL en REDIS_URL.Vagrant handhaaft dat contract lokaal. Terraform handhaaft het in gedeelde omgevingen. De app blijft hetzelfde; alleen de “waar” verandert.
Laptop (Vagrant): Een ontwikkelaar draait vagrant up, krijgt een VM met de app-runtime plus Postgres en Redis. Ze itereren snel en vangen “werkt lokaal”-issues vroeg af.
Test (Terraform): Een pull request werkt Terraform bij om een testdatabase en app-instantie(s) te provisionen. Het team valideert gedrag tegen echte infrastructurele beperkingen.
Productie (Terraform): Dezelfde Terraform-patronen worden toegepast met productie-instellingen—grotere capaciteit, strengere toegang, hogere beschikbaarheid—zonder de setup opnieuw uit te vinden.
Dat is de brug: herhaalbare lokale parity voedt herhaalbare gedeelde infrastructuur, zodat levering een gecontroleerde progressie wordt in plaats van bij elke stap opnieuw uitvinden.
Een solide Terraform/Vagrant-workflow gaat minder over het onthouden van commando’s en meer over het makkelijk reviewen, herhalen en terugdraaien van wijzigingen.
Het doel: een ontwikkelaar kan lokaal starten, een infrastructuurwijziging voorstellen naast een appwijziging en die wijziging met minimale verrassingen door omgevingen heen promoten.
Veel teams houden applicatie en infrastructuur in dezelfde repository zodat het leveringsverhaal coherent blijft:
/app — applicatiecode, tests, buildassets/infra/modules — herbruikbare Terraform-modules (netwerk, database, app-service)/infra/envs/dev, /infra/envs/test, /infra/envs/prod — dunne omgevingslagen/vagrant — Vagrantfile plus provisioning-scripts om "real" afhankelijkheden te spiegelenHet belangrijke patroon is “dunne envs, dikke modules”: omgevingen kiezen vooral inputs (grootte, aantallen, DNS-namen), terwijl gedeelde modules de feitelijke resource-definities bevatten.
Een eenvoudige trunk-based aanpak werkt goed: kortlevende featurebranches, gemerged via pull request.
Eis in review twee artefacten:
terraform fmt, validate en produceert een terraform plan-output voor de PR.Reviewers moeten kunnen antwoorden op “Wat zal er veranderen?” en “Is het veilig?” zonder alles lokaal te moeten reproduceren.
Promoot dezelfde set modules van dev → test → prod en houd verschillen expliciet en klein:
Vermijd het kopiëren van hele directories per omgeving. Promoot liever door variabelen te wijzigen, niet door resource-definities te herschrijven.
Wanneer een appwijziging nieuwe infrastructuur vereist (bijv. een queue of nieuwe config), lever ze dan in dezelfde PR zodat ze als één geheel worden beoordeeld.
Als infrastructuur gedeeld wordt door veel services, behandel modules als producten: versioneer ze (tags/releases) en documenteer inputs/outputs als contract. Zo kunnen teams updaten met beleid in plaats van per ongeluk naar “wat dan ook de nieuwste is” te drijven.
Terraform’s superkracht is niet alleen dat het infrastructuur kan creëren—het is dat het die veilig over tijd kan wijzigen. Daarvoor heeft het geheugen nodig van wat het gebouwd heeft en wat het denkt dat bestaat.
Terraform state is een bestand (of opgeslagen data) dat je configuratie koppelt aan echte resources: welke database-instantie bij welke aws_db_instance hoort, wat het ID is en welke instellingen laatst zijn toegepast.
Zonder state zou Terraform moeten raden wat er bestaat door alles opnieuw te scannen, wat traag, onbetrouwbaar en soms onmogelijk is. Met state kan Terraform een plan berekenen: wat wordt toegevoegd, gewijzigd of vernietigd.
Omdat state resource-identifiers en soms waarden kan bevatten die je liever niet openbaar maakt, moet het behandeld worden als een credential. Als iemand het kan lezen of wijzigen, kan die invloed uitoefenen op wat Terraform verandert.
Drift ontstaat wanneer infrastructuur buiten Terraform om verandert: een console-aanpassing, een hotfix om 2 uur 's nachts of een geautomatiseerd proces dat instellingen wijzigt.
Drift maakt toekomstige plannen verrassend: Terraform probeert mogelijk de handmatige wijziging te "ongedaan te maken", of faalt omdat aannames niet meer kloppen.
Teams slaan state meestal remote op (in plaats van op één laptop) zodat iedereen plannen en applies tegen dezelfde bron van waarheid uitvoert. Een goede remote setup ondersteunt ook:
Veilige levering is meestal saai: één state, gecontroleerde toegang en wijzigingen die via reviewbare plannen lopen.
Terraform wordt echt krachtig wanneer je stopt met het kopiëren van dezelfde blokken tussen projecten en gemeenschappelijke patronen verpakt in modules.
Een module is een herbruikbaar pakket Terraform-code dat inputs neemt (zoals een VPC CIDR-range of instancegrootte) en outputs produceert (zoals subnet IDs of een database-endpoint). Het voordeel is minder duplicatie, minder "snowflake"-setups en snellere levering omdat teams kunnen starten vanaf een bekende goede bouwsteen.
Zonder modules dreigt infrastructuurcode te vervallen in copy/paste-varianten: het ene repo past security group-regels aan, een ander vergeet encryptie-instellingen, een derde gebruikt een andere provider-versie.
Een module creëert één plek om een beslissing vast te leggen en in de tijd te verbeteren. Reviews worden ook eenvoudiger: in plaats van elke keer 200 regels networking te herauditen, review je een kleine module-interface (inputs/outputs) en verandert de module wanneer hij evolueert.
Goede modules standaardiseren de vorm van een oplossing en laten ruimte voor betekenisvolle verschillen.
Voorbeelden van patronen die de moeite waard zijn om te modulariseren:
Vermijd het coderen van elke mogelijke optie. Als een module 40 inputs nodig heeft om bruikbaar te zijn, probeert hij waarschijnlijk te veel use-cases te dienen. Geef de voorkeur aan verstandige defaults en een kleine set beleidskeuzes (encryptie aan, verplichte tags, goedgekeurde instance-families) en houd escape-hatches zeldzaam en expliciet.
Modules kunnen een doolhof worden als iedereen net iets andere versies publiceert ("vpc-basic", "vpc-basic2", "vpc-new"). Sprawl ontstaat meestal door gebrek aan duidelijke eigenaar, geen versiebeleid en geen richtlijn wanneer je een nieuwe module maakt versus een bestaande verbetert.
Praktische richtlijnen:
Goed uitgevoerd maken modules van Terraform een gedeelde workflow: teams gaan sneller omdat de “juiste manier” verpakt, vindbaar en herhaalbaar is.
Terraform en Vagrant maken omgevingen reproduceerbaar—maar ze maken fouten ook reproduceerbaar. Een enkele gelekte token in een repo kan zich verspreiden over laptops, CI-jobs en productie.
Een paar eenvoudige gewoonten voorkomen de meeste veelvoorkomende fouten.
Behandel “wat te bouwen” (configuratie) en “hoe te authenticeren” (geheimen) als aparte zorgen.
Infrastructuurdefinities, Vagrantfiles en module-inputs moeten resources en instellingen beschrijven—niet wachtwoorden, API-sleutels of private certificaten. Haal geheimen in plaats daarvan tijdens runtime uit een bewezen secret store (een dedicated vault-service, de secret manager van je cloud of een streng gecontroleerde CI-secret store). Dit houdt je code reviewbaar en je gevoelige waarden auditbaar.
Geef elke actor alleen de permissies die nodig zijn:
terraform plan kan uitvoeren, hoeft niet automatisch toestemming te hebben om productie-wijzigingen toe te passen. Gebruik rolscheiding zodat goedkeuring en uitvoering niet altijd dezelfde persoon zijn.Vermijd het embedden van credentials in code, lokale dotfiles die rondgekopieerd worden of gedeelde “teamkeys.” Gedeelde geheimen wissen verantwoording.
Deze richtlijnen vertragen levering niet—ze beperken de blast radius als er iets misgaat.
CI/CD is waar Terraform ophoudt een "iets dat één persoon draait" te zijn en een teamworkflow wordt: elke wijziging is zichtbaar, reviewbaar en op dezelfde manier toepasbaar.
Een praktisch basisniveau bestaat uit drie stappen, gekoppeld aan je pull requests en deployment-goedkeuringen:
terraform fmt -check en terraform validate om voor de hand liggende fouten vroeg te vangen.terraform plan en publiceer de output naar de PR (als artefact of comment). Reviewers moeten kunnen beantwoorden: Wat zal er veranderen? Waar? Waarom?terraform apply met exact dezelfde codeversie die het plan produceerde.# Example (GitHub Actions-style) outline
# - fmt/validate on PR
# - plan on PR
# - apply on manual approval
Het belangrijke is scheiding: PRs produceren bewijs (plannen), goedkeuringen autoriseren verandering (applies).
Vagrant vervangt CI niet, maar het kan lokaal testen CI-waardig laten aanvoelen. Als een bugrapport zegt “werkt op mijn machine”, laat een gedeeld Vagrantfile iedereen exact dezelfde OS, pakketten en serviceversies booten om het te reproduceren.
Dat is vooral nuttig voor:
Als je team leveringsworkflows standaardiseert, werken tools zoals Terraform en Vagrant het beste in combinatie met consistente applicatie-schaalering en herhaalbare releasestappen.
Koder.ai kan hier helpen als vibe-coding platform: teams kunnen een werkende web/backend/mobile basis genereren vanuit chat en vervolgens de broncode exporteren en die in dezelfde Git-gebaseerde workflow pluggen (inclusief Terraform-modules en CI plan/apply-poorten). Het is geen vervanging voor Terraform of Vagrant; het verkort de time-to-first-commit terwijl je infrastructuur- en omgevingpraktijken expliciet en reviewbaar blijven.
Om te voorkomen dat automatisering per ongeluk gevaarlijk wordt:
Met deze richtlijnen ondersteunen Terraform en Vagrant hetzelfde doel: wijzigingen die je kunt uitleggen, herhalen en vertrouwen.
Zelfs goede tools kunnen nieuwe problemen creëren als ze als "set and forget" worden behandeld. Terraform en Vagrant werken het beste wanneer je scope duidelijk houdt, een paar guardrails toepast en de neiging weerstaat om elk detail te modelleren.
Langdurige drift: infrastructuurwijzigingen “gewoon deze ene keer” in een cloudconsole kunnen stilletjes afwijken van Terraform. Maanden later wordt de volgende apply risicovol omdat Terraform de werkelijkheid niet meer beschrijft.
Te complexe modules: modules zijn geweldig voor hergebruik, maar kunnen veranderen in een doolhof—tientallen variabelen, geneste modules en “magische” defaults die maar één persoon begrijpt. Het resultaat is tragere levering, niet sneller.
Trage lokale VMs: Vagrant-boxen kunnen in de loop van de tijd zwaarder worden (grote images, te veel services, trage provisioning). Ontwikkelaars slaan de VM over en de "herhaalbare omgeving" wordt optioneel—totdat er iets in productie breekt.
Behoud Vagrant als je een volledig OS-niveau omgeving nodig hebt die productiegedrag nabootst (system services, kernelverschillen, netwerkcuriosa) en je team profiteert van een consistente "known good" baseline.
Stap over op containers wanneer je app goed in Docker draait, je snellere opstarttijd wilt en je geen volledige VM-kernelgrens nodig hebt. Containers verminderen vaak het probleem "mijn VM is traag".
Gebruik beide wanneer je een VM nodig hebt om de host te emuleren (of ondersteunende infrastructuur te draaien), maar de app zelf in containers draait binnen die VM. Dit kan realisme en snelheid combineren.
Aanbevolen links: /blog/terraform-workflow-checklist, /docs, /pricing
Terraform maakt infrastructuurwijzigingen expliciet, reviewbaar en herhaalbaar. In plaats van te vertrouwen op consoleklikken of runbooks commit je configuratie naar versiebeheer, gebruik je terraform plan om de impact te bekijken en pas je wijzigingen consistent toe.
Het is vooral waardevol wanneer meerdere mensen gedeelde infrastructuur over tijd moeten begrijpen en veilig moeten kunnen wijzigen.
Vagrant geeft ontwikkelaars een bekende, consistente OS-niveau omgeving vanuit één Vagrantfile. Dat verkort onboarding, voorkomt drift van het "werkt op mijn laptop"-type en helpt bugs te reproduceren die afhankelijk zijn van OS-pakketten, services of netwerkgedrag.
Het is bijzonder handig wanneer je productieaannames meer op een VM lijken dan op een container.
Gebruik Vagrant om de lokale omgeving te standaardiseren (OS, services, defaults). Gebruik Terraform om gedeelde omgevingen te standaardiseren (netwerken, databases, compute, DNS, permissies).
De verbindende gedachte is een stabiel “contract” (poorten, env vars zoals DATABASE_URL, beschikbaarheid van services) dat consistent blijft wanneer je van laptop → test → productie gaat.
Begin met een structuur die herbruikbare bouwblokken scheidt van omgevingsspecifieke instellingen:
/infra/modules/infra/envs/dev, /infra/envs/prod)/vagrantZo wordt promotie tussen omgevingen meestal een , niet een copy/paste-herschrijving.
Terraform “state” is hoe Terraform onthoudt welke echte resources bij je configuratie horen. Zonder state kan Terraform niet betrouwbaar veilige wijzigingen berekenen.
Behandel state als een credential:
Drift ontstaat wanneer echte infrastructuur buiten Terraform om verandert (console-aanpassingen, noodhotfixes, geautomatiseerde tweaks). Het maakt toekomstige plannen verrassend en kan ertoe leiden dat Terraform wijzigingen probeert terug te draaien of faalt.
Praktische manieren om drift te beperken:
Gebruik modules om veelvoorkomende patronen te standaardiseren (netwerken, databases, service-deploys) zonder code te dupliceren. Goede modules hebben:
Vermijd modules met 40 variabelen tenzij het echt nodig is—complexiteit kan levering vertragen in plaats van versnellen.
Houd configuratie en geheimen gescheiden:
Vagrantfileplan vs apply, en strengere controles voor productieHoud er ook rekening mee dat state gevoelige identifiers kan bevatten en bescherm dit dienovereenkomstig.
Een minimale pipeline die schaalbaar is:
terraform fmt -check + terraform validateterraform plan output voor reviewterraform apply uit met precies dezelfde revisie die het plan heeft gegenereerdDit houdt wijzigingen auditbaar: reviewers kunnen antwoorden op “wat verandert er?” voordat er iets gebeurt.
Behoud Vagrant als je nodig hebt:
Overweeg containers voor snellere opstarttijden als je app goed in Docker draait en je geen VM-niveau gedrag nodig hebt. Veel teams gebruiken beide: containers voor de app, Vagrant voor een productie-achtig hostmilieu.