Configuration Drift met IaC.
Wat is configuratie drift?
Naarmate een bedrijf evolueert, worden de softwareproductie- en leveringssystemen steeds complexer. Natuurlijk leidt dit tot frequente wijzigingen in hun configuraties.
In een ideale wereld zouden al deze wijzigingen op een uitgebreide en goed gestructureerde manier worden bijgehouden. Maar we leven niet in een perfecte wereld en zoals het er nu voor staat, worden veel van deze aanpassingen niet geregistreerd. Als ze onschadelijk zijn, is de impact op de systemen minimaal. Als deze wijzigingen echter ervoor zorgen dat de systemen uit een beveiligde staat raken, dan krijgen de eigenaars te maken met wat bekend staat als “configuratiedrift”.
Drift ontstaat tijdens de periode tussen het moment dat een nieuwe branch is gemaakt en wanneer deze wordt samengevoegd, en er meerdere andere wijzigingen zijn doorgevoerd in de hoofdbranch, wat resulteert in conflicten die moeten worden opgelost. In kleine ontwikkelingsteams kan een ontwikkelaar gewoon zijn collega’s op de hoogte stellen van de wijzigingen die hij heeft doorgevoerd. In grotere teams kan het aantal wijzigingen tussen een afsplitsing en samenvoeging aanzienlijk zijn, wat resulteert in meer conflicten en meer tijdverspilling bij het oplossen ervan.
Wat is code drift?
Code drift is waarschijnlijk de meest voorkomende vorm van drift, maar met de complexiteit van de huidige softwarearchitectuur en afhankelijkheden komt configuratiedrift ook vaak voor. Een ontwikkelaar kan bijvoorbeeld een nieuwe tabel aanmaken in de staging- of pre-productieomgeving nadat een branch is aangemaakt. Misschien is er een nieuwe lambda-functie gemaakt of is een SQS-configuratie bijgewerkt. Als de omgeving van de ontwikkelaar afwijkt, kan de code goed werken op een oude versie, maar fouten veroorzaken bij het samenvoegen in de bijgewerkte omgeving. Dit kan niet onmiddellijk gebeuren in eenvoudige gevallen, maar waarschijnlijk later, wanneer de complexiteit toeneemt en er meer diverse scenario’s worden gebruikt. Dit leidt tot veel debuggen en herschrijven, wat resulteert in een langere doorlooptijd voor de release. In de volgende secties zullen we verschillende benaderingen bespreken voor het beheer van code- en configuratiedrift.
Hoe kunt drift verminderen?
Het implementeren van Infrastructure-as-Code (IaC)
Een van de meest efficiënte manieren om configuratiedrift te voorkomen, is het adopteren van principes van infrastructure-as-code en het gebruik van oplossingen zoals Terraform.
In plaats van handmatig wijzigingen toe te passen om de omgevingen te synchroniseren, wat inherent foutgevoelig is, definieer je de omgevingen met behulp van code. Code is duidelijk en wordt op dezelfde manier toegepast/opgestart op een willekeurig aantal resources, zonder het risico iets over het hoofd te zien of de volgorde van bewerkingen om te draaien.
Wil jij meer weten over hoe wij bedrijven of jouw team kunnen verder helpen? Neem dan zeker eens contact op en brainstorm direct eventjes met een van onze professionals.
Door gebruik te maken van codeversiebeheer (bijv. Git), biedt een infrastructure-as-code platform ook een gedetailleerde registratie, inclusief zowel huidige als eerdere configuraties, waardoor het probleem van niet-gedocumenteerde wijzigingen wordt opgelost en er tevens een audit trail ontstaat als extra voordeel. Tools zoals Terraform, Pulumi en Ansible zijn ontworpen voor configuratiebeheer en kunnen worden gebruikt om drift te identificeren en signaleren, soms zelfs automatisch corrigeren – zodat je de kans krijgt om dingen recht te zetten voordat ze een echte impact hebben op je systemen.
Zoals bij elk hulpmiddel is het resultaat afhankelijk van hoe je het gebruikt. Het gebruik van een tool zoals Terraform maakt je bedrijf op zichzelf niet immuun voor configuratiedrift. Processen moeten nog steeds aanwezig zijn en door iedereen worden gevolgd; zelfs wanneer alle implementaties afhankelijk zijn van IaC, kan er drift optreden in bepaalde situaties (bijv. wanneer externe resources worden toegevoegd, verwijderd of gewijzigd). Er is ook geen garantie dat alle implementaties worden uitgevoerd met behulp van IaC, aangezien in veel gevallen handmatige implementaties nog steeds mogelijk zijn via CLI, API of de webportal-browser.
De gemakkelijkste manier om mogelijke drift in Terraform te detecteren, is door het plan opnieuw te berekenen en te beoordelen dat Terraform zou uitvoeren om de infrastructuur naar de gewenste staat te brengen: als het plan leeg is, is er niets veranderd in vergelijking met hoe je hebt beschreven dat het zou moeten zijn; als er stappen zijn die moeten worden uitgevoerd in het plan (en je de code niet hebt gewijzigd), betekent dit dat er wijzigingen zijn doorgevoerd via andere kanalen, wat resulteert in een afwijking in de configuratie. Soms kan dit automatisch worden opgelost en kan het systeem direct naar de beschreven staat worden gebracht, maar je moet op zijn minst onderzoeken hoe de verschillen zijn ontstaan en de processen dienovereenkomstig aanpassen om te voorkomen dat dit opnieuw gebeurt.
Infrastructure-as-code zal nog handiger zijn bij het delen en vrijgeven van gecontaineriseerde applicaties. Hoewel een containerimage alle code en softwareafhankelijkheden bevat die nodig zijn om uit te voeren, vereist het vaak aanvullende infrastructuurelementen in de cloud om schaalbaarheid en betrouwbaarheid te garanderen (bijv. een load balancer, monitoring, logging, enz.).
Nadat de app succesvol is geïmplementeerd in de cloud, moet je ervoor zorgen dat deze toegankelijk is voor het beoogde publiek en soepel draait. Dit betekent dat je alle infrastructuur rondom het containerimage opnieuw moet creëren, en de gemakkelijkste manier om dit te doen is met behulp van een IaC-template die alle noodzakelijke configuratie beschrijft.
Het is belangrijk op te merken dat het gedrag en de betrouwbaarheid van gecontaineriseerde applicaties sterk kunnen worden beïnvloed door verschillen tussen omgevingen, zoals ontwikkeling en productie. Dit komt door alle databases, services en andere cloud-native resources die extern zijn aan de app, maar essentieel zijn voor een goede werking ervan. In dit opzicht helpt IaC door veranderingen reproduceerbaar en voorspelbaar te maken, ervoor te zorgen dat de staging-omgeving nauw overeenkomt met de productieomgeving, en het implementeren van code- en infrastructuurwijzigingen in productie minder risicovol en aanzienlijk sneller te maken.
SUE kan je helpen met het implementeren van een effectieve infrastructure-as-code aanpak die helpt bij het beheren van configuratiedrift en het verbeteren van de betrouwbaarheid en efficiëntie van je IT-infrastructuur. Neem vandaag nog contact met ons op voor advies op maat en ondersteuning bij jouw specifieke behoeften.