Voorkomen en oplossen van infrastructure drift in Terraform voor Azure

By Mirko Peters · 2026-10-28

Lees hoe infrastructure drift ontstaat in Terraform en Azure, hoe noodfixes via de portal statebestanden breken, en hoe je afwijkingen veilig opspoort en corrigeert.

Automatically translated with AI from the original post. Read the English original

Infrastructure drift is een van de meest voorkomende en gevaarlijke stille killers in moderne cloudomgevingen. Wanneer engineers in noodsituaties handmatig wijzigingen doorvoeren in de Azure-portal, verbreken ze stilletjes de synchronisatie met de coderepositories. Deze uitgebreide gids beschrijft hoe drift ontstaat, welke risico's het oplevert voor je statebestanden, en hoe je afwijkingen systematisch opspoort en herstelt zonder productie-uitval te veroorzaken.

Belangrijkste punten

• Infrastructure drift ontstaat wanneer handmatige wijzigingen in de cloudconsole afwijken van je gedeclareerde Terraform-code.
• Noodfixes die rechtstreeks in productie worden doorgevoerd, omzeilen versiebeheer en veroorzaken stille storingen bij latere normale plan-runs.
• Terraform-statebestanden fungeren als geheugenbrug en vergelijken je geschreven configuratie, de vorige state en de werkelijke cloudresources.
• Vroeg detecteren van drift vraagt om regelmatige geautomatiseerde plan-runs en een strikt beleid tegen ongedocumenteerde handmatige portalwijzigingen.
• Drift oplossen betekent kiezen of je de live omgeving terugzet naar de code, of je configuratie aanpast aan de werkelijkheid.

Wat is Infrastructure Drift en waarom ontstaat het?

Zelfs de meest gedisciplineerde cloudengineeringteams worden uiteindelijk door infrastructure drift getroffen. Drift is elke ongeautoriseerde, ongedocumenteerde of noodwijziging aan cloudresources die buiten je geautomatiseerde pipelines om een staat beheert. Stel je een engineer voor die midden in de nacht wordt opgeroepen voor een incident. Onder druk logt hij in op de Azure-console, verhoogt hij een limiet voor auto-scaling van vijf naar tien instanties, lost hij het probleem op en gaat hij weer slapen.

Het probleem is dat het versiebeheerde configuratiebestand in je repository nog steeds vijf zegt. De live cloudomgeving zegt tien. Omdat niemand de wijziging heeft gedocumenteerd of de code heeft bijgewerkt, ontstaat er een grote kloof tussen je beoogde architectuur en de werkelijkheid. Die kloof blijft weken verborgen totdat iemand een routinematige Terraform-plan draait voor een volstrekt andere wijziging. Plotseling knippert in de terminal een waarschuwing dat Terraform die instanties weer terug wil schalen naar vijf.

De menselijke factor en operationele druk

Drift is zelden kwaadwillend; het ontstaat vrijwel altijd uit operationele urgentie. Wanneer productieomgevingen uitvallen, zegt de menselijke instinct dat engineers het probleem onmiddellijk moeten verhelpen met de snelste tool die voorhanden is. Point-and-click provisioning in de Azure-portal is snel, tastbaar en direct. Maar elke keer dat een engineer de portal gebruikt om een probleem te verhelpen zonder dat dit in code wordt vastgelegd, creëert hij technische schuld die later met rente moet worden afgelost.

Hoe de Terraform-state afwijkingen herkent

Om te begrijpen hoe Terraform drift opspoort, moet je goed kijken naar het geheugenmechanisme: het statebestand. Het statebestand van Terraform fungeert als dé bron van waarheid en koppelt je cloudresources aan je configuratiebestanden. Wanneer je een commando uitvoert, pusht Terraform niet zomaar bestanden naar de cloud. In plaats daarvan voert het een driewegvergelijking uit.

Ten eerste leest het wat je in je configuratiebestanden hebt geschreven. Ten tweede inspecteert het wat het tijdens de laatste geslaagde apply in het statusbestand heeft vastgelegd. Ten derde benadert het de API van de cloudprovider via plugins en controleert het wat er op dit moment daadwerkelijk in je abonnement bestaat. Wanneer deze drie elementen niet overeenkomen, beseft Terraform dat de werkelijkheid stilletjes is veranderd.

Het gevaar van genegeerde waarschuwingen

