Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Datumbereik

Onderwerpen

AND

Subforum

Topicstarter

Topicstatus

2 topics - Pagina 1 van 1

Het puppet topic, tips en trucs

11-10-2014 discussie 101
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?LinuxUnicesWindows 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:packagesusersservicesfilesmountsEen 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 draaienEr 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:
1 2 3 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:
1 2 3 4 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:
1 2 3 4 5 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:
1 define simple-vhost ( $admin = "beheer@foor.bar", $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 (beheer@foo.bar) gebruikt. De documentroot wordt anders op "" (een lege string) gezet, dit komt later nog aan bod.
code:
1 2 3 4 5 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:
1 2 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:
1 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:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 # # 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 beheer@foo.bar 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:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 <VirtualHost *:80> ServerName www.foo.bar ServerAdmin beheer@foo.bar 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:
1 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:
1 2 3 4 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:
1 2 3 4 5 6 7 8 9 10 11 12 13 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:
1 2 3 4 5 6 7 8 9 # 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, groepenNTPXenServer guest OS toolsAPT configuratieresolv.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/motdHandige pakketjes die ik op elke machine geinstalleerd wil hebben (iptraf, screen, vim, sudo)denyhostsEn 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 vandaanHeb je zelf een leuke link? DM me en hij komt in de lijst.

[backtrack] automated installatie via pxe

25-06-2012 discussie 11
Hoihoi


Ik ben atm voor een projectje bezig waar ik snel wat USB-disk met daarop backtrack wil kunnen vervaardigen.
Omdat eea dynamisch gerelged moet worden is clonezilla niet heel handig, en zat ik te denken aan:

- PXEboot
- backtrack
- automated install met alleen puppet erin geslipstreamed
- na reboot in OS gaat puppet even updaten , en klaar...


De reden waarom ik backtrack wil is dat hier standaard al heel veel tooltjes in zitten die voor mijn werkterrein handig zijn . Als alternatief is een debian automated install mogelijk, waarna puppet er een berg tools op knalt.
Debian kan iig automated installs doen via PXE, en dat is echt fijn.


Nu heb ik al bij baktrack gekeken maar vind ik nergens iets terug over automated installs. Heeft iemand hier ervaring mee?
Resultaten per pagina: 25 | 50 | 100


Samsung Galaxy S7 edge Athom Homey Xcom 2 Samsung Galaxy S7 Fallout 4 Apple iPhone 6C Hitman (2016) LG G5

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True