Puppet is hot. Ik hoor van veel organisaties dat ze bezig zijn met een implementatie van Puppet of die overwegen. Verschillende van onze klanten zijn bijvoorbeeld bezig met de voorbereiding ervan. Toch is het interessant dat het nu zo populair wordt. Mijn collega’s gebruiken het al jaren voor het beheer van onze systemen. Maar blijkbaar is de tijd er nu ‘rijp’ voor.

Maar wat is Puppet? Het is management software waarmee grote aantallen servers beheerd kunnen worden. Het gaat hierbij zowel om het beheer van configuratie files (zeg maar instellingen van de servers) als het beheer van de geïnstalleerde software (packages). Een typische use case voor Puppet is bijvoorbeeld het beheer van virtuele servers in een cloud. Het kan dan gebruikt worden om snel extra webservers te installeren. In Puppet worden recepten (classes) gemaakt waarin de server feitelijk beschreven is.

Deze recepten kunnen ook dynamisch zijn doordat ze scripts bevatten die situatie afhankelijk software installeren. Zo kan een script testen op welk type hardware de installatie plaats vindt en aan de hand daarvan bepalen welke specifieke software (ten behoeve van ILO, DRAC et cetera) geïnstalleerd moet worden. Op iedere te beheren server draait een server proces (puppet.d) dat met de server communiceert. Deze communicatie is versleuteld en er kan ingesteld worden met welk interval de configuratie van de te beheren server vergeleken wordt met de Puppet server.

Ook kan gebruik gemaakt worden van Facter. Met Facter kan informatie van verschillende servers verzameld worden. Deze informatie kan eventueel samen met variabelen gebruikt worden in de recepten. De recepten zijn overigens te nesten zodat ze hergebruikt kunnen worden. Al met al een krachtig stuk gereedschap dat steeds krachtiger wordt naar mate er meer servers beheerd moeten worden. Een andere sterke kant is dat het volledig command line gebaseerd is. Maar de leercurve van Puppet is stijl. Een (open source) alternatief voor Puppet is CFengine.

Enthousiast

Een interessante vraag is waarom de technisch specialisten er zo enthousiast over zijn. Voor een deel is dit te begrijpen omdat technische mensen niet graag dubbel werk verrichten. Wanneer de eerste server is ingesteld en een tweede geconfigureerd moet worden, begint een technisch specialist na te denken of het niet slimmer kan. Puppet is een manier om het slimmer te doen en daar houden ze van. Natuurlijk moeten de recepten gemaakt worden en zonder twijfel wordt het daar complexer van. Maar bij grote aantallen servers scheelt het veel tijd. Daarnaast is een beetje complexiteit voor een technisch specialist een intellectuele uitdaging.

Een andere reden om Puppet te willen gebruiken is dat ze daarmee controle en overzicht verkrijgen. Middels de recepten zijn de configuraties van alle servers beschreven. Dat scheelt behoorlijk als er gedocumenteerd moet worden, een werkje dat niet altijd even leuk gevonden wordt. Bovendien kan eenvoudig de configuratie van honderden servers aangepast worden. Als technisch specialist ben je daarmee ‘in control’.

Als Puppet gecombineerd wordt met GIT kan er versiebeheer uitgevoerd worden op de configuraties. Het voordeel van dit versiebeheer is dat er een roll back kan worden gedaan naar een ‘oude’ configuratie waarvan bekend is dat die werkte en dat alle wijzigingen gedocumenteerd zijn. Er is precies te zien wie, wanneer, wat, heeft veranderd.

Een nog interessantere vraag is waarom bedrijven vanuit het business perspectief gebruik zouden willen maken van Puppet. It-organisaties zien zich tegenwoordig geconfronteerd met een aantal uitdagingen waarbij Puppet mogelijk kan helpen. Om te beginnen moet alles tegen lagere kosten. Met andere woorden het moet efficiënter. Dit is bij uitstek natuurlijk een gebied waarin Puppet zinvol gereedschap is. Mits goed ingericht kan met weinig mankracht een groot aantal servers worden beheerd.

Praktisch

Doordat alle configuraties beschreven zijn kunnen servers ook snel (fysiek danwel virtueel) opnieuw geïnstalleerd worden. Dit is buitengewoon praktisch wanneer een systeem bijvoorbeeld gehacked is. De enige manier om zeker te zijn dat alle ‘achterdeurtjes’ verwijderd zijn, is een herinstallatie uit te voeren. In Puppet is het gehele systeem beschreven waardoor ook de herinstallatie kan snel worden uitgevoerd. De aangewakkerde aandacht voor security de laatste tijd maakt dit een aantrekkelijke feature.

Indien Puppet gecombineerd wordt met GIT, zoals eerder aangegeven, kan historie worden bewaard. Dit betreft een historie van alle wijzigingen die er op servers hebben plaatsgevonden. Vanuit ITIL – een beheermethodiek die veel toegepast wordt – is dit erg interessant. De gedachte achter ITIL is dat 80 procent van alle verstoringen veroorzaakt worden door wijzigingen. Goede documentatie van alle wijzigingen is een eerste stap richting het beheersen en controleren van het veranderproces. Betere beheersing van het veranderproces leidt tot minder verstoringen. Het is duidelijk wat het belang van minder verstoringen is voor de bedrijfsvoering van organisaties.

Puppet is open source software. Dit maakt de instap bijzonder laagdrempelig. Indien organisaties behoefte hebben aan commerciële support dan kan deze onder andere bij Puppetlabs verkregen worden. Er kan dan gebruikt gemaakt worden van de enterprise edition. Deze betaalde versie heeft naast support ook extra’s die het goed bruikbaar maken binnen bijvoorbeeld een VMware-omgeving. In mijn ogen is de populariteit van Puppet wederom een voorbeeld waaruit blijkt dat Linux en open source software steeds meer main stream worden. Het is gereedschap om juist grote aantallen servers te beheren en dat betekent dat er dus grote aantallen Linux servers in gebruik zijn bij steeds meer organisaties.

Al met al prima redenen om het te gaan gebruiken, maar ik vraag me af of er ook redenen zijn om Puppet juist niet te gebruiken?
Dit artikel is verschenen op de site van Computable op 20-03-2012