Waarom Configuratiebeheer

Al jaren gonst in computerland de kreet Configuratie Beheer of, in goed “ICT-Jargon”, Configuration Management. Maar, wat is nu configuration management en waarom zou je het moeten doen?

In de beginjaren van de computerwetenschappen waren er hordes hoogopgeleide beheerders nodig om een handjevol systemen te beheren. Met de hand. Naarmate de hardware goedkoper en beter beschikbaar werd, werd ook het vak van systeembeheerder anders. Steeds meer systemen werden door steeds minder mensen beheerd. Hierbij werd fanatiek gebruik gemaakt van scripts die op afstand op een systeem inloggen en die daar dan met veel hocus pocus de zaken regelden. Maar als het aantal systemen blijft groeien is dit op een gegeven moment geen werkbare situatie meer. Het is bijna niet te voorkomen dat het de systemen steeds verder uit elkaar drijven, configuration drift genoemd. Dit is een onwenselijke situatie die voor veel storingen en frustraties zorgt omdat de oplossing van een probleem op het ene systeem niet automatisch de oplossing is op het andere systeem. Er werd dan ook naarstig gezocht naar een manier om dit te voorkomen.

In 1993 bedacht Mark Burgess een oplossing voor dit probleem dat veel beheerders aangaat. Het idee van Burgess was eigenlijk kinderlijk eenvoudig: Het beschrijft wat de status van het systeem moet zijn, in tegenstelling tot het beschrijven van wat er gedaan moet worden. Dit is een omslag in denken die behoorlijk revolutionair is, zowel als concept als in zijn eenvoud. Doordat je namelijk beschrijft hoe het systeem er uit moet zien, kun je met de beschikbare tools ook afdwingen dat die status gehandhaafd wordt en blijft, waardoor de configuration drift tot een minimum beperkt wordt.

De tool die Mark Burgess hiervoor ontwikkelde is The Configuration Engine (CFEngine), de voorvader van alle configuration management tools.

Oké, het is revolutionair, maar waarom zou je het moeten gebruiken? Het antwoord is eigenlijk net zo eenvoudig als het idee van Burgess. Als je een handvol systemen hebt die allemaal identiek zijn, dan kun je dat met een kleine groep mensen nog wel beheren, maar als het aantal systemen explosief groeit naar duizenden dan is dat met ouderwets handwerk niet meer te doen. Configuratiebeheer is op zo’n moment essentieel om de systemen onder controle te krijgen en te houden.

In het begin van de jaren 2000 ging de beheerders-gemeenschap meer en meer aandacht besteden aan configuratiebeheer omdat er steeds meer gedistribueerde systemen kwamen die steeds complexer werden. Na een serie artikelen van LISA (Large Installation System Administration Conference) kwam er een ware explosie van open-source tools beschikbaar.

In de loop der tijd zijn er steeds meer tools ontwikkeld die zijn gebaseerd op de ideeën van Mark Burgess. In 2005 begon Luke Kanies uit ontevredenheid over CFEngine versie 2 met een eigen programma, genaamd Puppet. Momenteel is Puppet is één van de meest gebruikte configuratie beheer tools. Puppet heeft een eigen beschrijvende taal (Domain-specific language, DSL) waarin wordt beschreven wat de status van het systeem moet zijn. Later, in 2009, werd er een afsplitsing van Puppet gemaakt, door Adam Jacob, met de naam Chef. Chef richt zich vooral op Ruby specialisten, waarbij de beschrijvende configuratie taal ook volledig Ruby georiënteerd is. Naarmate de tijd vorderde zijn er meerdere systemen gekomen die allemaal hun specifieke voor- en nadelen hadden. Maar wat al deze systemen gemeen hebben is het concept van convergentie, het steeds dichter naderen van de gewenste situatie. Dit houdt in de praktijk vaak in dat er meerdere malen een run gedaan moet worden om het systeem in de juiste staat te krijgen. Dat dit een nadeel is mag duidelijk zijn, alhoewel het geen onoverkomelijk probleem is. Door de meeste beheerders wordt dit verschijnsel gewoon geaccepteerd.

In 2012 besloot een oud medewerker van RedHat en Puppet Labs, Michael DeHaan, dat dit beter kon en ontwikkelde zijn eigen programma genaamd Ansible. Een erg eenvoudig te gebruiken en te beheren configuratie beheer tool. De kracht van Ansible ligt vooral in het gemak waarmee het gebruikt kan worden en het ontbreken van convergentie. Een slag is voldoende om het systeem volledig te configureren. Hierdoor lijkt het weer op de eenvoud van de ouderwetse scripts maar wel met alle voordelen van configuratie beheer. Ook de taal (YAML) waarmee wordt beschreven in welke staat een systeem zich moet bevinden is erg eenvoudig en snel te leren.

Maar welk tool er door een beheerder gebruikt wordt, maakt in de praktijk vaak niet zoveel uit. Je kiest datgene wat het beste bij jezelf of je omgeving past en waar je je prettig bij voelt. Uiteindelijk is deze technologie ontwikkeld om de bedrijfs-doelen te halen, zoals in een korte tijd een systeem te herstellen of opnieuw op te bouwen, mogelijkheid om systeem-veranderingen te kunnen traceren (audits), een hoog aantal systemen per beheerder en nog vele meer.

In een wereld waarin de systemen voortdurend in beweging zijn, kun je je als beheerder waarschijnlijk wel vinden in de woorden van Tim Bell van CERN die stelt dat er bij het beheren van systemen steeds meer een verandering plaatsvindt van het hebben van huisdieren naar het hoedden van een kudde.

Onderwerpen
Actieve filters: Wis alle filters
Loading...