Nel panorama informatico moderno non si può più prescindere da sistemi di gestione centralizzata delle configurazioni. Troppo il numero di macchine da gestire, troppa la facilità con cui tali macchine una volta rese operative sfuggono al controllo, troppi i rischi di creare disallineamenti tra macchine le cui configurazioni devono essere identiche.
Da qui l’avvento dei sistemi di controllo centralizzato. Uno su tutti, Puppet. All’interno di Puppet è possibile definire modalità operative e configurazioni specifiche per il proprio parco macchine.
Ma cosa succede quando ad operare sulle configurazioni in questione non è una persona, ma un team di operatori che potenzialmente agiscono sugli stessi file? Il rischio di confusione è altissimo.
Proprio per questo torna utile affiancare a Puppet un sistema di versionamento che consenta di tenere traccia di tutte le modifiche fatte, effettuare l’eventuale rollback e di fatto creare delle release relative alla configurazione.
Questo articolo spiega come sia possibile configurare Puppet in modo che la configurazione comune possa essere modificata da più utenti, ciascuno proprietario di un branch specifico, mediante Git.

Installazione di Puppet

Ai fini del progetto la configurazione Puppet che verrà implementata sarà minima. Il sistema operativo su cui l’articolo è sviluppato è Ubuntu, con l’aggiunta dei repository puppetlabs, ma installazioni a parte, si applica a qualsiasi distribuzione.
Di fatto l’architettura comprenderà una macchina server (ubuntu-vm1.rascanet.local), su cui verrà installato il software puppetmaster:

root@ubuntu-vm1:~# apt-get install puppetmaster

ed una macchina client (ubuntu-vm2.rascanet.local) che farà riferimento alla macchina server per scaricarne le configurazioni:

root@ubuntu-vm2:~# apt-get install puppet

La prima esecuzione di Puppet da parte del client è già avviabile:

root@ubuntu-vm2:~# puppet agent --test --server=ubuntu-vm1.rascanet.local
Info: Creating a new SSL key for ubuntu-vm2.rascanet.local
Info: Caching certificate for ca
Info: Creating a new SSL certificate request for ubuntu-vm2.rascanet.local
Info: Certificate Request fingerprint (SHA256): EE:1C:4C:6F:9B:52:EE:21:D9:EC:95:98:B6:EB:98:A4:36:BC:A0:9B:06:A7:32:91:C8:D9:49:A5:29:BC:EC:68
Exiting; no certificate found and waitforcert is disabled

E’ stata creata una richiesta di abilitazione da parte del client sul server, il completamento di tale operazione andrà quindi eseguito sul puppetmaster, ubuntu-vm1:

root@ubuntu-vm1:~# puppet cert list
  "ubuntu-vm2.rascanet.local" (SHA256) EE:1C:4C:6F:9B:52:EE:21:D9:EC:95:98:B6:EB:98:A4:36:BC:A0:9B:06:A7:32:91:C8:D9:49:A5:29:BC:EC:68
root@ubuntu-vm1:~# puppet cert sign ubuntu-vm2.rascanet.local
Notice: Signed certificate request for ubuntu-vm2.rascanet.local
Notice: Removing file Puppet::SSL::CertificateRequest ubuntu-vm2.rascanet.local at '/var/lib/puppet/ssl/ca/requests/ubuntu-vm2.rascanet.local.pem'

Il client è stato identificato e da questo momento in poi sarà possibile appunto far gestire la macchina dal puppetmaster.

Configurazione di Puppet

La configurazione di Puppet implementata in questo articolo è molto semplice. Verrà impostata una password identica per l’utente root su tutte le macchine ed infine verrà implementata la modifica al file di sistema /etc/motd in modo da modificare il messaggio del giorno presentato dopo ogni login.
Le configurazioni di Puppet partono dal file /etc/puppet/manifests/site.pp. E’ questo il primo file ad essere letto dal sistema di centralizzazione delle configurazioni.
Nell’esempio illustrato esso avrà il seguente contenuto:

node 'base' {
        user { "root":
                password => '$6$jqfr0dC4$qmtaVdbOVImeuXcpps6F.dg.2p4TeVFfIS/j.rtZ/35b17.1OlEzmfIGrXujCAYlUK30151zBrDgZ6/gC14I/.',
        }
}

# ubuntu-vm1
node 'ubuntu-vm1' inherits base {
        include rascanet::standard
}

