Efficiëntieanalyse van het configuratiemanagementtool Puppet Marco van Hulten 15 mei 2009 Inhoudsopgave 1 Introductie 2 2 Werking van Puppet 2 2.1 Wat Puppet niet is............................ 2 3 Argumentatie 3 3.1 Puppet, na implementatie........................ 3 3.2 Implementatietijd............................. 4 3.2.1 Proof of concept......................... 4 3.3 Alternatieven............................... 5 3.3.1 Cfengine.............................. 5 3.3.2 Bcfg2............................... 5 4 Conclusie 6 1
1 Introductie Puppet[Pup] is een configuratiemanagement-tool voor het beheren van UNIX-achtige systemen. Met puppet is het mogelijk om configuraties van groepen van systemen en specifieke systemen te definiëren op een centrale host. Op deze manier zou er geen of minder handmatig onderhoud, of onderhoud door middel van scripts nodig zijn. In dit rapport wordt onderzocht in hoeverre Puppet voordeel oplevert boven scripten en of dat op zowel korte als lange termijn lucratief is. Puppet is van Reductive Labs, een commerciële organisatie. Vendor lock-in s 1 zijn echter niet mogelijk gezien de code gelicenceerd is onder GPL. Hiernaast staat de organisatie achter een open development-model. 2 Werking van Puppet Puppet gebruikt een declaratieve taal, waarin de toestand of staat van een situatie wordt gegeven. Dit is i.t.t. imperatieve talen zoals bash (shell scripting), waarin er sequentieel commando s worden uitgevoerd. Voorbeeld van een Puppet resource: file { "/etc/fstab": owner => "root" } We willen hier een bestand beheren, dus het soort resource is file, de naam hiervan is /etc/fstab en hierna volgt de gewenste toestand, namelijk de owner moet op root staan. Puppet zoekt zelf uit hoe dat wordt uitgevoerd op de host. Onder Fedora is dat chown root /etc/fstab (in bash), maar kan onder een ander systeem anders zijn. Dit hoeft een beheerder van Puppet niet te weten. Hij hoeft slechts te weten hoe je een resource toevoegt of wijzigt. Puppet kan ook andere resources beheren. Voorbeelden zijn de installatie en configuratie van een bepaald pakket of dat een bepaalde service moet draaien of niet (bijv. Apache). 2.1 Wat Puppet niet is Puppet is geen monitoring software. Wat bijv. wel een goed idee is, is Nagios en zijn modules of ZABBIX te laten beheren door Puppet. Hier zijn recepten voor. Veel recepten zijn te vinden op http://reductivelabs.com/trac/puppet/wiki/recipes. 1 Een vendor lock-in is een methode om de klant, bij introductie van een bepaald product, afhankelijk te maken van de fabrikant. Zo kan software worden geschreven waardoor de klant niet zonder aanzienlijke moeite en kosten kan overschakelen naar een ander product. Een voorbeeld hiervan is Microsoft Word. Het bestandsformaat is proprietary en kan alleen door MS Word goed worden gelezen en bewerkt. Op deze manier wordt een bedrijf, met veel MS Word documenten in huis, gedwongen licenties voor MS Office te blijven aanschaffen. Free en Open Source software (zoals Puppet) kent dit fenomeen niet, gezien deze gebruik maken van open standaarden en de broncode open is, zodat migratie en interoperabiliteit eenvoudiger en goedkoper is dan bij proprietary software (zoals MS Office). 2
3 Argumentatie 3.1 Puppet, na implementatie Zoals bij elk nieuw hulpmiddel zijn er voor- en nadelen te noemen voor Puppet. Hieronder volgen de belangrijkste voordelen. Centraal beheer Het beheer van alle werkstations kan met Puppet worden gedaan op één enkele server, de Puppet master. De Puppet master zegt tegen de werkstations, de puppets, hoe ze eruit moeten zien. Hoe dit gedaan wordt, is irrelevant voor de beheerder. De master doet dit goed, ongeacht het doel platform. Groepering Op de puppet master kunnen groepen hosts worden gedefiniëerd, met deels verschillende configuraties. Zo kunnen bijvoorbeeld binnen de reguliere werkstations een groep werkstations met extra services gedefiniëerd worden, waarin apache en mysql geïnstalleerd en aan staan. Op deze manier hoeft, indien gewenst, niet iedereen exact dezelfde configuratie te hebben. Tegelijkertijd is dit centraal te beheren. Een andere toepassing van groepering is het uitvoeren van migraties. Op deze manier kunnen verschillende groepen worden gedefiniëerd (bijv. testers, fase 2 en fase 3 ) om een migratie gecontroleerd te laten verlopen. Cross platform Op het KNMI hebben we verschillende distributies draaien. Hoewel we op de werkstations willen standaardiseren op Fedora, zouden we rekening kunnen houden met de volgende distributies, die daadwerkelijk draaien op het KNMI: Fedora, RHEL, SLED, OpenSUSE, Ubuntu, Debian en Solaris. Distro Client support Fedora Stabiel RHEL Stabiel SLED Stabiel op 10.1 en 10.2 OpenSUSE Stabiel Ubuntu Stabiel op LTS Debian Stabiel Solaris Stabiel Dit wil zeggen dat alle UNIX-achtige systemen 2 op het KNMI kunnen worden beheerd door een Puppet master. De Puppet master draait ook onder al deze platforms, maar waarschijnlijk zal de master worden geïnstalleerd op Fedora. Als Puppet wordt uitgerold, worden hier in eerste instantie alleen Fedora werkstations mee beheerd. Later is dat uit te breiden naar andere platformen. Windows wordt (nog) niet ondersteund. Open ontwikkeling Achter Puppet staat een actieve ontwikkelingsgemeenschap die zorgt voor ondersteuning en vrij te gebruiken recepten. De code van Puppet is vrij, zodat deze te wijzigen is. 2 Noemenswaardig is de support voor Solaris. Dit is een vroege en daarom één van de meest doorontwikkelde platforms van Puppet. Gezien er nog Solaris machines draaien op het KNMI en Solaris specifieke kennis alleen maar afneemt (ondermeer door de opkomst van GNU/Linux) kan Puppet ook hier een uitkomst in bieden. De syntax om een Solaris machine te beheren is namelijk hetzelfde als van alle andere machines. 3
Scripting In plaats van platform afhankelijke imperatieve shell scripts, is Puppet platform onafhankelijk en kent declaratieve recepten, waarmee je kunt aangeven hoe een host of een groep van hosts eruit moet zien. De Puppet syntax is leesbaar en beter te onderhouden, dus ook door extern ingehuurde partijen. Op dit moment worden de meeste zaken d.m.v. scripts uitgevoerd. Deze zijn vaak slecht gedocumenteerd en staan op verschillende plaatsen. Ieder schrijft scripts op zijn eigen manier en dit maakt het lastig om systeembeheer over te dragen aan anderen. Dit probleem valt weg bij het gebruik van een configuratiemanagement-tool zoals Puppet. Puppet s configuratiefiles zijn heel intuitief en high-level geschreven. Het gebruikt een declaratieve taal, wat het heel anders maakt dan scripten. Je geeft aan hoe een host eruit moet zien. Hoe dit dan daadwerkelijk op de puppet wordt bewerkstelligd, is irrelevant voor de beheerder. Hoewel wijzigingen in de state van een werkstation of server eenvoudig zijn te implementeren, is er geen (triviale) roll-back mogelijk. 3 Overzicht Hieronder volgt een overzicht van voor- en nadelen van Puppet. Voor Tegen beheer is centraal - cross-platform (generieke recepten) alleen UNIX-achtige systemen ontwikkeling en recepten zijn open relatief nieuw (2005) uitvoeren van wijzigingen eenvoudig geen (triviale) roll-back /etc/cups/ centraal regelbaar - groepen configuraties te definiëren - minder nadruk op bash scripting sommige scripts moeilijk te vervangen minder afhankelijk van beheerder externe moet eenvoudige syntax leren Puppet master kan op een virtuele host draaien - security: authenticatie en encrypie over SSL - 3.2 Implementatietijd Om te zien of Puppet beheer efficiënter maakt, is één ding. Om tot een goed overwogen conclusie te komen, moet er niet alleen worden gekeken naar het beheer van de werkstations, maar ook naar de implementatietijd en het onderhoud van Puppet zelf. 3.2.1 Proof of concept Op mijn werkstation met Fedora 10 heb ik probleemloos een Puppet master en client geïnstalleerd. Ik heb een resource gemaakt, zoals in sectie 2. Op een detail na 4 werkte dit binnen vijf minuten. Puppet packages (zowel de server als client) zijn beschikbaar voor de meeste distributies en ik verwacht dat de installatie op verschillende platformen op vergelijkbare wijze gaat. Om niet op zaken vooruit te lopen, heb ik dit nog niet getest. Veel van de implementatietijd zal zitten in het schrijven (of op internet opzoeken) van vrij triviale recepten. Hierbij denk ik aan Werkstations met extra services 3 Dit volgt uit de eigenschap van idempotentie. Dit betekent dat het meerdere malen uitvoeren van een operatie hetzelfde resultaat geeft. Bewijs uit ongereine: beschouw een idempotente niettriviale operatie O. Hiervoor geldt dat O 2 = O. Stel dat er een inverse P bestaat waarvoor dus moet gelden PO = id. Als we het linkerlid met O vermenigvuldigen, krijgen we PO 2 = O, maar omdat O idempotent is, geldt PO 2 = PO = id O (O was niet triviaal). Dit is een tegenspraak en dus bestaat er geen inverse van O. Q.E.D. Dit betekent concreet dat er geen roll-back van operaties mogelijk zijn. Als bekend is wat de begintoestand was, kan dit natuurlijk wel, hetzij op niet-triviale wijze. 4 De FQDN (m.a.w. bhwxxx.knmi.nl) was nog niet ingesteld op mijn werkstation en dan werkt Puppet niet; dit was een bug in onze Cobbler installatie van Fedora. 4
waarbinnen we recepten kunnen definiëren voor de installatie, configuratie en uitvoeren van Apache en MySQL. Voor alle werkstations kan het bijv. belangrijk zijn ervoor te zorgen dat /etc/shadow alleen voor de user root leesbaar is en wellicht willen we/var/log/httpd/ leesbaar zetten voor gebruikers. Dit laatste is misschien beter te definiëren binnen de Werkstations met extra services groep. Maar het punt is dat het kan en dat wij die controle hierover hebben. Zoals gezegd zijn dit vrij triviale recepten, wat vermoedelijk slechts twee dagen kost om te implementeren. Verdiepen in bash scripts is niet nodig, dus hierop kan tijd worden bespaard. Er zijn ook andere zaken waarbij Puppet uitkomst kan bieden, maar op minder triviale wijze. Hierbij kun je denken aan het beheren van gebruikers op werkstations. Dit is met een kale versie van Puppet voor elkaar te krijgen, maar dan krijg je wel lange recepten (voor alle gebruikers op elk werkstation). Dat zou je wellicht kunnen afvangen als er een database wordt gekoppeld aan Puppet, maar LDAP zou dan misschien een betere oplossing zijn. 3.3 Alternatieven Puppet is één van de vele configuratiemanagement tools, maar wel één van de meest belovende tools. Bij het zoeken naar configuratiemanagement tools heb ik drie stuks gevonden die voldeden aan de volgende eisen: Package in standaard Fedora repositories Up-to-date (laatste release dit jaar) Cross-platform (in zoverre relevant binnen deze discussie) Het resultaat was het volgende: Puppet Cfengine Bcfg2 Verdere informatie over Puppet is te vinden op de homepage [Pup] en het boek [Tur07]. De volgende subsecties buigen zich over Cfengine en Bcfg2 en hoe deze tools in verhouding staan tot Puppet. 3.3.1 Cfengine Cfengine is momenteel het meest gebruikte configuratiemanagement tool. Puppet is geschreven om Cfengine te vervangen. Platform-specifieke commando s zijn niet weggeabstraheerd in Cfengine. In Puppet is dat wel het geval. 3.3.2 Bcfg2 Hoewel ik denk dat Bcfg 2 een waardig alternatief is voor Puppet en Cfengine, heb ik mijn handen niet gebrand aan het daadwerkelijk testen van de software. De documentatie op de website duidt erop dat het opzetten een ingewikkeld proces is. Hiernaast kan ik niet expliciet vinden dat hoewel er gepraat wordt over Redhat en CentOS er client support is voor Fedora. (Deze documentatie lijkt echter out-of-date.) Deze software lijkt mij een no-go. 5
4 Conclusie In ieder geval op de langere termijn levert een configuratiemanagement-tool voordelen op. Naar verwachting werpt Puppet op de kortere termijn al vruchten af. Puppet is eenvoudig te implementeren en de syntax van de resources zijn eenvoudig te lezen, aan te passen en te maken. Bovendien is er een gemeenschap die ons kan voorzien van resources. De keuze van Puppet zal dan ook niet alleen op langere termijn voordelen opleveren, maar naar verwachting al na kortere tijd. De enige extra tijd die we nodig hebben is van het implementeren van Puppet op een (virtuele) server (puppet master) en alle hosts (puppets). Dit heb ik op kleine schaal al getest. Verder kan het uitrollen op alle clients tegelijk met de uitrol van de nieuwe distributie worden gedaan (Cobbler). Het kan ook met de hand worden gedaan op bijv. overblijvende SUSE systemen, RHEL servers, Ubuntu systemen en Solaris, gezien Puppet cross-platform is. Het alternatief, blijven scripten, is nog steeds mogelijk, maar zorgt voor een grote overhead. Bij het overdragen van taken zullen dan ook de scripts moeten worden overgedragen, maar in de praktijk zal dit niet of onvoldoende worden gedaan. Shell scripts zijn vaak slecht gedocumenteerd (slechts in scripts zelf; geen wiki met een overzicht, beschrijving, lokatie en functie van bestaande scripts) en lokaties niet gestandaardiseerd. Daarom zullen nieuwe beheerders zelf scripts gaan schrijven, dus het wiel opnieuw uitvinden. Dit is met Puppet niet nodig. Referenties [Pup] Homepage Puppet. http://reductivelabs.com/. [Tur07] James Turnbull. Pulling Strings with Puppet: Configuration Management Made Easy. Apress, Berkeley, 2007. 6