Tijd 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.
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!
Puppet op de afdeling systeembeheer van Antagonist
Puppet is software speciaal ontwikkeld voor configuratie-management. Een server haalt periodiek bij de Puppetmaster (zo word ikzelf trouwens ook regelmatig genoemd) de laatste catalog op. Hierin staat beschreven hoe de configuratie van de server eruit moet zien. Alle instructies om dit in orde te maken zitten hierin, mocht dit niet het geval zijn. Het synchroniseert niet alleen configuratiebestanden, maar neemt ook de juiste acties om deze toe te passen, zoals bijvoorbeeld het reloaden van Apache.
Dit alles heb je zelf in de hand en je kunt het precies maken zoals jij het wilt hebben. Voor Puppet zijn er een groot aantal standaard modules beschikbaar, welke je plug ’n play kunt gebruiken om bepaalde onderdelen van je server te beheren. Nu moet ik er wel bij vermelden dat meer dan 90% van onze Puppet-omgeving zelf geprogrammeerd of ontwikkeld is, dit heeft te maken met de specifieke eisen die wij aan ons platform stellen.
Voor het wijzigen van Puppet-code en het tracken hiervan gebruiken wij Git. Op deze manier kunnen eenvoudig meerdere mensen vanaf verschillende locaties aan dezelfde code werken, worden alle wijzigingen gelogd en kan je snel en eenvoudig een rollback uitvoeren mocht dit nodig zijn. Het werken met Git maakt het voor ons ook makkelijker om wijzigingen eerst te testen op niet-productie-servers, waarna we het uitrollen op een klein aantal productie-servers. Hier controleren we vervolgens nogmaals of er geen problemen opspelen. Wanneer de wijzigingen goedgekeurd zijn, dan rollen we dit uit naar de Master-branch, de volledige productie-omgeving.
Voorbeeld van systeembeheer: Update phpMyAdmin
Een van onze klanten had last van een issue in phpMyAdmin. Dit was een bekende bug en werd verholpen in een latere versie. Tijd voor een update, en natuurlijk hadden we hier eerder al een mooie Puppet-module voor geschreven. Hieronder een stukje van de git-commit en de uitrol ervan op de server (ik heb ter verduidelijking niet-relevante code achterwege gelaten).
commit 73a0ec5944dc18cf08580bf2699fa43b29ddffb3
Author: Erik Jan Hofstede <ejhofstede@antagonist.nl>
Date: Fri Nov 22 10:41:47 2013 +0100
--- a/modules/directadmin/files/custombuild/options.conf
+++ b/modules/directadmin/files/custombuild/options.conf
-custombuild=1.1
+custombuild=1.2
autover=no
bold=yes
clean=yes
@@ -75,3 +75,6 @@ libtool=yes
curl=yes
+phpmyadmin_ver=4
--- a/modules/directadmin/files/custombuild/versions.txt
+++ b/modules/directadmin/files/custombuild/versions.txt
@@ -43,7 +43,8 @@ php4:4.4.9:9bcc1aba50be0dfeeea551d018375548
phpmyadmin:2.11.11.3-all-languages:a4a9bdcf6a48d02895034e41844e7432
+phpmyadmin4:4.0.9-all-languages:f5c8bfcd75b5ee1914a248514e5b9b10
Hierboven zie je twee wijzigingen aan files van DirectAdmin, om vervolgens overal phpMyAdmin van een update te voorzien. De gedeeltelijke output van de Puppet-run zoals hij periodiek op elke server loopt:
Puppet (info): Caching catalog for s137.webhostingserver.nl
Puppet (info): Applying configuration version '1385097355'
/Stage[main]/Directadmin::Custombuild::Config/File[versions.txt] (info): Filebucketed /usr/local/directadmin/custombuild/versions.txt to puppet with sum bc3262a3cb18478c4f8032d259780666
/Stage[main]/Directadmin::Custombuild::Config/File[versions.txt]/content (notice): content changed '{md5}bc3262a3cb18478c4f8032d259780666' to '{md5}c012843b2ed5431e980095a91b1f9995'
/Stage[main]/Directadmin::Custombuild::Config/File[options.conf] (info): Filebucketed /usr/local/directadmin/custombuild/options.conf to puppet with sum 37866a541760f7ad7ecbf6184a254e4c
/Stage[main]/Directadmin::Custombuild::Config/File[options.conf]/content (notice): content changed '{md5}37866a541760f7ad7ecbf6184a254e4c' to '{md5}db88d564e8f8c7c2fbfb3a42c75d0b60'
Hierboven worden de files ‘options.conf’ en ‘versions.txt’ aangepast. Omdat de versies van Custombuild en phpMyAdmin veranderd zijn, worden deze automatisch naar de laatste versies gebracht. Voor deze update van phpMyAdmin is Custombuild versie 1.2 nodig, daarom wordt deze update eerst uitgevoerd:
/Stage[main]/Directadmin::Custombuild::Updater/Directadmin::Custombuild::Updater::Update[buildscript]/Exec[build-buildscript]/returns (notice): executed successfully
/Stage[main]/Directadmin::Custombuild::Updater/Directadmin::Custombuild::Updater::Update[phpmyadmin]/Exec[build-phpmyadmin]/returns (notice): executed successfully
Het Custombuild-script en phpMyAdmin zijn nu beiden up-to-date. Bij een nieuwe versie van phpMyAdmin wordt altijd de setup-directory opnieuw geïnstalleerd. Dit willen we niet, omdat het een potentieel beveiligingsrisico is, daarom verwijderen we deze automatisch:
/Stage[main]/Directadmin::Phpmyadmin::Config/File[phpmyadmin-setup] (info): Recursively backing up to filebucket
Puppet (info): FileBucket adding {md5}73c5618798aed7a3cc22979c57a90b6e
/Stage[main]/Directadmin::Phpmyadmin::Config/File[phpmyadmin-setup] (info):
Puppet (info): FileBucket adding {md5}8d9766badf08afa25b67573eec1297b6
De laatste stap is het terugzetten van onze .htaccess met specifieke phpMyAdmin-instellingen:
/Stage[main]/Directadmin::Phpmyadmin::Config/File[/var/www/html/phpMyAdmin/.htaccess]/ensure (notice): created
Puppet (notice): Finished catalog run in 41.82 seconds
En zo rolt een server in 41,82 seconden een update van Custombuild en phpMyAdmin uit, verwijdert het de setup-directory en zetten we onze eigen settings terug.
Voorbeeld van systeembeheer: Swappiness instellen
Het is standaard Linux-gedrag om een deel van het RAM-geheugen, wanneer dit niet actief wordt gebruikt, weg te schrijven naar swap space. Deze swap space staat op een harde schijf, die veel trager is dan RAM. Hoe snel Linux gaat swappen (RAM naar een harde schijf wegschrijven) wordt bepaalt door de instelling van de ‘vm.swappiness’, welke je kunt uitlezen en aanpassen met ‘sysctl’.
Standaard staat de waarde op 60, maar wij willen dit op 10 hebben. Wij hebben het namelijk niet zo op swappen. De kans is groot dat we ooit weer een instelling in sysctl aan willen passen met Puppet, dus hebben we er gelijk een kleine Puppet-class voorgeschreven. De volgende keer kunnen we deze instelling dus nóg sneller doorvoeren.
class sysctl::defs {
define enforce-sysctl ($name, $value) {
exec { "sysctl-$name":
onlyif => "/usr/bin/test `/sbin/sysctl -n $name` -ne $value",
command => "/sbin/sysctl $name=$value",
}
}
enforce-sysctl {
"swappiness":
name => "vm.swappiness",
value => "10";
}
}
class sysctl {
include sysctl::defs
}
De code hierboven controleert of ‘vm.swappiness’ gelijk is aan 10, zo niet dan past het deze aan:
[root@s137 ~]# sysctl vm.swappiness
vm.swappiness = 60
[root@s137 ~]# puppet agent --onetime --no-daemonize --logdest /var/log/puppet.log --verbose
info: Caching catalog for s137.webhostingserver.nl
info: Applying configuration version '1385465525'
notice: /Stage[main]/Sysctl::Defs/Sysctl::Defs::Enforce-sysctl[swappiness]/Exec[sysctl-vm.swappiness]/returns: executed successfully
notice: Finished catalog run in 13.02 seconds
[root@s137 ~]# sysctl vm.swappiness
vm.swappiness = 10
Zoals je ziet is de instelling aangepast van 60 naar 10 en hebben we de standaardwaarde aangepast naar onze gewenste instelling.
Hiermee zijn we aangekomen bij het einde van deze rondleiding. Hopelijk heb je een indruk gekregen in hoe wij zo efficiënt en consistent mogelijk ons serverpark beheren. Mocht je zelf aan de slag willen gaan met Puppet, begin dan makkelijk en bouw vanaf deze basis je omgeving verder uit.
Er is overigens niks mis met het maken van ‘verkeerde’ ontwerp-keuzes, er is immers nog nooit software geschreven die in één keer perfect was. Gaat er iets mis, dan is dat niet erg, leer ervan!
Kom werken bij Antagonist!
De liefde voor technische kennis, specifiek gericht op webhosting, zorgt voor constante verbeteringen aan ons systeem. We laten onze verregaande passie samenkomen met de nieuwste en meest geavanceerde technieken, daarin lopen we graag voorop. Het resultaat, een volmaaktheid van automatische processen ontwikkeld met eigen technologie.
Geef je net zoveel om techniek als wij en heb je zin om te werken bij een bedrijf als Antagonist? Wij zoeken nog versterking voor de afdeling Systeembeheer! Dus als jij een echte Linux-ninja bent en als je een uitdaging zoekt en als je wilt werken bij één van de snelsgroeiende IT-bedrijven van de Benelux? Maybe you can join the A-team!