# ubuntu-vm2
node 'ubuntu-vm2' inherits base {
        include rascanet::standard
}

Di fatto viene dichiarato un nodo “base” per cui viene impostato l’hash della password per l’utente root, in modo che questi corrisponda alla password dell’utente root sulla macchina ubuntu-vm1.rascanet.local, ricavato dal seguente comando:

root@ubuntu-vm1:~# cat /etc/shadow|grep root
root:$6$jqfr0dC4$qmtaVdbOVImeuXcpps6F.dg.2p4TeVFfIS/j.rtZ/35b17.1OlEzmfIGrXujCAYlUK30151zBrDgZ6/gC14I/.:15854:0:99999:7:::

E vengono dichiarati poi due nodi, ubuntu-vm1 ed ubuntu-vm2 che ereditano le caratteristiche della classe base (quindi la password di root) e le estendono includendo un’ulteriore classe ricavata dal modulo rascanet e denominata standard.
Quando si parla di modulo ci si riferisce alla componente che fornisce le informazioni per la configurazione a Puppet. Nel caso presentato nell’articolo il modulo viene denominato rascanet, dal dominio della rete in cui si sta operando. La scelta dei nomi è indifferente ed arbitraria, così come (e lo si vedrà in seguito) i path stessi relativi ai vari moduli potranno essere scelti arbitrariamente. La scelta effettuata per l’articolo fa riferimento alla configurazione standard di Puppet, presente nel file /etc/puppet/puppet.conf.
Nella pratica questo si traduce nella creazione della cartella /etc/puppet/modules/rascanet al cui interno dovranno essere create le sottocartelle manifests (che conterrà le definizioni per questo modulo), files (che conterrà i file statici utilizzati per questo modulo) e templates (che conterrà i file dinamici, ossia che verranno elaborati prima del loro caricamento, utilizzati da questo modulo).

root@ubuntu-vm1:~# mkdir -p /etc/puppet/modules/rascanet/{manifests,files,templates}

Una volta creato il path sarà quindi necessario dichiarare quella che sarà la classe standard menzionata poc’anzi. Il file che andrà creato sarà quindi /etc/puppet/modules/rascanet/manifests/standard.pp ed avrà il seguente contenuto:

class rascanet::standard {
        $role = "standard"

        # Semplice file
        file { '/etc/motd':
                ensure => present,
                owner  => 'root',
                group  => 'root',
                mode   => 644,
                source => "puppet:///modules/rascanet/$role/motd",
        }
}

Come anticipato la classe in questione altro non farà che impostare la variabile role per la classe (il cui valore sarà “standard”) ed includere il file /etc/motd il cui sorgente sarà preso nel path puppet:///modules/rascanet/$role/motd. Tale path corrisponderà, secondo gli standard di Puppet, al path reale /etc/puppet/modules/rascanet/files/standard/motd.
Pertanto andrà creata la cartella:

root@ubuntu-vm1:~# mkdir /etc/puppet/modules/rascanet/files/standard

E generato al suo interno il file “motd”, il cui contenuto potrà essere banalmente:

MOTD changed by Puppet!

A questo punto, per verificare l’esattezza di quanto creato, si andrà a verificare sulla macchina client il contenuto del file:

root@ubuntu-vm2:~# cat /etc/motd 
Linux ubuntu-vm2 3.2.0-35-generic #55-Ubuntu SMP Wed Dec 5 17:42:16 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
Ubuntu 12.04.1 LTS

Welcome to Ubuntu!
 * Documentation:  https://help.ubuntu.com/

  System information as of Thu May 16 11:35:51 CEST 2013

  System load:  0.21              Processes:             85
  Usage of /:   79.7% of 2.18GB   Users logged in:       0
  Memory usage: 24%               IP address for eth0:   192.168.122.12
  Swap usage:   0%                IP address for eth0:0: 10.0.0.1

  Graph this data and manage this system at https://landscape.canonical.com/

E si lancerà il comando puppet agent in modo da effettuare le modifiche:

root@ubuntu-vm2:~# puppet agent --test --server=ubuntu-vm1.rascanet.local
Info: Retrieving plugin
Info: Caching catalog for ubuntu-vm2.rascanet.local
Info: Applying configuration version '1368704116'
Notice: /Stage[main]//Node[base]/User[root]/password: changed password
Info: FileBucket adding {md5}20a22b90e6966a19ce338fb62c013250
Info: /Stage[main]/Rascanet::Standard/File[/etc/motd]: Filebucketed /etc/motd to puppet with sum 20a22b90e6966a19ce338fb62c013250
Notice: /Stage[main]/Rascanet::Standard/File[/etc/motd]/ensure: defined content as '{md5}489ada2679d72053a5a8147741da43db'
Notice: Finished catalog run in 0.56 seconds

