Systeembeheer bij Antagonist, een kijkje in de keuken: configuratie-management

Systeembeheer: configuratie-management bij AntagonistTijd voor een kijkje in de keuken van de afdeling Systeembeheer bij Antagonist. Niks geen klikker-de-klik met de muis (sorry Windows sysadmins), het gaat hier over keiharde, diepgaande Linux-automatisering. In dit artikel zullen we een duik nemen in het configuratie-management van de servers waarop jouw websites en e-mail zijn opgeslagen. Tevens krijg je enigszins een inzicht in de werkwijze van de afdeling Systeembeheer bij Antagonist.

Waarom configuratie-management voor systeembeheer?

Als je vroeger (slechts enkele jaren geleden) een wijziging wilde doorvoeren aan de configuratie, op laten we zeggen 60 servers, dan moest je op elke server met SSH inloggen. Vervolgens voerde je de benodigde handelingen uit en controleerde je of alles goed was gegaan. Een intensieve klus, met veel ‘breindodend’ werk die helaas regelmatig voorkwam, niet echt de hobby van een systeembeheerder bij Antagonist.

Systeembeheer: de servers van Antagonist

Dit was echter niet het enige waar we tegenaan liepen. Om te streven naar een volmaaktheid in automatische processen waren er diverse obstakels, een opsomming hiervan, die snakten naar een goede oplossing, worden hieronder beschreven.

  • Als je bij één van de snelstgroeiende IT-bedrijven van de Benelux werkt, dan groeit je serverpark vanzelf ook snel. Elke server die erbij komt zorgt voor extra werk en kost dus extra tijd, want het aantal wijzigingen om door te voeren groeit bij elke extra server.
  • Namate we meer servers kregen en deze ‘ouder’ werden, begonnen zogenaamde configuration drifts te ontstaan. De configuratie, zoals hij zou moeten zijn, begon langzaam maar zeker per server af te wijken. Hierdoor ontstonden rare bugs en afwijkend onvoorspelbaar gedrag. Iets wat tijd kost om keer op keer opnieuw uit te zoeken, maar nog belangrijker: een klant van ons kon hier last van krijgen. Daarnaast houden nerds niet van onvoorspelbaar gedrag ;).
  • Wanneer we een wijziging doorvoerden, dan wist degene die dat deed natuurlijk prima wat er gedaan was, maar de rest van het bedrijf was niet op de hoogte en dit was na verloop van tijd ook lastig terug te vinden.
  • Waar mensen werken worden nou eenmaal fouten gemaakt, zelfs door Linux-ninja’s ;). Bij een handeling die je 100 keer moet uitvoeren is er immers een kans aanwezig dat er ergens een klein foutje insluipt en ervoor zorgt dat bijvoorbeeld de webserver niet meer werkt.
  • Wanneer een wijzing niet zoals gepland ging en een zogenaamde rollback nodig was, dan kwam er een hoop handmatig werk aan te pas, server voor server waren er handelingen vereist en dat kostte bijzonder veel tijd.

Met alle uitdagingen die hierboven beschreven staan, viel ons oog al snel op een nieuw, shiny en fancy stukje software genaamd Puppet!

Verder lezen