Puppet Labs

Sono riuscito finalmente a trovare del tempo per spippolare con Puppet, un software per la configurazione centralizzata dei server. Come dice qualcuno: il miglior modo per distribuire un errore su più server con un solo clic :)

Ho intenzione quindi di scrivere una serie di articoli sulla sua installazione, configurazione ed uso. Iniziamo da qui.

In questo articolo illustro come installare Puppet (master e un primo nodo) sulla neonata Ubuntu server 12.04 LTS.

Prepariamo l'ambiente

La configurazione che ho usato è formata da un server master e uno slave, entrambi 12.04.

Su 12.04 i pacchetti sono sul repository ufficiale, in alternativa Puppet Labs fornisce un repository che può essere aggiunto alle proprie sorgenti con:

~$ wget http://apt.puppetlabs.com/puppetlabs-release_1.0-2_all.deb
~$ sudo dpkg -i puppetlabs-release_1.0-2_all.deb

Per delle più complete istruzioni di installazione vi rimando alla documentazione ufficiale.

I client si connettono al master sulla porta 8140 quindi si faccia attenzione ai firewall.

I server devono avere hostname con risoluzioni DNS valide (anche reverse). Se nella rete non c'è un server DNS si può usare il file /etc/hosts sui vari nodi.

Master

Come di consueto si inizia installando il necessario:

~$ sudo apt-get install puppetmaster

Il pacchetto crea la cartella /etc/puppet con delle configurazioni di base.
Si dia un'occhiata anche alla cartella /usr/share/doc/puppet-common/examples dove ci sono molti file interessanti.

La comunicazione tra i nodi avviene utilizzando SSL e i certificati garantiscono l'autenticità del master. Pertanto una volta installato il master vanno rigenerati i certificati usando l'hostname del server.

Si aggiunge al file /etc/puppet/puppet.conf, nella sezione [master], la riga:

dns_alt_names = puppet, puppet.mydomain

ovviamente rispettando il proprio hostname. Se serve si può ottenere col comando:

~$ hostname -f

Vanno inoltre eliminati i certificati esistenti, personalmente consiglio di rinominare la cartella (giusto per essere sicuri..):

~$ sudo mv /var/lib/puppet/ssl/ /var/lib/puppet/ssl-orig

Al riavvio del servizio (sudo service puppetmaster restart), puppet si accorgerà del maltolto e rigenererà i certificati. Per verificare la correttezza del DNS:

~$ sudo openssl x509 -in /var/lib/puppet/ssl/certs/puppet.mydomain.pem -text | grep -i dns

Nodo di prova

Passando al nodo slave da usare per le prove, anche in questo caso l'hostname deve essere risolto dal DNS e deve poter risolvere l'hostname del master. Fatto questo si può installare il necessario:

~$ sudo apt-get install puppet

Va editato il file /etc/puppet/puppet.conf aggiungendo:

[agent]
server = puppet.mydomain

Si modifica anche /etc/default/puppet impostando l'avvio al boot:

START=yes

Si può adesso riavviare l'agent:

~$ sudo service puppet restart

Può essere utile non utilizzare il demone ma far girare puppet con cron (ad esempio sembra che a volte il demone rimanga inchiodato al 100% della CPU). Per creare il job basta lanciare:

~$ sudo puppet resource cron puppet-agent ensure=present user=root minute=30 command='/usr/bin/puppet agent --onetime --no-daemonize --splay'

Per verificare la regola bisogna guardare il cron di root:

~$ sudo crontab -l
# HEADER: This file was autogenerated at Wed May 09 17:15:29 +0200 2012 by puppet.
# HEADER: While it can still be managed manually, it is definitely not recommended.
# HEADER: Note particularly that the comments starting with 'Puppet Name' should
# HEADER: not be deleted, as doing so could cause duplicate cron jobs.
# Puppet Name: puppet-agent
30 * * * * /usr/bin/puppet agent --onetime --no-daemonize --splay

Ovviamente bisogna stoppare puppet e settare in /etc/default/puppet:

START=no

Autenticare il nodo

Se tutto è andato bene il master dovrebbe aver rilevato lo slave, si può verificare lanciando sul master:

~$ sudo puppet cert --list
slave.mydomain (12:A1:08:DD:A4:40:16:A4:DC:C8:46:37:4C:46:93:E3)

Bingo! Firmiamo la chiave dello slave usando il master:

~$ sudo puppet cert --sign slave.mydomain
notice: Signed certificate request for slave.mydomain
notice: Removing file Puppet::SSL::CertificateRequest slave.mydomain at '/var/lib/puppet/ssl/ca/requests/slave.mydomain.pem'

Test

Proviamo a vedere se il tutto funziona creando un modulo "HelloWorld". Si crea il file necessario:

~$ sudo mkdir -p /etc/puppet/modules/helloworld/manifests/
~$ sudo vi /etc/puppet/modules/helloworld/manifests/init.pp

Il contenuto del file init.pp è:

class helloworld {
    file { '/tmp/helloFromMaster':
        content => "Hello, World!\n"
    }
}

Si edita il manifesto generale /etc/puppet/manifests/site.pp aggiungendo:

node slave.mydomain { include helloworld }

e infine:

~$ sudo service puppetmaster restart

Dopo qualche tempo lo slave si accorgerà del cambiamento creando il file /tmp/helloFromMaster. Per accelerare la cosa basta riavviare il servizio sullo slave (o aspettare il cron).

Server di produzione

Di base il pacchetto puppetmaster utilizza Webrick, molto comodo ma anche molto lento. In un ambiente di produzione è utile installare il pacchetto puppetmaster-passenger che utilizza, appunto, Passenger.
Prima di farlo bisogna ricordarsi di fermare il servizio puppetmaster e modificare /etc/default/puppetmaster impostando:

SERVERTYPE=passenger

A questo punto si può installare puppetmaster-passenger e riavviare il servizio puppetmaster. Troverete in /etc/apache2/sites-enabled/puppetmaster la configurazione di passenger.

blog comments powered by Disqus