L’output dovrà essere qualcosa di simile a quanto mostrato, e la verifica finale verrà dall’analisi del nuovo contenuto del file:

root@ubuntu-vm2:~# cat /etc/motd 
MOTD changed by Puppet!

Le modifiche sono quindi state applicate con successo.

Configurazione del repository GIT

Conclusa la configurazione di Puppet è quindi il momento di creare la struttura che consentirà di gestire le sue diverse configurazioni, differenziandole per utente.
Per realizzare quanto descritto sarà necessario creare sulla macchina server l’utente git a cui verranno assegnati il repository base e tutti le varianti (branch) associate ai vari utenti:

root@ubuntu-vm1:~# useradd -m -d /git -s /bin/bash git
root@ubuntu-vm1:~# passwd git
Inserire nuova password UNIX: 
Reinserire la nuova password UNIX: 
passwd: password updated successfully

All’interno della home directory dell’utente git verrà creata la sotto cartella puppet che conterrà i repository del progetto:

root@ubuntu-vm1:~# su - git
git@ubuntu-vm1:~$ pwd
/git
git@ubuntu-vm1:~$ mkdir puppet
git@ubuntu-vm1:~$ cd puppet

Nella cartella del progetto Puppet verrà poi creato il repository denominato puppet.git, di tipo bare. Tale modalità di creazione è necessaria per consentire di avere un repository condiviso da più utenti e su cui più utenti potranno scrivere:

git@ubuntu-vm1:~/puppet$ git init --bare puppet.git
Initialized empty Git repository in /git/puppet/puppet.git/
git@ubuntu-vm1:~/puppet$ ls -la puppet.git/
totale 40
drwxrwxr-x 7 git git 4096 mag 24 12:50 .
drwxr-xr-x 5 git git 4096 mag 24 12:50 ..
drwxrwxr-x 2 git git 4096 mag 24 12:50 branches
-rw-rw-r-- 1 git git   66 mag 24 12:50 config
-rw-rw-r-- 1 git git   73 mag 24 12:50 description
-rw-rw-r-- 1 git git   23 mag 24 12:50 HEAD
drwxrwxr-x 2 git git 4096 mag 24 12:50 hooks
drwxrwxr-x 2 git git 4096 mag 24 12:50 info
drwxrwxr-x 4 git git 4096 mag 24 12:50 objects
drwxrwxr-x 4 git git 4096 mag 24 12:50 refs

Partendo quindi da questo repository è possibile effettuare un primo clone denominato “master” che rappresenterà il riferimento principale per il servizio puppet (si veda in seguito nel file di configurazione di puppet la sezione denominata production):

git@ubuntu-vm1:~/puppet$ git clone file:///git/puppet/puppet.git master
Cloning into 'master'...
warning: You appear to have cloned an empty repository.

Il popolamento di questo nuovo repository (al momento una semplice cartella vuota con una sotto cartella nascosta denominata .git) può avvenire partendo dalla configurazione di Puppet attualmente funzionante:

git@ubuntu-vm1:~$ cd /git/puppet/master/
git@ubuntu-vm1:~/master$ cp -r /etc/puppet/manifests /etc/puppet/modules .
git@ubuntu-vm1:~/master$ ls -la
totale 20
drwxrwxr-x 5 git git 4096 mag 16 15:47 .
drwxr-xr-x 3 git git 4096 mag 16 15:44 ..
drwxrwxr-x 7 git git 4096 mag 16 15:44 .git
drwxr-xr-x 2 git git 4096 mag 16 13:34 manifests
drwxr-xr-x 3 git git 4096 mag 16 13:26 modules

Il primo popolamento del repository dovrà quindi passare dai seguenti comandi git, che aggiungeranno i file e mediante commit li includeranno nel sistema versionamento:

