Voor infrastructuur configuratie volgens het boekje
Servers: er zijn altijd een paar binnen het bedrijf die niemand meer aan durft te raken. Gebeurt dat toch, dan zijn de gevolgen soms desastreus en liggen werkprocessen stil. Het zijn precies die gevallen waar een Service Manager of IT Manager niet blij van wordt. Wil je een goed geteste en stabiele omgeving? En Infrastructuur configuraties kunnen doen zonder onverwachte risico’s? Met Desired State Configuration kun je jouw organisatie helpen naar een betrouwbare omgeving zonder onverwachte effecten bij aanpassingen.
No-touch servers zijn het gevolg van aanpassingen en configuraties die nergens zijn gedocumenteerd of vastgelegd. Deze servers worden ook wel eens ‘Snow-Flakes’ genoemd. Elke server heeft veel beheer aandacht nodig en de uitkomst bij updates en aanpassingen zijn altijd een verrassing en vormen dus een risico. Deze servers zorgen voor problemen met integratie en updates van de omgeving en worden daardoor met de dag gezien als een steeds groter blok aan het been. Helemaal nu met de steeds grotere aandacht op Security het regelmatig uitvoeren van updates aan de orde van de dag is, biedt Desired State Configuration uitkomst.
Wat is Desired State Configuration (DSC)?
Simpel gezegd wordt met DSC de configuratie vastgelegd in een definitie. Deze definitie wordt toegepast op het moment van uitrollen van een server, maar deze kan ook worden gebruikt om de configuratie te blijven monitoren. Zo kunnen handmatige wijzigingen op de server automatisch worden teruggedraaid. Deze wijzigingen moeten indien nodig worden opgenomen in de definitie en worden getest.
Met DSC maak je de infrastructuur onderdeel van de oplossing die op de servers wordt uitgevoerd. Zo heb je een totaaloplossing in code voor de applicatie zelf en de onderliggende infrastructuur. Dit biedt voordelen op het gebied van risicobeperking en security:
- Minder kans op verkeerd geconfigureerde servers
- Eenvoudig de configuratie meenemen bij een update van de infrastructuur naar nieuwere versies
- Servers voldoen altijd aan de gestelde security eisen van de organisatie
Oftewel, we halen de eigenaardigheden uit de infrastructuur en stoppen de configuratie-drift!
Wat is geschikt voor DSC?
Vanuit het verleden zien we dat DSC vaak ingezet is bij het realiseren van infrastructurele toepassingen zoals DHCP, Domain Controllers en DNS. De DSC zorgt voor een eenzijdige configuratie van deze omgevingen waardoor ze ten opzichte van elkaar geen afwijkingen vertonen. Problematiek op basis van configuratie wijzigingen worden op deze manier verder ingedamd.
Waar we nu steeds meer de focus op leggen, is het onderdeel maken van een ontwikkelproces binnen de organisatie. Heb jij een Development afdeling die haar applicaties laat landen op de door de IT afdeling beheerde servers, dan is dit een uitstekende kandidaat om te starten met DSC. Het doel is om de infrastructuur die je inzet voor het draaien van de oplossing onderdeel wordt van de Application Lifecycle. Door deze infrastructuur onderdeel te maken van de pipeline is het mogelijk om kwaliteitscontroles uit te voeren en bijvoorbeeld unit testing in te bouwen.
Het is ook goed te weten dat DSC niet Windows Server specifiek is, het is ook toepasbaar op Linux. En hiermee is het dus toepasbaar op de gehele infrastructuur.
Aan de slag met DSC
Wil je onder begeleiding aan de slag met DSC? Hier volgt een korte werkwijze hoe wij organisaties meenemen om DSC in de praktijk te laten ervaren.
Stap 1 – Inspireren en Overtuigen
We lichten de werking van DSC toe aan het IT-team om ze te overtuigen van de zero-touch mentaliteit (geen geklik meer en geen exceptions!). We maken ze bekend met de tooling die gebruikt wordt voor het inzetten van DSC. Denk hierbij aan het gebruik van Source Control, Code editor en Powershell.
Stap 2 – Vaststellen van het deployment process
In de volgende stap bepalen we het deployment proces van de infrastructuur. Hoe gaan we om met benodigde wijzigingen (code pull)? En hoe ziet het continue integratieproces (CI) er uit?
Stap 3 – Implementatie middels Iteratief proces
We starten met een greenfield server om het proces te leren, hierna kunnen we het ook toepassen op reeds bestaande servers. Elke additionele configuratie kan in een iteratief proces worden doorgevoerd totdat het change management proces helemaal eigen is geworden.
