Het puppet topic, tips en trucs

[Boudewijn]

Dit topic is tegelijk geopend met mijn blogpost over de voorbeeld code

Boudewijns blogje: Waarom configuratie-management met Puppet cool is!

Puppet?

Puppet is een bekend configuration management (CM) systeem dat in Ruby is geschreven , en ook van een Ruby DSL (domain specific language) gebruik maakt voor zijn configuraties. CM is een techniek waarmee je op een gestructureerde manier systeemconfiguraties kunt centraliseren. Puppet is FOSS, alhoewel er ook een enterprise versie is.

Wat heb ik eraan?

Je configuraties worden overzichtelijker, minder werk om uit te rollen, minder foutgevoelig en je kunt makkelijker configuraties tussen machines verplaatsen/syncen. offtopic: Uiteraard is er ook een bescheiden leercurve te doorlopen...maar dat mag geen naam hebben Het spreekt voor zich dat in een omgeving met veel machines je het meeste aan puppet hebt (1 maal instellen, x maal uitrollen), maar op een enkele machine kan het ook al heel nuttig zijn. Je hebt namelijk overzicht, en je kunt je changes aan je systeem ook terugdraaien als je je puppet configuratie in een versiebeheer-tool (git, svn) stopt.

Waar werkt het op?

Linux Unices Windows support is in beta (http://projects.puppetlab...cts/1/wiki/Puppet_Windows)

Hoe werkt het?

Je hebt een puppetmaster waar je systeemdefinities op staan, en deze machine kan verschillende puppet-nodes als client hebben. Dit is dus een klassieke client-server architectuur. Een client controleert elke X (standaard in debian 30) minuten zijn systeemstaat met de staat zoals deze volgens de puppetmaster moet zijn en zal eventuele aanpassingen uitrollen. Je statements zijn opgebouwd uit klassen: een client kan tot een classe behoren en zal dan die eigenschappen overnemen. Binnen de klassen kun je templates (defines in puppet termen) definieren die in feite te vergelijken zijn met een functie als je in object-oriented-programming taal denkt. Hier zijn zelfs grafische interfaces voor (Foreman, puppet dashboard). In je klasse (en in je defines) kun je een aantal standaard resource types gebruiken om aan te geven hoe je systeem eruit ziet. Voorbeelden hier van zijn: packages users services files mounts Een volledige lijst is te vinden op http://docs.puppetlabs.com/references/latest/type.html Van elk van deze types kun je een aantal dingen aangeven,bijvoorbeeld of de service geinstalleerd moet zijn (of juist niet!), of hij moet draaien, en waar het initscript staat. Voor de overige resources zijn er ook dergelijke eigenschappen. Omdat we het hier over systeemstaten hebben is Puppet een declaratief framework: je beschrijft hoe het systeem eruit moet komen te zien. Goed, genoeg info... tijd voor een voorbeeld. Dit voorbeeld is vast niet perfect (commentaar is altijd welkom) maar bedoeld om te laten zien hoe cool puppet is in de praktijk zonder daarbij heel complex te worden. Ook is het geen complete stap voor stap tutorial, maar meer een showcase van de mogelijkheden zonder al te complex te worden. Wel is onderstaande code de daadwerkelijke code zoals ik die gebruik voor mijn servers. Als mensen willen weten hoe ze puppet hier op kunnen zetten, of dit voorbeeld in de praktijk kunnen gebruiken zijn ze welkom om om meer informatie te vragen. Ik heb zelf een aantal webservers waarop ik vhosts configureer in apache. Dat kan prima met de hand, maar via puppet is het makkelijker. Hiervoor heb ik een recipe gemaakt.. Hierin regel ik: Apache moet geinstalleerd zijn, en php. Nu is php niet strikt noodzakelijk maar bijna alle websites die ik draai zijn php gebaseerd. Apache moet draaien Er moet een vhosts-file aangemaakt worden.Deze vhosts files zien er globaal allemaal hetzelfde uit(!). De vhost moet enabled worden: a2enmod foo.bar, in debian waarbij foo.bar de sitenaam is. Dit is een beetje distro-specifiek maar ook dat kan prima getackled worden als je bijvoorbeeld Centos draait. De webroot moet aangemaakt worden in /var/www/www.foo.bar/htdocs, en apache moet schrijfrechten krijgen. Dit laatste is ivm veel wordpress sites een eis. Awstats configureren voor deze vhost. Dit voorbeeld is sterk debian-gebaseerd, maar ik heb hem in korte tijd (20 minuten oid) ook geschikt kunnen maken voor Centos. Hierbij maak je anders vhosts aan, en heet apache ook anders. We gaan stap voor stap door de opbouw van zo'n definitie heen. De klasse hier is apache, en de functie "simple-vhost". Er kan vast ooit nog een complex-vhost komen. Mijn code heb ik gebaseerd op diverse informatiebronnen/tutorials en voor mijn eigen gebruik ingericht. Het is deels creatief knippen en plakken, en deels van mezelf. Je mag deze code vrij gebruiken. Alle onderstaande code staat in het recipe, en het hele recipe is te vinden op: http://pastebin.com/J2AaMAev De code: code: class apache { package { "apache2" : ensure => present; } package { "awstats" : ensure => present; } Hier geef ik aan dat apache2 en awstats geinstalleerd moeten zijn. Puppet zoekt zelf uit of dat via apt, yum of wat anders moet gebeuren. code: package { "libapache2-mod-php5" : ensure => present, require => Package['apache2'], } Hetzelfde geldt voor php, waarbij ik echter ook meteen aangeef dat de package 'apache2' eerst geinstalleerd moet zijn. Dit zorgt er namelijk voor dat de php configuratie meteen in apache wordt gezet door APT. Het maakt niet uit of ik php in mijn klasse voor of na apache2 definieer, maar hij moet wel netjes aangemaakt worden. code: service { "apache2" : ensure => running, enable => true, require => Package['apache2'], } Als de package apache is gestart, wil ik ook dat de daemon wordt gestart. In het geval van apache zijn de initscripts en dergelijke goed in orde dus hoef ik weinig anders aan te geven dan dat de daemon moet starten (ensure running), hij bij boot moet starten (enable) en dat de apache package geinstalleerd moet zijn. Dat laatste klinkt zeer logisch, maar je weet bij Puppet niet in welke volgorde je definities gesynchroniseerd worden. Hiermee voorkom ik dat een systeem eerst apache probeert aan te zwengelen en daarna de package gaat installeren. Nu komen we bij het interessante deel: ik heb een sjabloontje gemaakt voor virtual hosts... deze roep ik voor elke virtualhost een keer aan buiten mijn recipe: code: define simple-vhost ( $admin = "[e-mail]", $aliases, $docroot="") { Dit is te vergelijken met een functie. Sowieso moet je een naam opgeven voor je vhost (omdat het een declaratieve omgeving is...) waardoor dat geen aparte parameter wordt. Daarnaast kun je een attribuut voor de admin (het mailadres in geval van storing), een array (maak hier even een mental note van) van aliassen en een documentroot opgeven. Dit is optioneel, als je geen mailadres opgeeft wordt mijn default mailadres ([e-mail]) gebruikt. De documentroot wordt anders op "" (een lege string) gezet, dit komt later nog aan bod. code: file { "/etc/apache2/sites-available/$name": mode => "644", require => [ Package["apache2"], Service["apache2"] ], content => template("apache/vhost.conf"), } In de define body definieer ik vervolgens een file (deze file wordt dus voor elke keer dat de define wordt gebruikt, en dus een vhost wordt aangemaakt gecreeerd). De variabele $name wordt door puppet automatisch gezet op naam van de instantie van de vhost. Zo'n vhost definitie ziet trouwens als volgt uit: code: apache::simple-vhost { "www.foo.bar" : aliases => ["foo.bar"] } apache::simple-vhost { "test.foo.bar" : aliases => [] } Hierbij heet de vhost in kwestie (en dus de $name variabele!) "www.foo.bar" respectievelijk "test.foo.bar". www.foo.bar heeft een Alias op foo.bar. Goed, terug naar de puppet code: Het aanmaken van de virtualhost file verijst de definitie voor de apache2 package en service al toegepast zijn, met andere woorden apache moet geinstalleerd zijn en de daemon moet draaien. Vrij logisch. Vervolgens zien we deze regel: code: content => template("apache/vhost.conf"), Hier wordt eigenlijk een extern bestand van de puppetmaster gebruikt, (in apache/vhost.conf) wat de vhost-file definieert: code: # # Managed by puppet # <VirtualHost *:80> ServerName <%= name %> ServerAdmin <%= admin %> DocumentRoot /var/www/<%= name %>/htdocs <% aliases.each do |al| -%> ServerAlias <%= al %> <% end -%> ErrorLog /var/apache-log/<%= name %>.error.log CustomLog /var/apache-log/<%= name %>.access.log common ScriptAlias /cgi-bin /var/www/cgi-bin/ </VirtualHost> Dit is een standaard vhost file, waarbij opvalt dat op een aantal plekken Ruby-code staat( in de <% en <%= tags ). De <%= foo %> tags worden door puppet vervangen door de waarde van de variabele foo in de define. Dit zien we terug in de name (de naam van de vhost) en de admin (die standaard [e-mail] is) variabele. De name wordt vervolgens ook gebruikt voor de documentroot. We zagen ook dat de aliassen in array vorm waren opgegeven bij declaratie van een vhost. We zien nu waarom: een we iteren met gewone ruby syntax door die array en maken voor elk element een ServerAlias tag aan in de vhost-configuratie. Dit gebeurt door het aliases.each statement. Is de array leeg? dan wordt er geen ServerAlias regel aangemaakt. Met de <% end -%> geef ik aan dat de each-lus is afgelopen. Voor de logging gebruik ik wederom de name variabele. Een vhost voor www.foo.bar met als alias foo.bar en test.foo.bar komt er dan zo uit te zien: code: <VirtualHost *:80> ServerName www.foo.bar ServerAdmin [e-mail] DocumentRoot /var/www/www.foo.bar/htdocs ServerAlias foo.bar ServerAlias test.foo.bar ErrorLog /var/apache-log/www.foo.bar.error.log CustomLog /var/apache-log/www.foo.bar.access.log common ScriptAlias /cgi-bin /var/www/cgi-bin/ </VirtualHost> De ServerAliassen kunnen ook op 1 regel, maar je moet daarbij tussen alle elementen een , hebben. Hierbij zou je het alias neer moeten zetten en als geldt het alias niet het laatste in de array is een komma. Dat is lastiger qua puppetcode, daarom heb ik voor deze vorm gekozen. De file in puppet is gedeclareerd als: code: file { "/etc/apache2/sites-available/$name": Dit betekent dat de configuratie die met die template is aangemaakt dan ook meteen in /etc/apache2/sites-available/www.foo.bar wordt gezet... wat exact de bedoelign is . Hierna willen we de site enablen, en hiervoor gebruiken we een exec-resource. Exec voert shell-commando's uit (verrassing!). code: exec { "/usr/sbin/a2ensite $name; /usr/sbin/apache2ctl graceful ": subscribe => File["/etc/apache2/sites-available/$name"], refreshonly => true } De resource zelf zal uitvoeren "/usr/sbin/a2ensite $name; /usr/sbin/apache2ctl graceful", dit enablet de site en herstart apache. Echter willen we dit in verband met de performance niet elke puppetrun doen. Daarom gebruiken we de subscribe-eigenschap: dit zorgt ervoor dat de resource (in dit geval de exec) alleen wordt uitgevoerd als de resources waarop de eerste resource is gesubscribet veranderen. Met andere woorden: de puppetclient kijkt of de configuratiefile van de vhost op de client is aangepast, en herstart dan apache als dat zo is. Is de file niet aangepast... dan herstart hij apache niet. Erg handig dus! Nu hebben we een vhost gedefinieerd in apache, en apache herstart maar nog geen webroot: code: file {"/var/www/$name": mode => "660", group => "www-data", ensure => directory, } file {"/var/www/$name/htdocs": mode => "660", group => "www-data", ensure => directory, require => File["/var/www/$name"], } offtopic: Ik weet dat dit in 1x moet kunnen maar moet dat nog een keer uitpluizen. We maken hier de directories aan met het file resource type, waarbij we met ensure => directory zorgen dat het een directory is. Ik denk dat wel duidelijk is hoe bovenstaande werkt. Als laatste heb ik ook een aw-stats configuratie die aangemaakt wordt zodat klanten op www.foo.bar/cgi-bin/awstats.pl hun awstats kunnen bekijken. code: # awstats config... file { "/etc/awstats/awstats.$name.conf": mode => "640", owner => "www-data", content => template("apache/awstats.conf"), } } } Ook hier gebruik ik een template zoals bij de vhost. De template is niet erg boeiend en zal ik hier ook niet neerzetten tenzij men hier behoefte aan heeft. De extra accolades sluiten de klasse die we in de eerste code-snippet zijn begonnen weer netjes af. Op de puppetmaster kan ik met 1 enkele regel code een vhost aanmaken en inrichten op servers. Wil ik een vhost van server1 naar server2? Dan copy-paste ik de regel (en moet ik mijn DNS aanpassen) en ik ben klaar. Supermooi dus. Andere dingen die ik in puppet heb zitten: Users,public keys, groepen NTP XenServer guest OS tools APT configuratie resolv.conf, ik heb vrij veel machines op XS4ALL netwerken. Deze machines heb ik allemaal in een groep zitten die de xs4all DNS gebruikt... lekker makkelijk /etc/motd Handige pakketjes die ik op elke machine geinstalleerd wil hebben (iptraf, screen, vim, sudo) denyhosts En nog een zwik van dit soort spul. Ik zie op GitHub bijna voor alles wel een recipe: KVM virtual machines, Nagios monitoring, Mysql DB's, firewalls, asterisk, noem maar op.

Waarom dit topic?

Nou het valt eerlijk gezegd op dat hier op GoT weinig mensen over Puppet praten terwijl het toch echt booming business is. Ook is het, wat mij betreft, de fijnste configuration management tool, alhoewel Chef ook heel aardig schijnt te zijn. Ik heb echter om niet-technische redenen voor puppet gekozen. Het doel van dit topic is fijn over puppet in het algemeen en technische tips en trucs te praten. Ook hoop ik dat wat meer mensen hun coole (of juist heel simpele) recipes showen. Ook zou het leuk zijn als mensen wat informatie geven over hun setup, of bijvoorbeeld Foreman.

Toffe links?

Een overview van wat puppet doet: http://www.engineyard.com...nage-your-infrastructure/ http://www.github.com: Op Github staan heel veel open source recipes die je zo kunt gebruiken om andere dingen te managen. http://puppetlabs.com: de website van PuppetLabs, en op http://docs.puppetlabs.com/ heel veel goede documentatie. http://bitfieldconsulting.com/puppet-resources : veel toffe puppet recipes en uitleg over Puppet. Hier haal ik regelmatig inspiratie vandaan Heb je zelf een leuke link? DM me en hij komt in de lijst.

[CAPSLOCK2000]

Puppet is inderdaad geweldig als je meerdere systemen moet beheren.

Laat ik eens met een simpele vraag beginnen. Standaard draait puppet eens per 30 minuten. Ik ben al een tijdje op zoek naar een manier om die tijd te veranderen maar kan het maar niet vinden. Heeft iemand toevallig enig idee?

Tweede vraag. Heeft er iemand ervaring met puppet standalone draaien? Ik heb een paar servers die onderling niet of nauwelijks kunnen communiceren. Ik denk er over om de hele configuratie in GIT te stoppen (sowieso een goed idee) en dan puppet als stand-alone agent te draaien, dus zonder puppetmaster. Iemand enige ervaring hier mee?

[Boudewijn]

He leuk een reactie .

Ik heb een paar testmachines voor recipes die zichzelf managen. Reden is dat ik een template-vm heb die zichzelf als client heeft. Deze kan ik lekker snel clonen zonder met authenticatie tussen client en server te werken. Hierop rotzooi ik lekker met recipes. Mijn hele /etc/puppet staat daar dan ook in git, net als mijn op mijn puppetmaster. Hier gebruik ik wel een puppetmaster, die dan ook op localhost staat.
Waarom zou je het zonder puppetmaster willen doen?

De puppet-run frequentie kun je aanpassen door in je /etc/puppet/puppet.conf te zetten:
runinterval=xxx , met je polling interval in seconden als xxx.

Bron (niet zelf getest):
http://serverfault.com/qu...rval-of-the-puppet-master


Als er mensen trouwens mede-auteur van het topic willen worden zijn zij bij dezen uitgenodigd.

[ Voor 16% gewijzigd door Boudewijn op 11-03-2012 14:25 ]

[Kees]

CAPSLOCK2000 schreef op zondag 11 maart 2012 @ 14:19:
Puppet is inderdaad geweldig als je meerdere systemen moet beheren.

Laat ik eens met een simpele vraag beginnen. Standaard draait puppet eens per 30 minuten. Ik ben al een tijdje op zoek naar een manier om die tijd te veranderen maar kan het maar niet vinden. Heeft iemand toevallig enig idee?

Runinterval inderdaad, of hem op zijn tcp poort laten luisteren en een 'puppet kick' uitvoeren op de master.

Tweede vraag. Heeft er iemand ervaring met puppet standalone draaien? Ik heb een paar servers die onderling niet of nauwelijks kunnen communiceren. Ik denk er over om de hele configuratie in GIT te stoppen (sowieso een goed idee) en dan puppet als stand-alone agent te draaien, dus zonder puppetmaster. Iemand enige ervaring hier mee?

Standalone is zo mogelijk nog eenvoudiger dan remote draaien, gewoon de /etc/puppet/* dirs gebruiken. En inderdaad, de boel in git/svn stoppen is een goed idee.

[CAPSLOCK2000]

Boudewijn schreef op zondag 11 maart 2012 @ 14:23:
Ik heb een paar testmachines voor recipes die zichzelf managen. Reden is dat ik een template-vm heb die zichzelf als client heeft. Deze kan ik lekker snel clonen zonder met authenticatie tussen client en server te werken. Hierop rotzooi ik lekker met recipes. Mijn hele /etc/puppet staat daar dan ook in git, net als mijn op mijn puppetmaster. Hier gebruik ik wel een puppetmaster, die dan ook op localhost staat.
Waarom zou je het zonder puppetmaster willen doen?

Beperkte resources. Puppet en puppetmaster zijn niet echt zuinig. Die twee samen kosten een paar honderd MB aan geheugen. Dat is veel te veel voor een VM met 256M. Ook op een webserver met 1G geheugen vind ik het eigenlijk niet acceptabel om een kwart kwijt te zijn aan puppet.
Eens per nacht door de config heen lopen is in die situatie ook wel genoeg dus het is nergens voor nodig om de puppet-agent en puppet-master 24/7 te draaien.

De puppet-run frequentie kun je aanpassen door in je /etc/puppet/puppet.conf te zetten:
runinterval=xxx , met je polling interval in seconden als xxx.

tnx. ik snap niet dat ik dat zo lang gemist heb

[ Voor 7% gewijzigd door CAPSLOCK2000 op 11-03-2012 14:33 ]

[Boudewijn]

Runinterval zou in het verleden wel geheugenlekken op te hebben geleverd, wordt ook in die link geinsinueerd. Nu wil het zo zijn dat ik een machine in beheer heb die ook nu en dan de oomkiller op puppet toe laat slaan, waaruit ik af zou kunnen leiden dat Puppet nogal geheugen heeft lopen snoepen (de machine is een RoR webserver dus Ruby wil sowieso wel wat memory snopeen op dat ding).

Zit me eerlijk gezegd af te vragen hoe ik dat goed kan bewijzen; het probleem steekt maar 1x in de zoveel tijd de kop op.

Ben trouwens van plan de volgende dingen op korte termijn zelf te gaan doen:

• Mysql DB's in puppet. Ik heb ook wat pgsql (heeft zelfs mijn voorkeur) maar veel en veel meer mysql
• KVM VM's in puppet op mijn testomgeving
• Foreman opzetten

Ben dus voorlopig nog wel even zoet .


Weet iemand trouwens hoe je netjes communicatie tussen verschillende puppet recipes regelt?
Voorbeeldje:
Ik wil een VM aanmaken, dit gebeurt straks via mijn KVM recipe.Ook wil ik dan op een andere machine de monitoring geregeld hebben via Nagios, dat op een andere client via een Nagios recipe moet gebeuren.

Is daar een truc voor? Of ga je dan toch een DB gebruiken waarin je de VM zet die telkens door je nagios recipe laat checken (vies)?

[ Voor 21% gewijzigd door Boudewijn op 11-03-2012 15:12 ]

[imp-]

Leuk om te zien dat hier ook mensen met puppet bezig zijn
Ikzelf ben er nog maar een maandje mee bezig, maar ondertussen toch wel al het een en ander gerealiseerd ermee.

[Boudewijn]

Wat heb je allemaal gedaan?

Ik ben zelf atm bezig met recipes voor :

* OpenCA, voor een klant van me. Huisvlijt.
* KVM virtualisatie, moet er gewoon een downloaden.
* Mysql, denk dat ik dit ook geen homebrew wordt.
* De transip api voor DNS. Homebrew.


Met die laatste 2 +vhosts wil ik snel wordpress sites uit kunnen gaan rollen .

[ Voor 10% gewijzigd door Boudewijn op 13-03-2012 13:17 ]

[Fiddich]

Puppet standalone draaien is zeker een optie. Kan ook altijd via een cron, op die manier kan je altijd zelf de servers verdelen.

Een puppet-opzet is pas volledig met een goed versioning systeem, GIT of Mercurial ofzo.
Dan ook nog mcollective, om dan aan 'orchestration' te doen, alles dat interactief moet verlopen.
En natuurlijk een frontend voor de rapportage, 'dashboard' of nog beter 'theforeman'.

Welja, de mogelijkheden zijn eindeloos.
Maar ook de alternatieven: CFEngine3, Chef, bcfg2, zijn best ok.
Zolang ze maar niet met commerciele rommel afkomen voor op Linux/Unix.

[Boudewijn]

Nou ja Puppet is ook in de Enterprise editie te organiseren, dat is ook commercieel.
Imo is commercieel niet verkeerd, RHEL is ook nogal commercieel.


Zelf heb ik mijn /etc/puppet gewoon in git zitten, ondanks dat ik ook een svn server heb en die eigenlijk overal voor geruikt. Voordeel van git is dat het in dit geval mooi lokaal op de puppetmaster blijft staan.

Qua MCollective: zeker ook interessant, heb je daar ervaringmee?

Foreman moet ik nog opzetten.


CHEngine, chef enzo: ook interessant, maar ik ben ZZPer en een aantal van mijn klanten heeft Puppet in gebruik zonder veel eigen kennis (ze waren al klant voor ze puppet interessant vonden hoor). Ook denk ik dat Puppet momenteel het 'hipste' is; dat vergroot voor mij de potentiele klantenkring het sterkste (ja klinkt kansloos maar helaas werkt het zo).

[Kees]

Ikzelf heb mijn puppet config in svn staan, en daar heb ik dan 3 branches/environments gemaakt: experimantal, testing en production, op die manier voorkom ik dat ik perongeluk mijn productie environment sloop.

Overigens doe ik nog niet al te veel ingewikkelde dingen ermee, vhosts e.d. heb ik gewoon als 'files' gedefinieerd, want daar veranderd niet veel aan, en ze zijn bijna allemaal anders, dus dan is het net zoveel typewerk om het in de files dir aan te passen dan om een definitie aan te passen.

Verder heb ik momenteel configs erin zitten voor oa apt, activemq, exim4, dnsmasq, zabbix, ldap, locales, grub, memcached, mongodb, mysql, nfs, ntp, php5, apache, tomcat, varnish, powerdns, dnsmasq en networking. Veelal zijn dat hele eenvoudige 'package -> file -> service' recepten waarbij de config aangepast is.

Het grootste voordeel is dat ik een server op die manier na (soms enkele keren) puppet te draaien helemaal productieklaar heb. Alleen de data moet dan nog

[Boudewijn]

Kees schreef op dinsdag 13 maart 2012 @ 15:41:
Ikzelf heb mijn puppet config in svn staan, en daar heb ik dan 3 branches/environments gemaakt: experimantal, testing en production, op die manier voorkom ik dat ik perongeluk mijn productie environment sloop.

Ik heb mijn productie los staan met aparte credentials. Testomgeving draai ik thuis in een VM.

Overigens doe ik nog niet al te veel ingewikkelde dingen ermee, vhosts e.d. heb ik gewoon als 'files' gedefinieerd, want daar veranderd niet veel aan, en ze zijn bijna allemaal anders, dus dan is het net zoveel typewerk om het in de files dir aan te passen dan om een definitie aan te passen.

Ik heb heel erg veel generieke templates draaien zoals hierboven. Dan is het zo fijn om die niet handmatig te bakken. Ook bacula (ander projectje dat nog gedaan moet worden) gaat hier baat bij hebben.

Verder heb ik momenteel configs erin zitten voor oa apt, activemq, exim4, dnsmasq, zabbix, ldap, locales, grub, memcached, mongodb, mysql, nfs, ntp, php5, apache, tomcat, varnish, powerdns, dnsmasq en networking. Veelal zijn dat hele eenvoudige 'package -> file -> service' recepten waarbij de config aangepast is.

Vind je networking niet eng? Als je die sloopt kom je niet meer op je bak. Wordt puppet trouwens ook voor de t.net servers gebruikt?
En heb je een bestaande mysql recipe genomen of zelf wat gebakken?

Het grootste voordeel is dat ik een server op die manier na (soms enkele keren) puppet te draaien helemaal productieklaar heb. Alleen de data moet dan nog

Als je je volgorde goed hebt gedefinieerd zou het afaik in 1x moeten kunnen ,of mis ik wat?

[Kees]

Boudewijn schreef op dinsdag 13 maart 2012 @ 15:49:
[...]


Vind je networking niet eng? Als je die sloopt kom je niet meer op je bak. Wordt puppet trouwens ook voor de t.net servers gebruikt?
En heb je een bestaande mysql recipe genomen of zelf wat gebakken?

Neuh, networking is een kwestie van 1 keer goed doen (hij applied de config overigens niet) en daarna ervan afblijven

Nadat hij het veranderd heeft moet ik een keer rebooten, maar dat is toch al normaal in mijn installatieprocedure (testen of alles op komt na een reboot).

Verder hebben alle servers een drac/imm of vnc-console (de vm's) dus ik kom er altijd bij.

Als je je volgorde goed hebt gedefinieerd zou het afaik in 1x moeten kunnen ,of mis ik wat?

Ja, maar soms mis ik dingen op een volledig schone omgeving En sommige dependancy's heb ik gewoon nog niet kunnen uitwerken en/of negeert hij schijnbaar. Dus normaal gesproken draai ik het een paar keer tot er geen veranderingen meer zijn. Op een basis install is dat al wel na 1 keer draaien, maar bij extra installaties kan het soms wat langer duren, zo liep ik vandaag aan dat ik een file moest toevoegen, daarna een commando draaien, en vervolgens een package instaleren. Maar die pacakge is pas beschikbaar na het commando (apt-key & apt-get update), maar dat commando moet maar 1 keer draaien, dus kun je hem niet requiren, want hij zal vervolgens nooit meer draaien als het goed is.

En ja, ik ben het aan het uitrollen op de tweakers.net servers. So far draait het op 10 servers en 2 vm's in productie.

[imp-]

Boudewijn schreef op dinsdag 13 maart 2012 @ 13:16:
Wat heb je allemaal gedaan?

Mijn laatste wapenfeit is een custom postfix recipe, toepasbaar voor verschillende onderdelen van de organisatie.
Daarnaast ook wat testen gedaan met het schrijven van facts (facter) om bepaalde informatie van alle machines die door puppet beheerd worden te verzamelen. Die kan je dan in foreman ook mooi weergeven en bijv. op gaan filteren.

[CAPSLOCK2000]

Ik doe m'n netwerkconfiguratie ook met Puppet. Ik heb een recipe dat ik alleen maar een netwerk-naam en een nummer hoef te geven en dan wordt daar het IPv4 en IPv6 adres uit afgeleidt en de rest van de configuratie.
Het voordeel van deze aanpak is dat ik bij het installeren van de machine gewoon dhcp kan gebruiken om het ding lekker snel draaiend te krijgen. Daarna start ik puppet en die zorgt dan wel dat het goed komt.

Mijn hosts zijn ook niet in 1 keer klaar maar hebben een paar runs nodig. Ik geloof dat het beter is om de dependencies niet te strak te maken, dat maakt het alleen maar lastig en na een paar keer runnen krijgt puppet het toch wel goed.

[Anoniem: 91397]

Ben vorige week begonnen met een puppetserver op te zetten, liep finaal in het honderd omdat ik verkeerde files had overschreven. Ben nu eerst een LDAP server aan het configureren en dan ga ik hier weer mee verder.

[psyBSD]

Ik heb ook een tijd lang diverse servers beheerd met puppet. (zo'n 30)

Ik moet zeggen dat ik cfengine toch prefereer. Qua syntax heeft het een hoger leer-curve. Maar het heeft als voordeel dat het niet je hele systeem plat legt als het een configuratie controleert/uitrolt.

De memory-footprint en het cpu-gebruik van puppet is iets waar ik niet helemaal over te spreken ben.

[Boudewijn]

Hoezo leg je je systeem plat? Door geheugengebruik?

[psyBSD]

Doordat Puppet langskomt, met 400MB aan geheugengebruik, triggert dat cache-flushes van de webserver. Hierdoor gaat moet de webserver vaker naar disk en gaat de load omhoog. 'plat' is een groot woord, maar je merkt het wel in de responsetijden.

Edit:
Ik moet toegeven dat ik puppet voor het laatst begin 2011 heb gebruikt, dus misschien is dit inmiddels verholpen.

[ Voor 19% gewijzigd door psyBSD op 16-03-2012 12:27 ]

[Boudewijn]

Ik zie iets van maximaal 100MB geheugen voorbij komen. Alsnog vrij veel, maar geheugen is voor mij goedkoper dan de winst opgeven die ik met puppet realiseer.

[psyBSD]

Dat ben ik met je eens, 100MB is zeker acceptabel. Maar, op een server met 4GB aan geheugen is 400MB voor het controlleren dat er niets is veranderd extreem veel.

Wat ik bedoelde te zeggen is dat ik na deze problemen verder ben gaan kijken en uit kwam bij cfengine, een vergelijkbaar systeem maar zonder de overhead van ruby.

Edit:
Niet om het topic te kapen, maar om te wijzen op een mogelijk alternatief, mocht iemand de memory-footprint van puppet ook een probleem vinden.

[ Voor 29% gewijzigd door psyBSD op 16-03-2012 13:04 ]

[CH4OS]

Hoe vind dan het beheer en rapportage plaats? Ik kan me voorstellen dat bijvoorbeeld een webbased admin panel handig is voor het beheer van Puppet zelf. Neem aan dat je met configuration management ook dingen als CMDB (configuration management database) bedoeld?

[psyBSD]

Je kunt bijvoorbeeld kijken naar het puppet dashboard:

http://puppetlabs.com/puppet/related-projects/dashboard/

[Anoniem: 91397]

CptChaos schreef op vrijdag 16 maart 2012 @ 13:21:
Hoe vind dan het beheer en rapportage plaats? Ik kan me voorstellen dat bijvoorbeeld een webbased admin panel handig is voor het beheer van Puppet zelf. Neem aan dat je met configuration management ook dingen als CMDB (configuration management database) bedoeld?

9 / 10 keer zijn en php based applicaties die je dmv Apache kan draaien om content uit te lezen. Zo ben ik bijvoorbeeld momenteel aan het kijken naar phpLDAPadmin voor OpenLDAP omgeving, maar twijfel ik daar nog tussen en een Apache Directory Studio (meer GUI). Over de php oplossingen kan ik vaak vrij veel vinden.

[ Voor 18% gewijzigd door Anoniem: 91397 op 16-03-2012 13:49 ]

[Boudewijn]

Ik denk dat captchaos op foreman doelt met een sql backend, klopt dat captchaos?

[psyBSD]

Ah, right... foreman... helemaal vergeten. Is dat nu een beetje stabiel?

Ik moet echt weer terug kijken naar Puppet, het lijkt een stuk verbeterd sinds de laatste keer dat ik er mee gewerkt heb.

[ Voor 46% gewijzigd door psyBSD op 16-03-2012 16:13 ]

[CH4OS]

Boudewijn schreef op vrijdag 16 maart 2012 @ 14:02:
Ik denk dat captchaos op foreman doelt met een sql backend, klopt dat captchaos?

Configuration Management is een ruim begrip, ik denk dat Puppet iets anders is als wat ik nu denk dat het is. Ik doel meer op een functionaliteit zoals omschreven in Wikipedia: Configuration management database. Maar ik begrijp dat Puppet juist iets is om remote een PC te kunnen beheren qua software patches, imaging e.d.?

[Anoniem: 91397]

CptChaos schreef op vrijdag 16 maart 2012 @ 16:36:
[...]
Configuration Management is een ruim begrijp, ik denk dat Puppet iets anders is als wat ik nu denk dat het is. Ik doel meer op een functionaliteit zoals omschreven in Wikipedia: Configuration management database. Maar ik begrijp dat Puppet juist iets is om remote een PC te kunnen beheren qua software patches, imaging e.d.?

Denk dat jij op CMDB tooling doelt ipv CM system zoals hier het geval is.
Wat ik begrepen heb is dat je met puppet via 1 puppetmaster de configuratie voor veel servers kan centraliseren. Soort van GPO (denk dat ik hier nat ga) zoals in windows?? Maar dan on steriods als ik de beschrijvingen goed begrijp

IIG zie ik in Puppet de kans om mij te verbeteren in CLI & VIM scripting. Denk dat het voor mijn profiel een meerwaarde is om kennis hiervan te hebben.

[ Voor 3% gewijzigd door Anoniem: 91397 op 16-03-2012 16:52 ]

[Boudewijn]

CptChaos schreef op vrijdag 16 maart 2012 @ 16:36:
[...]
Configuration Management is een ruim begrijp, ik denk dat Puppet iets anders is als wat ik nu denk dat het is. Ik doel meer op een functionaliteit zoals omschreven in Wikipedia: Configuration management database. Maar ik begrijp dat Puppet juist iets is om remote een PC te kunnen beheren qua software patches, imaging e.d.?

Dat kan je ermee doen, maar je kunt ook veelvoorkomende configuratie-dingen makkelijker op lossen; zie mijn scenario van hierboven.
als je een stel webservers hebt kun je ook de taken overhevelen van de ene naar de andere server door gewoon de statements te knippen-plakken in je server definities.

Een ander ding dat heel gaaf is: je kunt OS onafhankelijk werken... ik heb een recipe geschreven voor denyhosts waarbij mijn configuratie gepushed wordt. Beetje jammer dat debian en centos verschillende paden hebben voor logfiles en PIDs enzo. Kan ik mijn configuratie weer niet pushen ... of toch wel?!

Tuurlijk kan dat:

code:

<% if operatingsystem == "CentOS" %>
LOCK_FILE = /var/lock/subsys/denyhosts
<% else %>
LOCK_FILE = /var/run/denyhosts.pid
<% end %>

Heb ik in mijn template gezet. De code ga ik niet uitleggen, en ik doe de (relatief ongevaarlijke omdat het mijn eigen serverpark is) aanname dat als het geen Centos is, het Debian is...

Hierbij gebruik je in je templates (maar evt ook in je manifests) facter; facter is een tool waarmee je je lokale systeem in runtime kunt querien. Dingen als users, Ipadressen, hardware, OS-dingen noem maar op.

Dit maakt het mogelijk om in runtime je template in te vullen.
(linkje: http://puppetlabs.com/puppet/related-projects/facter/).


Ik gebruik het ook in een project dat op debian en centos moet draaien, waarbij de apache user gebruikt moet worden. If centos -> apache, if debian --> www-data.

Dat soort trucs. Je abstraheert je distro-specifieke dingen redelijk: je zegt gewoon "installeer apache" , of dat nu via apt, rpm of portage gaat mag puppet lekker zelf uitzoeken.

Een ander punt is dat kleine wijzigingen heel makkelijk uitgerold worden: ik heb zo'n 30 NRPE servers en wil wel eens een check toevoegen of aanpassen. Rotwerkje om die 30 bakken af te lopen.

Laatste punt is dat ik hiermee nieuwe servers kan prepareren voor de werking in mijn bedrijf; de standaard users en utilities worden automagisch geinstalleerd door puppet, net als public keys etc.
Scheelt veel saai post-install werk.

Anoniem: 91397 schreef op vrijdag 16 maart 2012 @ 16:49:
[...]


Denk dat jij op CMDB tooling doelt ipv CM system zoals hier het geval is.
Wat ik begrepen heb is dat je met puppet via 1 puppetmaster de configuratie voor veel servers kan centraliseren. Soort van GPO (denk dat ik hier nat ga) zoals in windows?? Maar dan on steriods als ik de beschrijvingen goed begrijp

IIG zie ik in Puppet de kans om mij te verbeteren in CLI & VIM scripting. Denk dat het voor mijn profiel een meerwaarde is om kennis hiervan te hebben.

Ik denk dat ik hem verkeerd begrijp maar je kunt idd prima je ~/.vimrc deployen met puppet ja.

Qua GPO's: ik weet het niet, ik ben geen windows-dude.

[ Voor 12% gewijzigd door Boudewijn op 17-03-2012 14:10 ]

[Boudewijn]

psyBSD schreef op vrijdag 16 maart 2012 @ 16:13:
Ah, right... foreman... helemaal vergeten. Is dat nu een beetje stabiel?

Ik moet echt weer terug kijken naar Puppet, het lijkt een stuk verbeterd sinds de laatste keer dat ik er mee gewerkt heb.

Een voormalige klant van mij gebruikt het, en daar lijkt het voor een redelijk aantal servers goed te werken. Ik heb me er nog niet in verdiept.

Ga vandaag trouwens mijn mysql-testding afmaken en kijken hoe lekker dat werkt met verschillende recipes.

[CAPSLOCK2000]

Ik heb er genoeg van gezien om te durven zeggen dat Puppet productieklaar is. Maar het is wel een tool voor de professionele IT'er. Ik wil niet zeggen dat puppet niet nuttig is als je maar 1 server hebt, maar het is wel een hoop extra werk. Als pro verdien je die tijd later makkelijk terug maar het vereist wel discipline.
Als ik voor vrienden een website opzet of iets dergelijks verbazen ze zich over het feit dat ik 'moelijk' loop te doen met puppet en niet 'gewoon' even die file edit ofzo want op die manier duren dingen drie keer langer.
Ik heb wel eens een stevige discussie gehad toen puppet iemands handmatige aanpassingen overschreef. Ik zie dat als voordeel, had ie maar niet de cowboy uit moeten hangen, maar het werd me niet in dank afgenomen.

[Boudewijn]

Puppet wel, maar foreman? Imo zou het ook prima moeten kunnen .


Grmbl, ik heb op mijn prutssetup en clients de ssl sleutels vernaggeld op de een of andere manier (ik cloon clients en bij opnieuw aanmelden ging eea mis).

Moet eens uitzoeken waar deze error vandaan komt:

code:

root@openca-packager:/var/lib/puppet/ssl# puppet agent --test --noop --server 192.168.1.100 --waitforcert 10
err: Could not retrieve catalog from remote server: SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B: certificate verify failed
warning: Not using cache on failed catalog
err: Could not retrieve catalog; skipping run
err: Could not send report: SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B: certificate verify failed

SSL prut op client en server wegmieteren (en passant op de productie ipv test gedaan ) en daarna opnieuw aanmelden fixte de boel.

[ Voor 8% gewijzigd door Boudewijn op 18-03-2012 02:04 ]

[Boudewijn]

Goed, ik zit een beetje vast met een standaard mysql module, te weten:
https://github.com/camptocamp/puppet-mysql

Deze heb ik genomen omdat je makkelijk databases + grants kunt definieren.

Netjes ook een

code:

Exec { path => "/usr/bin:/bin" }

aangemaakt en pwgen op mijn puppetmaster geinstalleerd.

Prima de bima.

Ook de augeas module geinstalleerd waar aan gerefereerd wordt is geinstalleerd net als augeas zelf (de machines zijn nog schoon omdat het mijn testomgeving is).


Punt is dat hij toch eea vernaggeld met passwords en my.cnf, en ik ook directories met de hand aan moet gaan maken etc. Maw: ik heb niet de indruk dat het allemaal heel stabiel/lekker/bugvrij werkt.

Welke mysql recipes gebruiken jullie eigenlijk? Doel is databases+grants managen. installeren van mysql is leuk maar dat kan ik zelf ook nog wel bouwen .

[ Voor 7% gewijzigd door Boudewijn op 18-03-2012 21:17 ]

[LLaTeM]

Nog een paar handige sites voor mensen die met puppet aan de slag willen;

Schrijf je manifests volgens de Puppet Style Guide;
http://docs.puppetlabs.com/guides/style_guide.html

Controleer je huidige manifests of ze aan de Puppet Style Guide voldoen;
https://github.com/rodjek/puppet-lint

En hou de belangrijkste Puppet blogs bij;
http://planetpuppet.org/

[software]

Ik ben ook een aanhanger van Puppet. Werkt fantastisch om je configuraties gelijk te houden.
We hebben hier ook 3 verschillende omgevingen opgezet (testing, acceptatie, productie).

Voor bepaalde projecten steek ik zelf de hele LVM volume config in een manifest. Volledig van aanmaken tot mounten en de juiste rechten geven.
Voor dit project beheren we naast LVM ook de packages, ssh keys, apache configs, users, cron's, iptables, ...

Werkt fantastisch goed. 1 minpunt is het Puppet dashboard (mysql backend), dat goed werkt, maar verschikkelijk traag is.
Duurt 10 sec vooralleer de homepage geladen is. Eens de homepage geladen is, werkt de rest gelukkig rapper.

[Boudewijn]

software schreef op zondag 18 maart 2012 @ 21:31:
Werkt fantastisch goed. 1 minpunt is het Puppet dashboard (mysql backend), dat goed werkt, maar verschikkelijk traag is.
Duurt 10 sec vooralleer de homepage geladen is. Eens de homepage geladen is, werkt de rest gelukkig rapper.

Zou het niet handig zijn om dan eens naar foreman te kijken? Afaik doet die het wat beter dan puppet dashboard en biedt deze toch dezelfde features.

[software]

We hadden al eens gekeken naar foreman, ongeveer 1.5 jaar geleden. We liepen er niet direct warm van.
Bovendien hebben we een paar zelf geschreven API's die het puppet dashboard aanspreken voor ons management systemen. Voor het moment zitten we vast met het dashboard.

Misschien toch maar eens foreman een nieuwe kans geven. De nieuwe versies zien er goed uit.

We hebben vorige week de nieuwe versie geinstalleerd van het Dashboard dat toch merkbaar veel sneller is.
Hopelijk bij de volgende versie, nog wat rapper.

[ Voor 9% gewijzigd door software op 18-03-2012 21:40 ]

[LLaTeM]

software schreef op zondag 18 maart 2012 @ 21:31:

Werkt fantastisch goed. 1 minpunt is het Puppet dashboard (mysql backend), dat goed werkt, maar verschikkelijk traag is.
Duurt 10 sec vooralleer de homepage geladen is. Eens de homepage geladen is, werkt de rest gelukkig rapper.

heb je al eens geprobeerd om een browser lokaal op je puppet dashboard server te starten, dat werkt een stuk sneller hebben wij gemerkt.

[Boudewijn]

Ik heb trouwens https://github.com/camptocamp/puppet-mysql alsnog werkend gekregen.

wat mij dan op debian opvalt is dat je augeas-lenses geinstalleerd moet hebben en een directory nog even aan moet maken. Hebben jullie augeas-lenses standaard geinstalleerd staan?
Ik dus niet... en twijfel of ik het in het recipe erbij ga zetten.

En nog een tweede vraag:

Ik heb in mijn bedrijf 2 soorten bacula machines: 1 server (met daarop configs voor clients) die zowel director als storage speelt, en x clients (met daarop alleen de filedaemon)
Op beide machines (binnen de client-server combinatie) moet ik 1 en hetzelfde password hebben, en ik heb daar nu recipes voor.

Even de code erbij:

code:

class bacula-server {
  $deps = ['bacula','bacula-director-mysql','bacula-sd-mysql','bacula-director-common', 'bacula-sd']

  package { $deps:
   ensure => present,
  }
  
  service {'bacula-director':
   ensure => running,
   require => [ Package["bacula-director-common"]],
   enable => true,
   hasstatus => true,
  }
  
  service {'bacula-sd':
   ensure => running,
   require => [ Package["bacula-sd"]],
   enable => true,
  }

  define bacula-client ( $password, $clientFQDN, $prio="10", $fileset="Full Set") {
   $client_config="/etc/bacula/clients/${name}.conf"

   file { $client_config:
    mode    => "600",
    owner => "bacula",
    require => [ Service["bacula-sd"], Service["bacula-director"] ],
    content => template("bacula-server/client.conf"),
   }
 
   notify {"Config created: ":
    message => "Creating config ${client_config}",
   }
   
   exec { "/etc/init.d/bacula-dir restart":
    subscribe => File[$client_config],
    refreshonly => true
   }


 }
}

En de bacula-client:

code:

root@puppetmaster:/etc/puppet/modules# cat bacula-client/manifests/init.pp 
class bacula-client {
  package { 'bacula-fd':
   ensure => present,
  }
  
  service {'bacula-fd':
   ensure => running,
   require => [ Package["bacula-fd"]],
   enable => true,
  }


  define bacula-client ( $director = "leiden-dir", $password) {
   file { "/etc/bacula/bacula-fd.conf":
    mode    => "600",
    owner => "bacula",
    require => [ Package["bacula-fd"], Service["bacula-fd"] ],
    content => template("bacula-client/bacula-fd.conf"),
   }
  }

}

Het werkt, maar ik heb 2 kanttekeningen (als mensen een beter idee hebben hoe dit te tackelen of commentaar hoor ik het graag).
Ik moet 2x een password invullen in mijn nodes definitie:

code:

# de bacula server
node 'foo.boudewijnector.nl' inherits basenode {
    include bacula-server
    
    bacula-server::bacula-client { "bar": password => "*",clientFQDN=> "bar.bla.tld"}
}


node 'bar.boudewijnector.nl' inherits xs4all-host {
    include bacula-client
    bacula-client::bacula-client{ "foo" : director => "directornaam", password => "*" }
}

Kan ik dit niet fraaier oplossen?


En ik herstart de bacula-director gewoon na een config change. Op zich niet erg, tenzij er jobs op dat moment draaien of gescheduled staan. Die verdwijnen, en een reload werkt niet om nieuwe files in te lezen.

[ Voor 80% gewijzigd door Boudewijn op 19-03-2012 10:37 ]

[Kees]

Boudewijn schreef op zondag 18 maart 2012 @ 22:02:
Ik moet 2x een password invullen in mijn nodes definitie:

Kan ik dit niet fraaier oplossen?

code:

# de bacula server
$bacula-password = "b4cul4"

node 'foo.boudewijnector.nl' inherits basenode {
    include bacula-server
    
    bacula-server::bacula-client { "bar": password => $bacula-password,clientFQDN=> "bar.bla.tld"}
}


node 'bar.boudewijnector.nl' inherits xs4all-host {
    include bacula-client
    bacula-client::bacula-client{ "foo" : director => "directornaam", password => $bacula-password }
}

Werkt dat niet?

[Boudewijn]

Ja dat zou kunnen, maar ik heb dan 30 passwords in mijn node config.

Ik doelde er meer op dat 1 recipe zowel de client als de serverkant regelt .

[Kees]

Boudewijn schreef op maandag 19 maart 2012 @ 11:35:
Ja dat zou kunnen, maar ik heb dan 30 passwords in mijn node config.

Ik doelde er meer op dat 1 recipe zowel de client als de serverkant regelt .

Ja natuurlijk kan dat

Gewoon een recipe alla:

code:

class bacula ($type="client", $pass="blaat", $director = "leiden-dir") {

if ($type = "server") {
..do server dingen
}

client-dingen
}

[Boudewijn]

Haha volgens mij leg ik niet goed uit wat ik wil.
Ik wil eigenlijk 1 recipe dat ik 1 keer aanroep en dan op beide hosts wat regelt, maar volgens mij kan dat niet.


Maw: ik definieer in de bacula server "hoi je hebt deze client en je mag dit password gebruiken bij deze fileset" en bacula deployt het dan op zowel client als server.
Ik zit nu voor 1 functionaliteit (een backup config) op 2 plekken regels neer te zetten en dat vind ik eerlijk gezegd niet heel strak.

[software]

LLaTeM schreef op zondag 18 maart 2012 @ 22:00:
[...]

heb je al eens geprobeerd om een browser lokaal op je puppet dashboard server te starten, dat werkt een stuk sneller hebben wij gemerkt.

Heeft niet direct veel snelheids winst gegeven. We hebben nu de DB draaien op een dedicated server.
Werkt al een stukje sneller

[Boudewijn]

Goed ik ben ook eens heftig bezig met puppet om een servertje in te richten, met het volgende doel:


- installeer een zelf-gepackagede deb file, die ik via filebucketing binnenhaal.
- trek dependencies binnnen
- installeer (en configureer) apache en mysql

- configure de software in kwestie
- compileer de software in kwestie (openca)
- knal wat passwords her en der in
- laad de DB

- copieer de webroot middels de makefile van openca
- doe evt nog wat klein config spul zoals fw enzo.

Nu is dit een redelijke berg facts die ik op ga voeren en ik ben van plan om het ook met stages te doen , zoals deze kerel:http://glarizza.posterous.com/using-run-stages-with-puppet


Nu wil ik 3 stages maken (pre main en post)....hierboven zie je al een indeling in die 3 stages en daarbinnen dan met dependencies de middels een interfact-dependencies of een file["bla"] -> exec ["foo"] 'treintje' oplossen.


Ik zit nu op 200 regels aan puppet code en zo'n 40 facts. ik wil zo min mogelijk zelf regelen maar het is bijvoorbeeld een keiharde eis dat ik een specifieke debian package installeer voor ik die software ga compileren.
Daarom die stages.


Heeft iemand hier ervaring mee?


Het compileren wil ik trouwens gaan doen door een simpel bash script te maken dat door puppet ge'exect wordt. Dit voelt ergens als 'beter' voor me dan het in een exec zelf te doen, maar wellicht gooi ik dat alsnog om.

[Boudewijn]

Hmmz uiteindelijk heb ik mijn compilatie-prut ook maar eens uitgeschreven in puppet. Daar moet ik straks eigenlijk een klasse voor schrijven, maar voorlopig voldoet deze snippet:

code:

    exec{"unpack_openca_tarball":
        require         => File["/tmp/openca-base-${install_version}.tar.gz"],
        command         => "tar xfzp openca-base-${install_version}.tar.gz",
        cwd             => "/tmp",
        #TODO: unless exists openca-base-$[openca_version]
    }

    exec{"configure openca":
        require         => File[$openca_build_dir],
        cwd             => $openca_build_dir,
        command         => "${openca_build_dir}/configure ${configure_flags} && touch _is_configured",  
        creates         => "${$openca_build_dir}/_is_configured",
        logoutput       => true,
    }

    exec{"make openca":
        cwd             => $openca_build_dir,
        command         => "make && touch _is_made", 
        require         => Exec["configure openca"],
        creates         => "${$openca_build_dir}/_is_made",
        logoutput       => true,
    }

Heeft iemand hier al wat bestaande code voor, anders ga ik ^^ maar eens verklassen. (ja het is niet het hele recipe, dat behelst wat meer, maar dit is wel de relevante code gok ik zo).

[Boudewijn]

Ik ben lekker nog bezig met puppet en heb een cykel in mijn afhankelijkheidsgraaf gemaakt, en ik wil dat eigenlijk wat mooier zien (heb hem al lang gevonden btw).

Weet iemand of puppet wat meer info kan geven dan:

code:

<een grote lijst deps>.... try using the '--graph' option and open the '.dot' files in OmniGraffle or GraphViz

Volgens mij kun je in dot files prima cykels vinden, en dat dan in je error neergooien. * Boudewijn krijgt jeuk om ff wat te coden .

[dommerick]

Grappig. Een puppet topic. Toen ik vorig jaar zocht kon ik hier op tweakers helemaal niks over vinden. Voor mijn stage heb ik puppet uitgezocht. Leuk speelgoed, jammer dat ik nu geen servers meer beheer.

[Boudewijn]

Je had ook gewoon het puppet-topic kunnen starten? .
Beetje een open-deur, maar toch.

[Boudewijn]

hoihoi

Weet iemand hoe je kunt voorkomen dat je .svn files serveert?

De ignore optie van de File klasse lijkt mij zeer geschikt:

Ruby:

    # tftp root
    file {'tftp root': 
        ensure => present,
        path    => "${tftp_root}",
        recurse => true,
        links => follow,
        source => "puppet:///modules/<projectnaam>//srv",
        ignore => ".*\.svn.*",

        purge => true, # purge all unmanaged junk
        force => true, # also purge subdirs and links etc.
    }

Nu serveer ik vanuit <projectnaam>/files/srv een directory (met daarin de inhoud van mijn tftp root) die in SVN ligt. Daardoor heb je allemaal .svn directories er tussen zitten.
Dit is een bewuste keuze omdat ik mijn tftproot ook ontwikkel en graag dus ook versioneer.

Alleen nu wordt al die prut dus meegepulld door de client, en dat na elke subversion commit . Heel irritant.... op de puppet server de boel verwijderen is niet zo'n optie omdat daarvandaan ook nog wel eens gecommit wordt.

Dus ik wil het zo maar doen.

Alleen de regex zou moeten kloppen, ik wil alle files/directories met daarin .svn ignoren.

Dit staat in de manual:

ignore
A parameter which omits action on files matching specified patterns during recursion. Uses Ruby’s builtin globbing engine, so shell metacharacters are fully supported, e.g. [a-z]*. Matches that would descend into the directory structure are ignored, e.g., */*.

Nu vraag ik me af of mijn logica faalt, of dat die laatste regel toch iets vernaggelt.

Een stukje van een noop'je in puppet:

code:

notice: /File[/srv/tftp/debian-installer/amd64/pxelinux.0]/ensure: is absent, should be file (noop)
notice: /File[/srv/tftp/debian-installer/amd64/pxelinux.cfg]/ensure: is absent, should be directory (noop)
notice: /File[/srv/tftp/debian-installer/amd64/pxelinux.cfg/.svn]/ensure: is absent, should be directory (noop)
notice: /File[/srv/tftp/debian-installer/amd64/pxelinux.cfg/.svn/all-wcprops]/ensure: is absent, should be file (noop)
notice: /File[/srv/tftp/debian-installer/amd64/pxelinux.cfg/.svn/entries]/ensure: is absent, should be file (noop)
notice: /File[/srv/tftp/debian-installer/amd64/pxelinux.cfg/.svn/prop-base]/ensure: is absent, should be directory (noop)
notice: /File[/srv/tftp/debian-installer/amd64/pxelinux.cfg/.svn/prop-base/default.svn-base]/ensure: is absent, should be file (noop)
notice: /File[/srv/tftp/debian-installer/amd64/pxelinux.cfg/.svn/props]/ensure: is absent, should be directory (noop)
notice: /File[/srv/tftp/debian-installer/amd64/pxelinux.cfg/.svn/text-base]/ensure: is absent, should be directory (noop)
notice: /File[/srv/tftp/debian-installer/amd64/pxelinux.cfg/.svn/text-base/default.svn-base]/ensure: is absent, should be file (noop)
notice: /File[/srv/tftp/debian-installer/amd64/pxelinux.cfg/.svn/tmp]/ensure: is absent, should be directory (noop)
notice: /File[/srv/tftp/debian-installer/amd64/pxelinux.cfg/.svn/tmp/prop-base]/ensure: is absent, should be directory (noop)
notice: /File[/srv/tftp/debian-installer/amd64/pxelinux.cfg/.svn/tmp/props]/ensure: is absent, should be directory (noop)
notice: /File[/srv/tftp/debian-installer/amd64/pxelinux.cfg/.svn/tmp/text-base]/ensure: is absent, should be directory (noop)
notice: /File[/srv/tftp/debian-installer/amd64/pxelinux.cfg/default]/ensure: is absent, should be file (noop)
notice: /File[/srv/tftp/pxelinux.0]/ensure: is absent, should be file (noop)
notice: /File[/srv/tftp/pxelinux.cfg]/ensure: is absent, should be directory (noop)

Die eerste twee en die laatste twee moeten geserveerd worden, en de rest dus niet.

[Anoniem: 464235]

Op mn werk ben ik ook druk aan het lobbyen om puppet in onze productie te gooien. De enige echte limitatie vind ik tot nu toe de file distributie. Standaard word er gebruik gemaakt van webrick, de ingebouwde webserver van ruby. Zelf heb ik puppet op een aantal prive servers draaien maar vind het distribueren van kleine bestandjes toch niet echt rap gaan.

Her en der op het op het internet lees ik dat er ook wat serieuze limitaties op webrick zitten als je het in een wat omvangrijkere omgeving gaat gebruiken. Nu kan er gebruik gemaakt worden van mongrel icm. apache of nginx oid om files via meerdere nodes te verspreiden. Heeft iemand hier ervaring mee om te delen?
(link: http://projects.puppetlabs.com/projects/1/wiki/Using_Mongrel)

Zelf ga ik er ook nog even mee knoeien en zal mn bevindingen posten....

update:
puppet heb ik nu draaiend met mongrel en een httpd reverse-proxy, als je de handleiding volgt is het echt een fluitje van een cent. De reverse-proxy vanuit httpd verdeeld de inkomende clientconnecties over de puppetmaster instanties.

Nu heb ik een setup om goed door te testen en bij succes op +/- 130 centos kistjes uit te rollen
Heeft nog iemand zoiets draaien en nog eventuele tips of tricks te delen?

[ Voor 44% gewijzigd door Anoniem: 464235 op 11-07-2012 00:36 ]

[Kees]

Boudewijn schreef op maandag 02 juli 2012 @ 15:06:
hoihoi

Weet iemand hoe je kunt voorkomen dat je .svn files serveert?

Ik laat ze appart weer verwijderen met een

code:

    file { "/etc/php5/conf.d/.svn" :
        ensure => absent,
        recurse => true,
        purge => true,
        force => true,
    }

wat niet zo erg is, want ik heb maar een paar dirs die ik compleet sync

[b][message=38563247,noline]Zelf heb ik puppet op een aantal prive servers draaien maar vind het distribueren van kleine bestandjes toch niet echt rap gaan.

Ik heb daar (met zo'n 40 servers) niet echt veel last van, ook al is het traag, het is vaak maar 1 keer binnenhalen. Als je honderden servers hebt, dan kan het mischien een limiet zijn.

[Anoniem: 464235]

Ook deze link is handig als je een geclusterd setupje wilt bouwen: http://docs.puppetlabs.co...ing_multiple_masters.html
Het moraal is laat een master meerdere masters beheren waar de clients dan weer mee connecten.

Dat bewijst toch weer dat het werkt als een tierelier, gebruik puppet om puppet te clusteren... of klinkt dit nou vreemd?

[Boudewijn]

Kees schreef op dinsdag 10 juli 2012 @ 21:58:
[...]

Ik laat ze appart weer verwijderen met een

code:

    file { "/etc/php5/conf.d/.svn" :
        ensure => absent,
        recurse => true,
        purge => true,
        force => true,
    }

wat niet zo erg is, want ik heb maar een paar dirs die ik compleet sync

Ik heb dit nu staan maar echt mooi is dat niet:

code:

    # tftp root
    file {'tftp root': 
        ensure => present,
        path    => "${tftp_root}",
        recurse => true,
        links   => follow,
        source  => "puppet:///modules/ehbi-pxe-data//pxeroot",
        purge   => true, # purge all unmanaged junk
        force   => true, # also purge subdirs and links etc.
    }

    # tftp root
    file {'clean tftp root': 
        ensure => absent,
        path    => "${tftp_root}/*.svn",
        purge   => true,
        recurse => true,
        links   => follow,
        force   => true, # also purge subdirs and links etc.
    }

Plus dat het verdorie niet eens werkt.


Die ignore optie zou echt veel mooier zijn omdat je het maar in 1 stap hoeft te doen; al die SVN prut copieren duurt ook een uur .

Maar, uiteraard heeft de community een oplossing:
http://michal-bryxi.blogs...ke-puppet-ignore-svn.html

It is right behavior because you are just telling puppet to ensure that all files and directories from some_directory should appear in /tmp/test_directory. But this behavior is often not desired. You can suppress this either by changing each similar statement to:

file { "/tmp/test_directory":
ensure => directory,
recurse => true,
source => "puppet:///some_module/some_directory",
ignore => ".svn"
}

Or if you want to change this behavior globally, you can just add statement below to manifests/site.pp

File { ignore => '.svn' }

* Boudewijn loves puppet.


Ander puntje dat raar is is dit:

code:

err: /File[/srv/tftp/pxelinux.cfg]: Could not evaluate: Got nil value for content
err: /File[/srv/tftp/pxelinux.cfg/default]/ensure: change from absent to present failed: Could not set 'present on ensure: No such file or directory - /srv/tftp/pxelinux.cfg/default.puppettmp_8523

Okay ik wil die directory inderdaad serveren, maar het is een symlink op de puppetmaster:

# ls -al
total 24
drwxrwxr-x 5 boudewijn boudewijn 4096 Jul 20 13:47 .
drwxrwxr-x 5 boudewijn boudewijn 4096 Jul 20 13:47 ..
drwxrwxr-x 4 boudewijn boudewijn 4096 Jul 20 13:47 debian-installer
lrwxrwxrwx 1 boudewijn boudewijn   33 Jul 20 13:47 pxelinux.0 -> debian-installer/amd64/pxelinux.0
lrwxrwxrwx 1 boudewijn boudewijn   35 Jul 20 13:47 pxelinux.cfg -> debian-installer/amd64/pxelinux.cfg
drwxrwxr-x 6 boudewijn boudewijn 4096 Jul 20 13:47 .svn
drwxrwxr-x 4 boudewijn boudewijn 4096 Jul 20 13:47 tftp
-rw-rw-r-- 1 boudewijn boudewijn   60 Jul 20 13:47 version.info

eens kijken hoe ik dat ga tackelen .

[Freeaqingme]

Een puppet topic, \o/
snap alleen niet dat het zo rustig is in dit topic voor een site als GoT.

Wat ik nog mis is Vagrant. Ikzelf werk bij een ontwikkeltoko waarbij iedereen lokaal ontwikkelt, en ieder project zijn eigen OTAP straat heeft. Omgevingen volledig in sync houden is iets wat weinig voorkomt. Hiervoor ben ik nu Vagrant aan het opzetten. Een developer kloont een project met git, typt vervolgens `vagrant up` en hij/zij krijgt een volledige virtualbox vm geserveerd welke live ingericht wordt aan de hand van de centrale puppet master.

Ook bij ons staat de volledige puppet master config in git. Dat werkt als functionele backup, maar wat ik me wel afvraag is hoe jullie omgaan met je PKI etc. Developers kunnen hun eigen manifesten aandragen, en hebben (dus) ook toegang tot de repo met de puppetmaster config. Echter hoeven deze geen toegang m.i. te hebben tot bijv. de puppet pki. (ik moet nog kijken naar Hiera om bijv. passwords mee te managen).

[Intru]

Leuk, een puppet topic op GoT! Ik was me wat aan het inlezen (om te kijken of puppet nuttig is in mijn situatie), en kwam de blogpost van Boudewijn tegen. Het voorbeeld met de vhosts was precies wat ik nodig had om in te zien dat ik zeker wat aan puppet ga hebben!

Ik zal ook nog even mijn use case bespreken hier. We beheren op dit moment 1 server waarop meerdere klanten allemaal een eigen instance van een php applicatie draaien. In feite draaien al onze klanten dus gewoon een eigen website, maar wel met dezelfde structuur. Op dit moment beheren we dit nog vanuit DirectAdmin, en het toevoegen van een klant is niet echt een feest:

• vanuit DA een nieuwe gebruiker aanmaken met subdomein (*klantnaam*.onzesite.nl)
• Inloggen (in DA) als deze gebruiker, en een MySQL database + gebruiker aanmaken
• Via SSH inloggen als nieuwe gebruiker, git checkout doen van het project
• Config files aanpassen (oa MySQL gegevens)
• Init script draaien (permissions, lege database importeren)
• in DA cronjobs instellen

Niks extreems, maar niet echt leuk om met de hand te doen. En wanneer je er niet helemaal bij bent, wil er natuurlijk nog wel eens een foutje in glippen.

Volgens mij moeten (bijna) al deze zaken ook te beheren zijn met puppet. Dan zou het toevoegen van een nieuwe klant veranderen in een aanroep voor nieuwe gebruiker/vhost/database via puppet (dat is vast ook te combineren, right?).

Dat betekent nog wel dat alle klanten hardcoded in de recipe staan, maar dat is nog steeds een behoorlijk vooruitgang. Is het ook mogelijk om een hoop definities extern te beheren (bv via een database). Zodat je niet een enorme lijst krijgt met:

code:

apache::simple-vhost { "www.foo.bar" : aliases => ["foo.bar"] }
apache::simple-vhost { "test.foo.bar" : aliases => [] }

[Boudewijn]

Dat kan prima, al dan niet via puppet dashboard denk ik, maar ik heb het nog nooit gebruikt (wil dat binnenkort wel gaan doen), zie bijvoorbeeld: http://www.tomhayman.co.u...ed-configs-centos-6-part/ .

Heb je daar wat aan?

[Intru]

Ziet er zeker interessant uit, ik zal me eens wat verdiepen in puppet dashboard. Ik zie nog niet direct hoe je via dashboard makkelijk nieuwe vhosts kan aanmaken, maar dat ligt wellicht aan mij.

edit: het lijkt er op dat je met Hiera makkelijk al deze vhosts kan bijhouden.

[ Voor 17% gewijzigd door Intru op 29-11-2012 15:51 ]

[Boudewijn]

En, is het nog gelukt?


Ik zit ook nog met een beetje een issue, in het kader van een projectje. Hierbij heb ik een stel clients die een hele zwik recipes moeten krijgen maar waarbij ik eigenlijk geen zin heb om een heel erg cluttered nodes.pp file te krijgen.

Het gaat zo om +- 40 modules (verwacht ik) per machine, waarbij ze gelukkig wel allemaal dezelfde set krijgen. Kan ik niet een include * achtig iets doen?
Anders ga ik inderdaad met een recipe schrijven dat handmatig de andere recipes vereist, maar ik moet wel nog uitzoeken hoe ik dat voor elkaar ga krijgen .

[dj-wasabi]

Je kan bijvoorbeeld in je manifests directory een infa.pp aanmaken:

code:

node basenode {
  include mysql
  include ssh
  include ntp
  include pizza
}

En dan bijv. je node:

code:

node 'web.example.com' inherits basenode {
  # blabla
}

De 'web.example.com' heeft dus nu de mysql, ssh, ntp en pizza module geladen.

Je moet dan nog wel even in je 'site.pp' file het volgende includen:

code:

import infra.pp

[ Voor 13% gewijzigd door dj-wasabi op 20-12-2012 15:22 ]

[Boudewijn]

Ja dat klopt, maar dan ben je het op node-niveau aan het doen. Als je heel veel modules hebt moet je dat nog steeds per module toevoegen.

Ik wil eigenlijk include * doen oid .

[dj-wasabi]

Ja, maar het is wel overzichtelijker lijkt mij?

Bij de "infra.pp" file waar de basenode in zit, daar zet ik juist alles in wat voor alle machines moet gelden voor die omgeving. Denk aan ntp, dns servers, yum repositories etc. Daarbij zal de specifieke nodes voor de machine's zelf kleiner worden en kan er misschien wat met reguliere expressies opgelost worden met minder aantal node definites.

Ik denk dat je het te complex voor jezelf gaat maken als je 1 module gaat maken die alles doet. (Wat misschien nu wel leuk kan zijn om dat allemaal uit te vogelen, maar uiteindelijk moet het over 6 maanden nog steeds te snappen zijn als je iets moet aanpassen..)

Of praten we langs elkaar?

[Boudewijn]

Nou in mijn specifieke setup (deze specifieke dan!) gebruik ik het om bakken te configureren die allemaal identiek zijn. In die infra.pp ga ik dan een basenode krijgen en in de nodes.pp allemaal nodes die die basenode includen.

Wat ik zelf het liefst zou doen is eigenlijk 3 recipes hebbben:

presetup
setup
postsetup


Waarbij presetup wat basic spul installeert (X, drivers dat soort spul)
setup een berg apps
postsetup wat user-customisable spul doet en artwork enzo.

Dit kan dan door al die handelingen in elke stap te zetten, maar ik had liever dat ik in elk van de 3 stappen gewoon een berg recipes include die in die stap uitgevoerd moeten worden.

Het liefst zou ik nml wel weer per applicatie een eigen recipe wilen, maar ze dan toch op de een of andere manier willen groeperen .

[dj-wasabi]

Ok, maar je hebt in je modules directory wel hoop modules als xorg, ntp, ssh, httpd, mysql etc etc?
Als dat zo is, dan maak je nog 3 modules:

presetup/manifests/init.pp

code:

class presetup {
  include xorg
  $ntp_servers = ['ntp1.example.com','ntp2.example.com']
  include ntp
  include ...
}

setup/manifests/init.pp

code:

class setup {
  $vhost_dir = '/var/www/pizza'
  include httpd
  include ...
}

postsetup/manifests/init.pp

code:

class postsetup {
  include pizza
  include ...
}

Vervolgens definieer je in je nodes (of basenode)

code:

include presetup
include setup
include postsetup

(Volgens mij kan je met Puppet 3 dacht ik aangeven in welke volgorde je precies de includes geladen wilt hebben... Maar heb zelf nog niet zoveel ervaring met puppet 3)

En anders, succes! :-)

[dj-wasabi]

Kennen jullie trouwens puppet-lint ? Zie: http://www.puppet-lint.com

Vrij eenvoudig te installeren en te gebruiken:

code:

[root@centos6-base ~]# puppet-lint --with-filename /tmp/vagrant-puppet/modules-0/vmware
/tmp/vagrant-puppet/modules-0/vmware/manifests/install.pp - WARNING: top-scope variable being used without an explicit namespace on line 13
/tmp/vagrant-puppet/modules-0/vmware/manifests/install.pp - ERROR: trailing whitespace found on line 13
/tmp/vagrant-puppet/modules-0/vmware/manifests/install.pp - ERROR: trailing whitespace found on line 14
/tmp/vagrant-puppet/modules-0/vmware/manifests/install.pp - WARNING: double quoted string containing no variables on line 12
/tmp/vagrant-puppet/modules-0/vmware/manifests/install.pp - WARNING: double quoted string containing no variables on line 12
/tmp/vagrant-puppet/modules-0/vmware/manifests/install.pp - WARNING: double quoted string containing no variables on line 12
/tmp/vagrant-puppet/modules-0/vmware/manifests/install.pp - WARNING: double quoted string containing no variables on line 14
[root@centos6-base ~]#

De puppet-lint tool gaat kijken of je creaties wel voldoen aan de "puppet style guide" http://docs.puppetlabs.com/guides/style_guide.html

[mithras]

Sinds een week zijn wij ook aan het kijken naar Puppet. We zijn nog even aan het verkennen (bv laatst veel gekeken naar de Chef vs Puppet discussie). Waar ik me (toch bij beide systemen eigenlijk) over verwonder: hoe sla je nu veilig wachtwoorden op

Met het aantal VPSen wat we nu hebben (<10) is een korte handleiding genoeg en die volgen we. In de handleiding staat "[voer password in]" en alle beheerders weten dan wat in te vullen. Nergens staat enig pwd vermeld.

Dat gaat anders worden als we het automatiseren: Waar blijven wachtwoorden? Dat moet veilig (encrypted?) en liefst buiten de definities zelf (dus variabelen). Ik heb iets gelezen over extlookup, waar je in externe bestanden kan zoeken. Hiera is een zogezegd "beter" alternatief (maar eigenlijk is er niets hiërarchisch in onze configs), is dat zo?

Hoe dan ook: tips en trucs welkom

[dj-wasabi]

Schrijf je "ruby" ?
Anders zal je denk ik zelf een library moeten maken in je module om data uit bijv. mysql te halen. Zie hier een voorbeeld: http://serverfault.com/qu...e-in-puppet-3-0-templates

Anders zou ik het zo even 123 niet weten.

[Boudewijn]

Ik wil een recipe gebruiken van github dat augeas gebruikt (https://github.com/anchor/puppet-module-tcpwrappers) . Op zich prima de bima, ware het niet dat puppet hierop errort:

code:

root@www:~# puppet agent --test --server puppetmaster.X.nl  
err: Could not retrieve catalog from remote server: Error 400 on SERVER: Unknown function sum at /etc/puppet/modules/tcpwrappers/manifests/entry.pp:82 on node www.X.nl

okay prima, even naar de code kijken:

code:

            augeas {
                "${key}/new":
                    changes => sum($create_cmds, $extra_create_cmds),
                    onlyif  => "match ${key_entry} size == 0";
                $key:
                    changes => "set ${key_entry}/clients/client[.='${client_}'] '${client_}'",
                    onlyif  => "match ${key_entry}/clients/client[.='${client_}'] size == 0",
                    require => Augeas["${key}/new"];
            }

Makes sense.


Beide boxen draaien debian en hebben zowel augeas-lenses als augeas-tools geinstalleerd.

Weet iemand wat hier fout gaat?

[Boudewijn]

hmmz ik loop er nog/weer tegenaan.

Weet niemand waar die sum vandaan komt?

Hmmz en dan zie je hier iemand met een suggestie:
https://github.com/anchor/puppet-module-tcpwrappers/issues/1

Eens proberen.

[ Voor 46% gewijzigd door Boudewijn op 19-05-2013 23:38 ]

[Freeaqingme]

Kan het zijn dat het deze is? https://github.com/puppet...llective/aggregate/sum.rb

Alle functies worden standaard in <fuctinaam>.rb opgeslagen, zo kwam ik hier op uit. Geen idee of het is wat je nodig hebt.

Hoe schrijven jullie je puppet modules? Ik zelf gebruik nagenoeg uitsluitend die van example42, en waar iets niet volstaat contributen we het terug. Scheelt ons weer het onderhouden er van

[BarthezZ]

Mega schop

Ten eerste omdat Puppet onwijs tof is, ten tweede omdat ik eindelijk tijd en mogelijkheid (en een financierder/werkgever die me ervoor wilt betalen) heb gevonden.

Ik begon om eerlijk te zijn vrij sceptisch, met de grote vrees dat het pas de moeite waard zou worden bij tientallen servers etc... En moet eigenlijk zeggen dat het der mate simpel van toepassing is dat ook bij hele simpele semi-identieke installaties het gewoon de moeite waar is! Ik ben nog niet zo ver dat ik mijn eigen types en providers ga schrijven (ben geen ruby held), maar met puur bijvoorbeeld configuratie files creatief genereren valt al enorm enorm enorm veel te bereiken.

Om even een voorbeeld te noemen van wat ik nog niet in Puppet heb staan en mij frustreerde: Ik beheer en monitor vrij veel web clusters, en gebruik daar inmiddels Zabbix voor. Voor een stukje custom configuratie moest ik iets toevoegen aan de agent configuratie, maar dit moest opeens op 5 hosts gebeuren... Als het nou in Puppet had gestaan had ik gewoon weg even een snelle template geschreven, zodat ik meteen generiek dit soort wijzigignen kon doen, inclusief eventuele host specifieke zaken.

In de praktijk gebruik ik het voor de configuratie van VoIP software, in combinatie met een webinterface, mysql, apache, php, odbc koppeling, etc. etc. En alhoewel dat nog in ontwikkeling is, zie ik zo gruwelijk veel voordelen! Puppet heeft wel een beetje de manier veranderd hoe ik naar systeembeheer op meer dan één onafhankelijke host aankijk.

[CAPSLOCK2000]

Nadat ik een tijdje met Puppet gewerkt had vond ik het ook een echte eye-opener.
Van te voren kon ik wel een beetje inschatten dat het handig zou zijn, anders was ik er niet mee begonnen, maar ik had niet gedacht dat het zo diep zou inslaan. Ik zie mijn collectie VM's nu niet meer als losse machines, maar onderdelen van hetzelfde systeem. Ik doe al mijn beheer op 1 plek, de puppet-master. De andere systemen hoef ik eigenlijk niet meer te komen, dat zijn domme slaafjes van de master geworden.

[Freeaqingme]

CAPSLOCK2000 schreef op woensdag 28 augustus 2013 @ 11:21:
Ik doe al mijn beheer op 1 plek, de puppet-master.

Ik neem aan dat je een kopie van je puppetmaster lokaal hebt staan, en hier op ontwikkelt, voordat je het uberhaupt deployt naar je productie puppetmaster?

[CAPSLOCK2000]

Je hebt helemaal gelijk, ik ging een beetje kort door de bocht. Als het professioneel is zorg je uiteraard voor een OTAP-straat, maar thuis gebruik ik ook puppet, daar kras ik direct in de puppet-config. Dat staat nog steeds in versiebeheer, dus ik kan bij fouten altijd terug, maar OTAP kan ik thuis niet opbrengen.

Mijn punt was meer dat ik één directory heb met alle configs van al mijn systemen. Geen gedoe meer met heen en weer ssh-en of zoeken waar een bestand ook al weer stond. Alles staat in een git boom. Als ik iets zoek dan kan ik locate, find en grep gebruiken. Staat het daar niet, dan is het er nog niet.

[BarthezZ]

Waar ik trouwens wel benieuwd naar ben, en iets waar ik zelf tegen aanloop en me op dit moment heel veel tijd kost, hou gaan jullie om met software deployen (via puppet) waar geen distro-packages voor zijn?

Vanuit consistentie en herproduceerbaarheid (wat mede de reden is voor het gebruik van Puppet) zou ik zeggen alle software packagen (we hebben bijv standaard pakket + wat patches wat overal uitgerold word)... Maar toch kost het in de vingers krijgen van packagen best wel wat tijd en werk...

Comments?

[Freeaqingme]

Dan zou 't zonder puppet toch ook veel tijd kosten?

Ik zou kijken of je daar, los van puppet, alsnog een package van kan maken. Als dat geen optie is, hoe jij normaal deze software dingen installeert, kan je dat toch ook met Puppet doen? Desnoods maak je een apart install script, en roep je dat met 1 exec {} statement aan? (dan wel even een onlyif param toevoegen...)

[Anoniem: 294759]

BarthezZ schreef op donderdag 29 augustus 2013 @ 21:54:
Waar ik trouwens wel benieuwd naar ben, en iets waar ik zelf tegen aanloop en me op dit moment heel veel tijd kost, hou gaan jullie om met software deployen (via puppet) waar geen distro-packages voor zijn?

Vanuit consistentie en herproduceerbaarheid (wat mede de reden is voor het gebruik van Puppet) zou ik zeggen alle software packagen (we hebben bijv standaard pakket + wat patches wat overal uitgerold word)... Maar toch kost het in de vingers krijgen van packagen best wel wat tijd en werk...

Comments?

In een gezonde omgeving zorg je er zelf voor dat er een package komt en die rol je dan uit in jouw omgeving, op de OTAP principe. In het geval van bijvoorbeeld RPM packages, is het kwestie van goed in de vingers krijgen. En als het kan zou je dit ook via puppet kunnen doen. Maar packages per systeem compileren moet je niet willen.

[BarthezZ]

Agree, precies wat ik al dacht... Vannacht ergens toch gelukt om mijn packages (semi-netjes) te recompilen tegen CentOS 6 64 bit aan ipv 5, dus er is hoop... Gewoon nog even verder in de vingers krijgen

[Boudewijn]

Weet iemand hoe je het volgende voor elkaar krijgt?

Ik heb een webserver en een DB-server (mysql): als ik een vhost aanmaak wil ik eigenlijk daarin ook aangeven (default parameter) of een DB aangemaakt moet worden voor die vhost op de DB-server.
je zit hiermee op 2 verschillende puppet-nodes, waardoor je volgens mij per definitie uit de context van je webserver manifest komt.

Heeft iemand dit getackled?

[Freeaqingme]

Al eens naar exported resources gekeken? Zo nee kan ik morgen wel een voorbeeldje uitwerken...

[Boudewijn]

Nee dat heb ik nog niet, ik weet het keyword nog niet.
Als je een voorbeeldje hebt wil ik er graag naar kijken .

[Freeaqingme]

Morgen duurt nog lang

code:

node 'webserver' {

  include apache

  apache::vhost { 'www.google.com':
     path => '/srv/http/'
  }

  @@mysql::db { 'google':
     username => 'google',
     password => 'g00gle'
  }

}

node rdbms {

  include mysql
    
  Mysql::Db <<||>>

}

Het type Mysql::Db zou gewoon hoeft niets bijzonders te zijn, gewoon hetzelfde zoals je dat anders ook zou doen. Wat er gebeurt is dat apache::vhost uiteraard op de webserver node uitgevoerd wordt.Bij het compileren van de catalog wordt mysql::db niet in de catalog van de webserver node geplaatst, maar bewaard op de Puppet Server. Op het moment dat de rdbms-node langs komt, en pakt ie nu ook alle definities van @@mysql::db mee. Het evalueren van dingen als hiera values en dynamic databinden gebeurt tijdens het exporteren, dus op het moment dat de webservernode catalog gecompileerd wordt.

Is ook hier omschreven: http://docs.puppetlabs.co...erence/lang_exported.html

Ik weet niet hoe je architectuur qua classes etc er precies uitzet. Als je die eventueel iets verder kan beschrijven kan ik best meedenken. Voor het geheel heb je wel storeconfigs nodig (met bijvoorbeeld PuppetDb). Eventueel zou je op de rdbms-node ook nog kunnen filteren op welke exported resources 'ie daadwerkelijk moet uitvoeren, en eventueel nog params kan overriden.

[Boudewijn]

Dank voor je update. Had hem twee weken geleden al gezien maar ben helaas pas nu in staat om er verder aan te pielen . Ga er zo eens mee aan de slag.

Die storeconfigs etc moet ook nog ingeregeld worden, joepie... dat gaat weer wat tijd kosten .

[Freeaqingme]

Ik heb een tijdje in mijn nieuwe setup een puppetmasterless setup gebruikt, en die heb ik van de week omgebouwd naar een setup met een puppetmaster.

Door de volgende modules te gebruiken werkt het goeddeels out of the box:
https://github.com/example42/puppet-puppet
https://github.com/example42/puppet-puppetdb
https://github.com/example42/puppet-postgresql

[Boudewijn]

Okay daarmee manage je dus je puppetdb OP je master?

[Freeaqingme]

Yup, dat kan. De Puppet Master communiceert over http met PuppetDb, dus je kan PuppetDb ook op een losse bak installeren (of meerdere, en dat met een http loadbalancer balancen).

Hoeveel nodes heb je?

Vandaag overigens The Foreman geimplementeerd (op een andere bak dan de Puppet Master). Dit gebruiken we voorlopig als rapportage tool om alle facts en alle details over puppet runs te bekijken. Zo ontdekten we dat er op 25% van onze nodes een of meerdere manifesten resulteerden in errors. Dat dat het geval was wisten we, maar we hadden geen totaaloverzicht op welke nodes dat dan het geval zou zijn (die hebben we nu dan dus ook meteen opgelost).

Het alternatief hiervoor was Puppet Dashboard. We hebben er voor gekozen dit niet te gebruiken omdat het EOL lijkt te zijn. De laatste minor versie is al van heel lang geleden, en er zijn al 6+ maanden geen nieuwe releases meer geweest. Ook is het relatief resource heavy, en support het alleen Ruby 1.8 (op 1.9 krijg je de meest waanzinnige stacktraces). Ook kan Puppet Dashboard niet provisionen/preseeden/configureren, terwijl The Foreman dat wel kan (gebruiken we - in ieder geval voorlopig - nog niet though).

[BarthezZ]

Na alle stilte toch maar weer even een update mijnerzijds...

Inmiddels kan ik mijzelf wel een RPM-build master noemen Dmv. Koji (mock backend voor de chroot's) mash, en op termijn Sigul voor het automatisch signen, kan ik eigenlijk van al onze software prima een package bouwen.

Wel ben ik bij het distribueren in puppet één utidaging gevonden. Ik gebruik yum-plugin-versionlock om te zorggen dat mijn via puppet gemanagde packages (die gedwongen worden op een versie) niet perongeluk ge yum-upgrade kunnen worden. Nu heb ik naar stdlib/file_line gekeken om dit in versionlock.list te zetten (een package-versie regel per pakket). Maaar, dat voegt nieuwe regels toe en laat de oude gewoon staan, waarop versionlock weer op zijn muil gaat omdat het nog de oude pakt...

Ik zat te denken over iets pushen met alles naar een array pushen en dat in de file zetten... AAlleen lukt dat natuurlijk niet

Iemand een tof idee? Elke host krijgt vaak een unieke combinatie, dus externals worden lastig denk ik

[Freeaqingme]

Jij wilt delen van regels updaten? In dat geval moet je naar Augeas kijken. Als dat te veel moeite is kan je natuurlijk ook een exec resource declareren waarin je een sed commando uitvoert. Beetje lelijk wel, en je host moet wel perl draaien (doet freebsd/solaris niet standaard denk ik).

[BarthezZ]

Ja in feite wel; Resource package-versieX.Y.Z mag er maar één keer instaan, ook al pas ik dus de resource aan naar package-versieA.B.C... Augeas had ik nog niet aan gedacht hiervoor, ondanks dat ik het op andere machines wel gebruik...

[BarthezZ]

Oh en natuurlijk voor de liefhebbers

offtopic:
en een onsubtiel kickje

http://www.eventbrite.com...terdam-tickets-9344063345

Puppet Camp Amsterdam
Puppet Labs
Tuesday, January 28, 2014 from 9:00 AM to 5:00 PM (CET)
Amsterdam, Netherlands


Agenda:
09:00 - 09:30: Check in / Registration
09:30 - 10:30: Puppet Keynote - Eric Sorenson, Puppet Labs
10:30 - 11:15: Manageable Puppet infrastructure - Ger Apeldoorn,Puppet Specialist
11:15 - 12:00: Puppet Patterns from the Enterprise Battlefield - Tomasz Dziedzic, Linux Polska
12:00 - 13:00: Lunch
13:00 - 13:45: Continuous Delivery of Puppet Manifests, Lessons Learned - Kris Buytaert, Inuits
13:45 - 14:30: Writing better Puppet code with Gerrit and Jenkins - Maxim Burgerhout, Inter Access
14:30 - 14:45: Break
14:45 - 15:15: Puppetboard - Daniele Sluijters, Nedap
15:15 - 16:00: Scaling Puppet workflows at Spotify - Erik Dalen, Spotify
16:00 - 17:00: Puppet Demo - Steven Thwaites, Puppet Labs
17:00 - 18:30: Reception

Ben vorige keer ook geweest in Amsterdam; en ondanks dat het "zitten en luisteren" gehalte vrij hoog is, heeft het mij wel geholpen bij wat extra perspectief voordat ik met Puppet begon en daarmee denk ik de leercurve wel omlaag heeft gehaald. Daarmee moet je het niet aangrijpen als beginners-event trouwens, sommige onderwerpen zijn vrij heftig. Lunch was ook heel prima trouwens

[dj-wasabi]

Iemand nog geweest eind Januari? Nog wat geleerd?

Ikzelf vond deze 2 het interessants:
13:00 - 13:45: Continuous Delivery of Puppet Manifests, Lessons Learned - Kris Buytaert, Inuits
13:45 - 14:30: Writing better Puppet code with Gerrit and Jenkins - Maxim Burgerhout, Inter Access

Alleen nog geen tijd gehad om hier op het werk wat mee te doen (Teveel wensen met te weinig mensen.)

[Room42]

Ja ik was er bij! Ik ben zelf nog maar beginner met Puppet maar ik vond het erg interessant. Wij hebben grootse plannen met Puppet en Foreman en what not. Erg mooi! Ik verbaas me er dan ook over hoe rustig deze thread is.

[CAPSLOCK2000]

Dat verbaasd mij ook een beetje. Puppet is enorm krachtig maar de leercurve is ook wel fors. Als je het kunstje eenmaal door hebt dan kun je ontzettend veel gedaan krijgen maar eerst moet je een paar keer flink op je bek gaan.

[Room42]

Ja, ik zit nog even flink in de curve. Ik ben misschien een iets te steile route aan het volgen. Ik probeer het nu direct allemaal met Foreman te managen, en het provisionen lukt al wel (incl. MS AD DHCP-integratie), maar de basis en best-practice om bijvoorbeeld een lamp-server op te zetten trek ik nog niet helemaal. Vooral de parameters en hoe je dat beheersbaar flexibel organiseert is mij nog niet helemaal duidelijk.

Misschien maar even een stapje terug doen

Is de kennis die je met Foreman opdoet voldoende basis voor Puppet, of kun je beter eerst Puppet masteren?

[Freeaqingme]

Room42 schreef op vrijdag 14 maart 2014 @ 13:38:
Vooral de parameters en hoe je dat beheersbaar flexibel organiseert is mij nog niet helemaal duidelijk.

Na de nodige setups gedaan te hebben ben ik vooralsnog hier op uitgekomen: http://www.craigdunn.org/category/linux/howtos/

Wie weet dat dat wat houvast biedt.

[CyBeR]

CAPSLOCK2000 schreef op vrijdag 14 maart 2014 @ 13:27:
Dat verbaasd mij ook een beetje. Puppet is enorm krachtig maar de leercurve is ook wel fors. Als je het kunstje eenmaal door hebt dan kun je ontzettend veel gedaan krijgen maar eerst moet je een paar keer flink op je bek gaan.

Ik denk dat er nog vrij weinig mensen hier zijn die 't gebruiken. Het is ook best lastig om een bestaande omgeving te puppetizen. Daar heb ik me ook niet echt aan gewaagd.

[Room42]

Freeaqingme schreef op vrijdag 14 maart 2014 @ 16:28:
[...]


Na de nodige setups gedaan te hebben ben ik vooralsnog hier op uitgekomen: http://www.craigdunn.org/category/linux/howtos/

Wie weet dat dat wat houvast biedt.

Ziet er op het eerste gezicht goed uit. Dank je! Ik ben zelf erg practisch ingesteld, ik begrijp vooral door te doen. Dus dit soort tutorials helpen enorm. Ik lurk ook Youtube helemaal leeg

[ Voor 17% gewijzigd door Room42 op 14-03-2014 22:49 ]

[dj-wasabi]

Ik heb bestaande omgevingen ook nooit gepuppetized, alleen maar vanaf begin op opgebouwd met puppet. Ik zie toch redelijk vaak vacatures voorbij komen waarbij puppet minstens een pre is, dus daarom ook best gek dat het soms even kan duren voordat er iets geplaatst word in dit topic (Ja, ik ben ook schuldig, ik kijk ook niet elke dag ;-))

@Evanescent
En gebruik je al "The Foreman" ?
IK gebruik het zelf bij mijn huidige werkgever wel. Het is best handig, grafisch interface om puppet modules aan host(groepen) te plaatsen. Is ook wat makkelijker te doen dan bijv. gebruik van Hiera.

[3dmaster]

Ik ben bezig met het maken van een puppetscript die automatisch een lamp stack deployed op een ubuntu machine. Nu loop ik tegen het probleem aan dat ik het niet voor elkaar krijg om ITK te depoyen.
Ik gebruik de apache module van puppet zelf en heb nu dit in de config staat:

code:

class { 'apache':
        default_mods => false,         # don't load default mods
}
include apache::mod::itk
include apache::mod::php

Als ik het wil uitvoeren krijg ik de volgende melding:
May not include both apache::mod::itk and apache::mod::worker on the same node.

Weet iemand hoe ik wel ITK kan deployen? ( ik kan ook gewoon itk via package installeren maar dan moet ik ook met de hand weer apache modules uitzetten ivm incompatibilateit met andere mods).

Edit:

code:

class { 'apache':
        default_mods => false,         # don't load default mods
        mpm_module => false,
}
include apache::mod::itk
include apache::mod::php

werkt ook niet, nu krijg ik de melding apache::mod::php requires apache::mod::prefork
En als ik prefork aan zet krijg ik weer de melding dat prefork en itk niet in op één node mogen. Zucht.

[ Voor 20% gewijzigd door 3dmaster op 09-10-2014 11:18 ]

[Kees]

3dmaster schreef op donderdag 09 oktober 2014 @ 11:03:

werkt ook niet, nu krijg ik de melding apache::mod::php requires apache::mod::prefork
En als ik prefork aan zet krijg ik weer de melding dat prefork en itk niet in op één node mogen. Zucht.

Klopt, mod-php heeft prefork nodig. Als jij php wil icm met itk zul je voor php-cgi moeten gaan.