git@ubuntu-vm1:~/master$ git add .
git@ubuntu-vm1:~/master$ git status
# On branch master
#
# Initial commit
#
# Changes to be committed:
#   (use "git rm --cached ..." to unstage)
#
#	new file:   manifests/site.pp
#	new file:   modules/rascanet/files/standard/motd
#	new file:   modules/rascanet/manifests/standard.pp
#
git@ubuntu-vm1:~/puppet.git$ git commit -m "Primo popolamento repository"
[master (root-commit) 5574c5e] Primo popolamento repository
 3 files changed, 31 insertions(+)
 create mode 100644 manifests/site.pp
 create mode 100644 modules/rascanet/files/standard/motd
 create mode 100644 modules/rascanet/manifests/standard.pp

Pertanto il branch (un ramo del repository principale) master, è pronto ad essere caricato sul repository centralizzato:

git@ubuntu-vm1:~/puppet/master$ git branch
* master
git@ubuntu-vm1:~/puppet/master$  git remote
origin
git@ubuntu-vm1:~/puppet/master$ git push origin master
Counting objects: 11, done.
Compressing objects: 100% (5/5), done.
Writing objects: 100% (11/11), 950 bytes, done.
Total 11 (delta 0), reused 0 (delta 0)
Unpacking objects: 100% (11/11), done.
To file:///git/puppet/puppet.git
 * [new branch]      master -> master

Il comando chiave è git push origin master che regola in sostanza il primo caricamento del branch attuale (master) nel principale (origin). Da questo momento in avanti non sarà più necessario specificare parametri al comando git push poiché l’iniziale associazione verrà memorizzata.

Al momento quindi il sistema ha un repository Git principale (/git/puppet/puppet.git) ed un branch dello stesso denominato master (/git/puppet/master) a cui Puppet farà riferimento per la configurazione principale, non rimane altro da fare che configurare l’accesso ad un singolo utente.
Ad ogni utente corrisponderà un branch omonimo, per la creazione del quale saranno necessarie le seguenti fasi:

git@ubuntu-vm1:~/puppet/master$ cd /git/puppet/puppet.git
git@ubuntu-vm1:~/puppet/puppet.git$ git branch
* master
git@ubuntu-vm1:~/puppet/puppet.git$ git branch rasca
git@ubuntu-vm1:~/puppet/puppet.git$ git branch
* master
  rasca

E’ stato quindi creato il nuovo branch rasca nel repository principale, ma c’è un problema: Puppet non è in grado di accedere direttamente ai branch di git, quindi così come fatto per master sarà necessario creare una cartella reale a cui Puppet possa far riferimento.
La soluzione a questo problema è quindi quella di clonare il branch in una directory effettiva, con il seguente comando:

git@ubuntu-vm1:~/puppet$ cd /git/puppet
git@ubuntu-vm1:~/puppet$ git clone -b rasca file:///git/puppet/puppet.git rasca
Cloning into 'rasca'...
remote: Counting objects: 11, done.
remote: Compressing objects: 100% (5/5), done.
Receiving objects: 100% (11/11), 949 bytes, done.
remote: Total 11 (delta 0), reused 0 (delta 0)

Da notare l’opzione -b che permette di creare il clone partendo dal branch dichiarato (in questo caso “rasca”).
Sono state create quindi due cartelle, al momento contenenti gli stessi identici file (la configurazione originale di Puppet):

1. /git/puppet/master/ : che conterrà l’ambiente Puppet principale;
2. /git/puppet/rasca/ : che conterrà l’ambiente dell’utente rasca;

Puppet potra quindi essere configurato per gestire questi nuovi ambienti, modificando /etc/puppet/puppet.conf (come utente root):

[production]
#modulepath = /etc/puppet/modules
#manifest = /etc/puppet/manifests/site.pp
modulepath = /git/puppet/master/modules
manifest = /git/puppet/master/manifests/site.pp

[rasca]
modulepath = /git/puppet/rasca/modules
manifest = /git/puppet/rasca/manifests/site.pp

Applicando le modifiche con un reload del servizio:

root@ubuntu-vm1:~# /etc/init.d/puppetmaster reload

Per verificare infine il corretto funzionamento del sistema sarà possibile, sulla macchina client, lanciare il seguente comando:

root@ubuntu-vm2:~# puppet agent --test --server=ubuntu-vm1.rascanet.local --environment=rasca
Info: Retrieving plugin
Info: Caching catalog for ubuntu-vm2.rascanet.local
Info: Applying configuration version '1369393193'
Notice: Finished catalog run in 0.17 seconds

L’agente Puppet ha riconosciuto l’ambiente rasca e non ha applicato alcuna modifica, così come ci si aspettava.