Tijdens een plan-uitvoering genereert Terraform een gedetailleerde uitvoer met toevoegingen, wijzigingen en verwijderingen. Wanneer er sprake is van drift, zie je vaak waarschuwingen die aangeven dat een resource moet worden gewijzigd of zelfs volledig vervangen. Beginners raken vaak in paniek wanneer ze waarschuwingen zien over geforceerde vervanging van resources. Deze waarschuwing is geen fout. Terraform laat je weten dat de live resource zodanig is veranderd dat hij niet meer herkenbaar is, en dat hij om hem weer in lijn te brengen met je code moet worden verwijderd en opnieuw aangemaakt.

Best practices voor het detecteren en voorkomen van drift

Drift voorkomen vraagt om een combinatie van organisatorische kaders en geautomatiseerde technische maatregelen. Als je drift-detectie volledig overlaat aan handmatige controles, krijg je onvermijdelijk pijnlijke productie-storingen. Dit zijn de basisstrategieën die teams gebruiken om hun cloudomgevingen op één lijn te houden:

• Dwing alleen-lezentoegang af: Haal schrijfrechten in productie weg bij gebruikers. Laat alle infrastructuurwijzigingen verlopen via je CI/CD-pipelines en pull request-reviews.
• Plan geautomatiseerde plan-runs in: Richt continue integratiepipelines in die regelmatig 'terraform plan'-commando's uitvoeren zonder ze toe te passen. Controleer de uitvoer op onverwachte wijzigingen.
• Splits monolithische statusbestanden op: Verdeel grote omgevingen in kleinere, modulaire componenten. Kleinere statusbestanden maken drift makkelijker te isoleren, te beoordelen en te herstellen.
• Implementeer remote state-locking: Zorg dat je team veilige remote backends met state-locking gebruikt, zodat gelijktijdige runs de statusregistratie niet beschadigen.

Drift herstellen wanneer het zich voordoet

Wanneer je ontdekt dat je live infrastructuur is afgeweken van je configuratie, sta je voor een strategische keuze. Je hebt twee primaire opties om het te herstellen:

De eerste optie is Terraform de live omgeving laten overschrijven. Door je standaard 'terraform apply' uit te voeren, dwing je Azure om terug te keren naar de toestand die in je code is beschreven. Dit is het juiste pad wanneer de drift is veroorzaakt door een ongeautoriseerde handmatige wijziging of een tijdelijke debug-instelling die niet meer zou moeten bestaan.

De tweede optie is je Terraform-configuratie aanpassen aan de werkelijkheid. Kies dit pad wanneer de handmatige hotfix die tijdens een incident is uitgevoerd noodzakelijk, stabiel en nuttig voor productie blijkt. Door je code bij te werken zodat die de nieuwe situatie weerspiegelt, dicht je de kloof en zorg je dat toekomstige geautomatiseerde runs de noodzakelijke configuratie behouden.

Conclusie

Infrastructuurdrift is een onvermijdelijke uitdaging in dynamische cloudomgevingen, maar het hoeft voor je team geen ramp te betekenen. Door te begrijpen hoe het statusbestand van Terraform wijzigingen bijhoudt, strikte toegangscontroles in te voeren en drift-detectie als een vast operationeel gewoonte te behandelen, houd je de volledige controle over je cloudarchitectuur. Wil je de basisprincipes van infrastructure as code, providers en statusbeheer in meer detail verkennen? Luister naar de volledige aflevering en neem kennis van alle expertinzichten om je cloudautomatiseringsstrategie naar een hoger niveau te tillen.

Veelgestelde vragen

Wat veroorzaakt infrastructuurdrift in Terraform?

Drift ontstaat door wijzigingen die buiten Terraform om rechtstreeks in cloudresources worden aangebracht, via portals, CLI-commando's of scripts die de Terraform-pipeline omzeilen.

Hoe detecteert Terraform configuratiedrift tijdens een plan-run?

Terraform vergelijkt het opgeslagen statusbestand met de daadwerkelijke live cloudresources via provider-API's en je lokale configuratiebestanden.

Wat gebeurt er als iemand een Azure-resource die door Terraform wordt beheerd handmatig wijzigt?

Bij de volgende Terraform plan-run signaleert Terraform het verschil en probeert het de resource terug te zetten naar de in je code beschreven situatie, tenzij de configuratie wordt bijgewerkt.

Moet ik mijn Terraform-code bijwerken of de wijziging in de Azure-portal ongedaan maken?

Als de handmatige wijziging een noodhotfix was die nu nodig is voor de stabiliteit, pas dan je Terraform-configuratie aan. Als het een ongeautoriseerde of per ongeluk gemaakte wijziging was, laat Terraform deze terugdraaien.