Continuiamo la configurazione di un PuppetMaster per la gestione di datacenter complessi.
Nel precedente blog abbiamo visto come sia possibile definire, all’interno del file site.pp, una configurazione distinta per ogni server. L’inconveniente di questo approccio lo vediamo quando siamo in un contesto con diverse centinaia di server da configurare in modo eterogeneo: pochi server con esattamente la stessa configurazione. In questo caso, il file di specifica dei server diventa velocemente troppo grosso e ingestibile, con un reale rischio di errore e “rottura” della configurazione globale. Un errore in un puppet che configura 600 e più server, può costare caro!!
Per questo motivo PuppetLabs fornisce da diverso tempo la possibilità di configurare i server “esternamente” (rispetto al file site.pp) attraverso Hiera: un database gerarchico che possiamo usare con file di testo (yaml, json, …) o con un database chiave-valore (i.e. redis) come backend.
Il risultato é, che invece di avere un singolo file di migliaia di righe, avremo 1 database che contiene tutto o un file di testo per ogni singolo server.
Installazione del pacchetto Hiera
yum -y install hiera hiera-puppet
I due pacchetti in questione li troviamo nei repository ufficiali puppetlabs, che dovremmo aver già configurato ed importato per l’installazione di puppet.
Se non dovesse esserci un pacchetto nativo per il vostro sistema, é possibile installare hiera direttamente attraverso rubygem:
sudo gem install hiera sudo gem install hiera-puppet
Configurazione di Hiera
Dobbiamo poi configurare il prodotto per specificare il modo in cui vogliamo usarlo. Puppet e la CLI di hiera si aspettano un file di configurazione in /etc/hiera.yaml (o /etc/puppet/hiera.yaml nelle version 2.x di puppet) configurato, per esempio, come il seguente:
:backends:
- yaml
:logger: console
:hierarchy:
- common
:yaml:
:datadir: '/etc/puppet/hieradata'
Che indica il tipo di backend da usare (file di testo yaml in questo esempio), la directory dove i file data per i server sono salvati e la gerarchia di configurazione.
In questo caso la gerarchia contiene solo “common”, che vuol dire che per ogni server, hiera andrà a leggere la configurazione definita in un file common.yaml e successivamente la configurazione specifica per il server (un file il cui nome corrisponde al FQDN del server).
In ambienti più complessi potremmo essere portati a configurare più livelli gerarchici dipendenti dalla tipologia o ambiente del server, per esempio:
:hierarchy:
- common # all nodes
- %{operatingsystem} # subset
- %{hostname} # single node
In questo caso, la configurazione di ogni server andrà a cercare i file:
- common.yaml
- RedHat.yaml (Debian.yaml, …): dipendente cioè dal nome della distribuzione del server configurato
- web01.yaml
Configurazione dei server
A questo punto non ci resta che configurare i server e, dove necessario, i file specificati nella “gerarchia”.
Quindi andremo per esempio a creare un file /etc/puppet/hieradata/common.yaml, all’interno del quale potremo specificare le classi/moduli da installare su ogni server personalizzati se necessario con delle variabili:
--- classes: ['core', 'mcollective', 'ntp', 'profile', 'ssh', 'vim']
Seguito, ove necessario, da un file specifico per il server, per esempio /etc/puppet/hieradata/web01.yaml
--- classes: ['jboss'] jbossver: 6.1.0.Final jboss::up: true
In questo esempio stiamo definendo una classe da installare (jboss) e valorizzando alcune variabili (usate nella classe specifica o in altre classi installate sul server).
Nel codice del modulo andremo solo a cambiare il modo in cui le variabili vengono lette:
1 2 3 4 5 6 7 8 9 10 11 12 13 | class jboss( $up = hiera('jboss::up', true) ) { $jbossver = hiera("jbossver") # (...) service{ 'jboss': require => [ File['jboss_service'], Package['jbossas'], ], ensure => $up? { true => running, 'true' => running, default => stopped }, enable => $up? { true => true, 'true' => true, default => false }, } } |
Quindi lettura del valore jboss::up, valorizzato a “true” dove non impostato.
Vorrà quindi dire, continuando a seguire il nostro esempio, che sul server web.example.com verrà installato JBoss in version 6.1 e il servizio verrà attivato automaticamente sul server (service jboss start e chkconfig jboss on).
Terminata la configurazione dei vostri file potrete verificarne la correttezza attraverso la CLI di hiera, per esempio il comando seguente dovrà mostrarvi il contenuto della variabile jbossver:
hiera -c /etc/puppet/hiera.yaml jbossver
Se preferite non usare dei file di testo per la configurazione, come detto all’inizio dell’articolo avete la possibilità di usare un database chiave-valore come backend.
Vediamo per esempio come configurare hiera per usare redis in backend.
Nel file /etc/hiera.yaml:
:backends:
- redis
:redis:
:username: nil
:password: nil
Aggiungiamo i nostri dati a redis:
redis-cli<<'EOF' set common:jbossver 6.1.0.Final set common:testmsg "Test Message" set common:jboss::up true keys * EOF
E il gioco é fatto.
Ref: kermit.fr