Apportare modifiche al repository GIT

Come è però possibile fare in modo che le modifiche al branch rasca vengano importate direttamente all’interno della cartella clonata /git/puppet/rasca per cui è stato configurato un ambiente Puppet apposito? La soluzione di questo problema è quella di configurare un automatismo che consenta sulla base dei caricamenti (push) effettuati nel branch di scaricare le modifiche (pull) nella relativa cartella clonata.
Git mette a disposizione di ciascun repository degli hook, ossia script che vengono eseguiti in virtù di specifiche operazioni. Nel caso che si sta trattando, l’hook sarà “post-receive”, e verrà eseguito quindi a seguito di un “push” all’interno di uno specifico branch.

Il file da creare sarà quindi /git/puppet/puppet.git/hooks/post-receive:

#!/bin/bash
read oldrev newrev refname
BRANCH=${refname#refs/heads/}
if [ -d /git/puppet/$BRANCH ]
 then
  cd /git/puppet/$BRANCH
  GIT_DIR=/git/puppet/$BRANCH/.git git pull
  if [ $? -eq 0 ]
   then
    echo "Updated branch '$BRANCH'" >> /tmp/git.log
   else
    echo "Error during branch '$BRANCH' updating." >> /tmp/git.log
  fi
fi

Questo semplice script esegue un comando chiave, ossia:

GIT_DIR=/git/puppet/$BRANCH/.git git pull

che sostanzialmente caricherà tutte le modifiche applicate al repository ed ai suoi branch all’interno della cartella relativa all’environment.

Essenziale è che il file sia eseguibile:

git@ubuntu-vm1:~/puppet$ chmod +x /git/puppet/puppet.git/hooks/post-receive

A questo punto lato server il lavoro è completo. E’ stato creato un repository, due cartelle associate ai suoi branch (attualmente master e rasca) e gli hook per aggiornarne il contenuto, mancano i test funzionali di gestione di tali repository.

Preparazione di un repository locale

L’utente che voglia effettuare modifiche al repository in questione dovrà creare un repository locale, partendo dal repository base presente sul server:

rasca@anomalia [~]> git clone ssh://git@ubuntu-vm1/git/puppet/puppet.git puppet
Cloning into 'puppet'...
git@ubuntu-vm1's password: 
remote: Counting objects: 11, done.
remote: Compressing objects: 100% (5/5), done.
remote: Total 11 (delta 0), reused 0 (delta 0)
Receiving objects: 100% (11/11), done.
rasca@anomalia [~]> cd puppet/
rasca@anomalia [~/puppet]> ls -la
totale 20
drwxr-xr-x 5 rasca rasca 4096 mag 16 15:55 .
drwxr-xr-x 5 rasca rasca 4096 mag 16 15:55 ..
drwxr-xr-x 8 rasca rasca 4096 mag 16 15:55 .git
drwxr-xr-x 2 rasca rasca 4096 mag 16 15:55 manifests
drwxr-xr-x 3 rasca rasca 4096 mag 16 15:55 modules

La copia clonata sul disco riflette esattamente quanto al momento presente sul server.
Per operare sul branch interessato, ossia rasca, si potrà eseguire il seguente comando:

rasca@anomalia [~/puppet]> git checkout rasca
Branch rasca set up to track remote branch rasca from origin.
Switched to a new branch 'rasca'

Test funzionali

Nel test qui presentato si modificherà il file “motd” configurato in precedenza, variandone il contenuto, effettuando il commit all’interno del repository locale e caricando le modifiche sul server remoto, mediante push:

rasca@anomalia [~/puppet]> vi modules/rascanet/files/standard/motd 
rasca@anomalia [~/puppet]> git commit -a -m "Modifica di motd da parte di RaSca"
[rasca 5fae565] Modifica di motd da parte di RaSca
 1 file changed, 1 insertion(+), 1 deletion(-)
rasca@anomalia [~/puppet.git]> git push
git@ubuntu-vm1's password: 
Counting objects: 13, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (3/3), done.
Writing objects: 100% (7/7), 527 bytes, done.
Total 7 (delta 0), reused 0 (delta 0)
remote: From file:///git/puppet/puppet
remote:    ae80980..26bc481  rasca      -> origin/rasca
remote: Updating ae80980..26bc481
remote: Fast-forward
remote:  modules/rascanet/files/standard/motd |    2 +-
remote:  1 file changed, 1 insertion(+), 1 deletion(-)
To ssh://git@ubuntu-vm1/git/puppet/puppet.git
   ae80980..26bc481  rasca -> rasca

Se l’hook configurato in precedenza avrà funzionato a dovere, lato server sarà possibile vedere la modifica nel path relativo:

git@ubuntu-vm1:~/puppet$ cat rasca/modules/rascanet/files/standard/motd 
MOTD changed by Puppet by RaSca!

E lanciando dal client il comando puppet agent con il parametro environment le modifiche dovranno essere applicate:

root@ubuntu-vm2:~# puppet agent --test --server=ubuntu-vm1.rascanet.local --environment=rasca
Info: Retrieving plugin
Info: Caching catalog for ubuntu-vm2.rascanet.local
Info: Applying configuration version '1369391648'
Notice: /Stage[main]/Rascanet::Standard/File[/etc/motd]/content: 
--- /etc/motd	2013-05-16 13:35:17.009107640 +0200
+++ /tmp/puppet-file20130524-1947-9y1tpv-0	2013-05-24 12:34:08.891868278 +0200
@@ -1 +1 @@
-MOTD changed by Puppet!
+MOTD changed by Puppet by RaSca!

Info: FileBucket adding {md5}489ada2679d72053a5a8147741da43db
Info: /Stage[main]/Rascanet::Standard/File[/etc/motd]: Filebucketed /etc/motd to puppet with sum 489ada2679d72053a5a8147741da43db
Notice: /Stage[main]/Rascanet::Standard/File[/etc/motd]/content: content changed '{md5}489ada2679d72053a5a8147741da43db' to '{md5}9b49de19dc47e4fa52c8677726828997'
Notice: Finished catalog run in 0.66 seconds

L’output del comando mostra come le modifiche effettuate hanno avuto esito positivo.
Tipicamente in queste situazioni la persona che ha effettuato le modifiche farà tutte le verifiche del caso lato client, controllando che il proprio ambiente abbia prodotto gli esiti desiderati sulla macchina. Una volta reso certo questo passaggio sarà possibile applicare queste modifiche sul branch master, in modo che la configurazione principale di Puppet venga allineata con il branch rasca.
Per fare ciò si modificherà il branch mediante il comando git checkout:

rasca@anomalia [~/puppet]> git checkout master
Switched to branch 'master'

E si effettuerà un merge dei contenuti dal branch rasca, seguito da una push che carichi i dati sul branch master nel server remoto:

rasca@anomalia [~/puppet]> git merge rasca
Updating ae80980..26bc481
Fast-forward
 modules/rascanet/files/standard/motd |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
rasca@anomalia [~/puppet]> git push
git@ubuntu-vm1's password: 
Total 0 (delta 0), reused 0 (delta 0)
remote: From file:///git/puppet/puppet
remote:    ae80980..26bc481  master     -> origin/master
remote:  * [new branch]      rasca      -> origin/rasca
remote: Updating ae80980..26bc481
remote: Fast-forward
remote:  modules/rascanet/files/standard/motd |    2 +-
remote:  1 file changed, 1 insertion(+), 1 deletion(-)
To ssh://git@ubuntu-vm1/git/puppet/puppet.git
   ae80980..26bc481  master -> master

Anche in questo caso le verifiche di funzionamento dell’hook passano dal controllo del file lato server:

git@ubuntu-vm1:~/puppet$ cat /git/puppet/master/modules/rascanet/files/standard/motd 
MOTD changed by Puppet by RaSca!

E dal lancio dell’agente Puppet lato client:

root@ubuntu-vm2:~# puppet agent --test --server=ubuntu-vm1.rascanet.local
Info: Retrieving plugin
Info: Caching catalog for ubuntu-vm2.rascanet.local
Info: Applying configuration version '1369400053'
Notice: Finished catalog run in 0.16 seconds

Essendo già stata applicata in precedenza la versione dell’environment rasca, nessuna modifica viene effettuata, esattamente il risultato che ci si aspettava.

Conclusioni

Le potenzialità della gestione di un repository Git condiviso sono enormi e questo articolo ne ha illustrate solamente una minima parte cercando di produrre qualcosa di funzionale che si sposasse con un tool come Puppet che fa delle configurazioni il suo punto cardine.
Utilizzi ed impieghi di questa tecnologia sono limitati unicamente dalla propria fantasia.