Ansible per l’automazione IT ed il Configuration Management

Ansible e l’automazione IT

Ansible e l’automazione IT

Ansible e’ un tool di Configuration Management ed IT Automation che sta riscuotendo un notevole successo tra gli addetti ai lavori in virtu’ della sua immediatezza, della sua semplicita’ di utilizzo e del superamento delle limitazioni della tipica configurazione basata su “server & agent”.

Che cos’e’ Ansible

Ansible quindi e’ un tool di Configuration Management ed IT Automation che rientra nella sfera degli strumenti tipici del metodo DevOps.

DevOps e’ un movimento nato per abbattere il muro di gomma che nel corso degli anni si e’ innalzato tra Developer e Sysadmin. Per usare un’analogia, DevOps e’ una cultura che ha lo scopo di creare una pipeline (in pratica un ponte di comunicazione) tra sviluppatori ed amministratori di sistema.

L’obiettivo e’ uno solo: aumentare costantemente la soddisfazione del cliente producendo ed erogando software allo stato dell’arte con continue release correttive.

Per raggiungere un obiettivo cosi’ ambizioso e’ importante poter contare non solo sulle persone ma anche sugli strumenti. Cosi’ sono nati tool agili ed intuitivi che hanno lo scopo di automatizzare lo sviluppo, il testing e la configurazione di server ed applicazioni. Questa famiglia di tool per il Configuration Management comprende gia diversi nomi blasonati come ad esempio Puppet, Chef, Saltstack e CFEngine.

Configuration Management in breve

Il Configuration Management e’ un processo utilizzato per definire la configurazione delle applicazioni web e dei server in modo consistente, possibilmente sotto controllo di versione. Con il Configuration Management e’ possibile definire a priori come dovra’ essere configurato il server X o l’applicazione Y. Il tutto in linguaggio sorgente o sotto forma di meta-linguaggio.

I tool di Configuration Management leggono le configurazioni a partire da un file sorgente ed applicano le stesse su uno o piu’ server, in modo automatico e prevedibile.

Esempio:

inizio configurazione
1 assicurati che apache2 sia installato
2 assicurati che php5 sia installato
3 assicurati che mysql sia installato
fine configurazione

Un tool di Configuration Management puo’ leggere queste istruzioni ed applicarle su uno o piu’ server. In questo modo l’operatore puo’ replicare la stessa configurazione su decine di server oppure ricostruire la stessa in pochi secondi quando uno o piu’ server vengono messi fuori uso.

Ansible, un po’ di storia

Lanciato nel 2012, Ansible  nasce da un’idea di Michael de Haan, creatore tra l’altro di Cobbler. De Haan un bel giorno sente la necessita’ di scrivere un software che potesse semplificare all’ennesima potenza le attivita’ di Configuration Management ed Automazione IT.

Fino a quel momento il panorama del Configuration Management era dominato da Puppet e Chef (che comunque mantengono e sicuramente manterranno  anche in futuro quote di mercato molto vaste). Ma seppure ottimi, sia Puppet che Chef hanno alcuni punti deboli, che fanno storcere il naso ai Sysadmin piu’ esigenti:

* Puppet e Chef funzionano principalmente in modalita’ server – agent

* Chef richiede anche la conoscenza del linguaggio Ruby

Anche se non si tratta di limitazioni insormontabili ci sono comunque alcuni svantaggi in questo tipo di approccio.

Prima di tutto non sempre e’ possibile installare un agent sul server di destinazione, poiche’ un agent e’ comunque un piccolo software che rimane in esecuzione permanente su uno o piu’ server ed ha lo scopo di attendere comandi e configurazioni impartite dal server master.

Sia Chef che Puppet utilizzano questo approccio che spesso non e’ possibile mettere in pratica.

Pensiamo ad esempio ad ambienti server che per ragioni di conformita’ o sicurezza non possono ospitare agenti o software estranei oppure a quei server con un discreto numero di anni sulle spalle, dove l’installazione di una versione aggiornata di Ruby (richiesta, ad esempio, da Puppet) potrebbe causare effetti imprevedibili.

I vantaggi di Ansible

Perche’ dunque adottare Ansibile ?
Se sei un Sysadmin o un Developer potrai trarre sicuramente grande beneficio dall’uso di questo tool: con Ansible non e’ mai stato cosi’ semplice definire lo stato di un server e delle tue applicazioni web.
Con Ansible quindi il risparmio di tempo e di codice e’ notevole rispetto a Puppet o Chef.

Curva di apprendimento bassa

Dalla lettura della documentazione alla scrittura dei primi Playbooks il passo sara’ breve, ed in pochi minuti vi sara’ possibile iniziare a lavorare con Ansible senza dover penare con configurazioni di server Master e agenti vari.

Non sono richieste capacita’ di coding

Puppet e Chef nascono entrambi da un team di sviluppatori follemente innamorati di Ruby. Per la definizione dello stato dei server e delle configurazioni Puppet adotta un linguaggio simile al codice Ruby mentre per definire lo stato di un server con Chef e’ addirittura essenziale conoscere il linguaggio, invece Ansible supera completamente questa limitazione.

In Ansible ad esempio e’ possibile definire che il server X dovra’ contenere Apache con due righe:
es:

Install Httpd
yum: name=httpd state=latest

Come si puo’ notare, a differenza di Puppet, Chef e Saltstack, Ansible non ha bisogno di nessun agente per applicare le configurazioni su un server. Ansible utilizza di default il trasporto SSH: questo elimina la necessita’ di installare software estraneo sui nodi.

Modulare e Open Source

Ansible e’ composto da numerosi moduli. Per analogia i moduli di Ansible hanno la stessa funzione delle risorse in Puppet. Ogni modulo svolge delle funzioni ben precise e gestisce un singolo aspetto di ogni sistema. Questa architettura consente di espandere Ansible praticamente all’infinito, senza contare che i moduli possono essere scritti in qualsiasi linguaggio di programmazione. Inoltre Ansible e’ Open Source e la comunita’ continua a crescere rapidamente.

Ansible, i concetti chiave

Prima di terminare con questa introduzione su Ansible vediamo quali sono i concetti chiave ed i componenti che ruotano attorno a questo software.

Ansible: l’inventario

L’inventario e’ una lista di server sui quali Ansible applica, a comando, le configurazioni di sistema e le istruzioni di automazione. L’inventario di solito e’ contenuto all’interno del file /etc/ansible/hosts anche se e’ possibile specificare una posizione a piacere.

All’interno dell’inventario l’operatore puo’ specificare la lista dei server “bersaglio”. E’ chiaramente obbligatorio che ogni server abbia una corrispondenza DNS anche se e’ possibile specificare ogni server con il proprio indirizzo IP . Un esempio di inventario:

[webservers]
webserver1.example.com
webserver2.example.com

[dbservers]
dbserver1.example.com
dbserver2.example.com

Ansible ed i Tasks

In Ansible i Tasks sono dei “compiti” ovvero una serie di istruzioni che Ansible esegue in ordine di apparizione. Ogni istruzione contiene la definizione e/o la configurazione che dovra’ essere applicata ad ogni sistema.

Ansible e gli Handlers

Gli Handlers in Ansible sono delle istruzioni che vengono eseguite a seguito di una determinata azione. Ad esempio dopo aver installato httpd un operatore puo’ voler avviare Apache automaticamente. Un esempio di Handler che avvia Apache su CentOS:

name: start httpd
service  : name=httpd state=started enabled=yes

Gli Handlers si basano sul modulo service di Ansible (questo modulo viene utilizzato per gestire i servizi di sistema).

Ansible ed i Playbook

In Ansible i Playbook sono delle collezioni di Tasks. Ogni Playbook puo’ contenere un determinato numero di Tasks e di Handlers. I Playbook devono essere definiti in linguaggio YAML.


Ansible ed i Moduli

Ansible e’ composto da numerosi moduli. Esistono moduli per gestire i servizi di Cloud Computing (EC2 su AWS), Rackspace e Google Compute Engine, esistono moduli per installare pacchetti software su server Linux con apt e yum, moduli per gestire file di configurazione e database e molto altro ancora.

Per una lista completa dei moduli puoi consultare la documentazione ufficiale: Ansible Modules.

#AnsibleConfigurationManagement

Virtualizzazione e provisioning senza sforzo

Vagrant Virtualization Box

Vagrant Virtualization Box

La virtualizzazione ha sicuramente cambiato il modo di lavorare e di pensare alla gestione dei sistemi informatici aziendali o dei service provider, ed il cloud ha aggiunto un’ulteriore strato, sia di liberta’, ma anche di complicazione in piu’, nella gestione dei nuovi sistemi ad alta affidabilita’ che devono essere in grado di scalare nel minor tempo possibile ecc….

Queste esigenze hanno portato alla nascita di innumerevoli sistemi di virtualizzazione, tra i piu’ conosciuti sicuramente ci sono Xen, Vmware, Kvm, Virtuozzo, Virtualbox, Openvz …..! che per certi versi si trasformano in un incubo per gli amministratori di sistema, costretti ad avere diversi ambienti di gestione delle VM su diversi sistemi e con molteplici file di configurazione da settare.

Infatti quando ci troviamo ad amministrare un ambiente cloud con molte macchine, il rischio di dover aggiungere una macchina in più e doverla successivamente configurare in poco tempo per il deploy e la messa in produzione insieme a tutte le altre è molto alto. In più, se siamo all’interno di un’architettura che deve scalare rapidamente per rispondere in modo agile alle esigenze degli utenti (e chiaramente dell’azienda), dover attendere l’installazione del sistema operativo e poi del software non è certamente divertente. Per tutte queste esigenze, Vagrant potrebbe risultare la giusta soluzione che può semplificarci la vita, permettendoci di aggirare tutte queste “rogne”

Vagrant è un gestore di macchine virtuali che può usare parecchi hypervisor tra cui VirtualBox, il predefinito, ma anche VMWare, Xen e KVM. Attraverso questo software infatti potremo basarci su una struttura di base comune a tutte le macchine, che contiene il sistema operativo (anche se poi vedremo come personalizzare questa alberatura), e mantenere degli step comuni nella configurazione delle nostre istanze virtuali, per poi dedicarci solo alle rifiniture, risparmiando tantissimo tempo grazie alle capacità di elaborazione dei datacenter che abbiamo in-house o magari in cloud.

Per inizializzare il nostro primo progetto Vagrant, abbiamo solo bisogno di spostarci in una directory vuota e dare il comando (avendo già installato il software):

Installazione Vagrant

### Verificare di aver installati i seguenti pacchetti : rubygems ruby1.9.1-dev virtualbox-4.2 (o superiori)
# sudo apt-get install vagrant
# vagrant plugin install vagrant-vbguest

Le Box di Vagrant
Il primo concetto fondamentale da fare nostro, per quanto riguarda Vagrant, è quello del concetto di Box. Una Box per quanto riguarda questo ambiente di virtualizzazione infatti è una vera e propria scatola che contiene il sistema operativo, e tutto quello di cui abbiamo bisogno come i software di base ed ogni loro configurazione di base. Al punto di partenza abbiamo delle Box rese disponibili dai server di Vagrant, ma possiamo tranquillamente aggiungerne altre: tutto quello di cui abbiamo bisogno è un po’ di fantasia coi nomi, e di conoscere l’URL remoto tramite il quale scaricare la Box (ne trovate parecchie già fatte su Vagrantbox.es oppure su Hasicorp), con questa sintassi da riga di comando.

# vagrant init
# vagrant box add name url

che, traducendolo con un esempio reale:

# vagrant box add precise32 http://files.vagrantup.com/precise32.box

Che non farà altro che aggiungere al nostro progetto Vagrant una Box Ubuntu 12.04 a 32 bit.

Il Vagrantfile
Una volta scaricata la nostra Box di partenza, possiamo cominciare a configurare il nostro progetto Vagrant tramite il Vagrantfile che abbiamo a disposizione e che si presenta essenzialmente come un file Ruby con vari namespace, ma niente paura, non è necessario conoscere direttamente Ruby per la configurazione (anche se può aiutare), ed è possibile fare riferimento alla documentazione per conoscere i vari prefissi e le possibilità che abbiamo a disposizione. Ogni volta che eseguiamo un comando Vagrant, il Vagrantfile viene cercato in tutte le directory di livello superiore nell’albero.

Il file può avere grossomodo un aspetto del genere:

Esempio di un cluster di 7 Boxes. Preso da:
### https://github.com/patrickdlee/vagrant-examples

domain   = 'example.com'
 
nodes = [
  { :hostname => 'ex7proxy',   :ip => '192.168.0.42', :box => 'precise32' },
  { :hostname => 'ex7db',      :ip => '192.168.0.43', :box => 'precise32' },
  { :hostname => 'ex7web1',    :ip => '192.168.0.44', :box => 'precise32' },
  { :hostname => 'ex7web2',    :ip => '192.168.0.45', :box => 'precise32' },
  { :hostname => 'ex7static1', :ip => '192.168.0.46', :box => 'precise32' },
  { :hostname => 'ex7static2', :ip => '192.168.0.47', :box => 'precise32' },
  { :hostname => 'ex7cache',   :ip => '192.168.0.48', :box => 'precise32' },
]
 
Vagrant::Config.run do |config|
  nodes.each do |node|
    config.vm.define node[:hostname] do |node_config|
      node_config.vm.box = node[:box]
      node_config.vm.host_name = node[:hostname] + '.' + domain
      node_config.vm.network :hostonly, node[:ip]
 
      memory = node[:ram] ? node[:ram] : 256;
      node_config.vm.customize [
        'modifyvm', :id,
        '--name', node[:hostname],
        '--memory', memory.to_s
      ]
    end
  end
 
  config.vm.provision :puppet do |puppet|
    puppet.manifests_path = 'puppet/manifests'
    puppet.manifest_file = 'site.pp'
    puppet.module_path = 'puppet/modules'
  end
end

Prima di arrivare a questo livello tuttavia, è necessario cominciare dalle basi: il primo file di configurazione di Vagrant che andremo a scrivere conterrà ben poche specifiche, e si baserà esclusivamente sulla Box che abbiamo scelto per la nostra prima macchina virtuale.

# Una singola Box.
#
Vagrant.configure(“2”) do |config|
config.vm.box = “precise32”
end

Esempio per una singola Box.

Vagrant.configure("2") do |config|
config.vm.box = "precise32"
end

Inoltre il Vagrantfile deve essere soggetto a version control (tramite git ad esempio) per tenere traccia di ogni modifica e rendere il tutto facilmente riportabile in una nuova architettura

Avviamo la Box

# sudo vagrant up
Bringing machine 'default' up with 'virtualbox' provider...
[default] Importing base box 'precise32'...
[default] Matching MAC address for NAT networking...
[default] Setting the name of the VM...
[default] Clearing any previously set forwarded ports...
[default] Clearing any previously set network interfaces...
[default] Preparing network interfaces based on configuration...
[default] Forwarding ports...
[default] -- 22 => 2222 (adapter 1)
[default] Booting VM...
[default] Waiting for machine to boot. This may take a few minutes...
[default] Mounting shared folders...
[default] -- /vagrant

Adesso che abbiamo il nostro progetto funzionante, basterà dare

# vagrant ssh
Last login: Fri Apr 15 05:43:58 2011 from 10.0.2.2
[vagrant@localhost ~]$

per collegarci ed esserne subito operativi all’interno della nostra box.

Provisioning
Vagrant non è solo un sistema per avviare velocemente delle macchine virtuali, infatti ci permette anche di controllarle, e di controllarne le impostazioni nel tempo, insieme al software installato. Possiamo quindi gestire la configurazione automatica secondo le nostre esigenze delle varie Box che abbiamo, attraverso una struttura di provisioning abbastanza flessibile che supporta normali shell script (Bash), il buon vecchio Puppet, ma anche Chef e Ansible.

Tramite questa infrastruttura possiamo modificare il Vagrantfile per eseguire quindi qualsiasi istruzione, che sia configurata per script Puppet oppure attraverso Bash. Ad esempio, possiamo utilizzare la piccola struttura riportata di seguito, che proviene direttamente dalla documentazione di Vagrant e che mostra come sia facile scriversi uno script di configurazione da mandare poi in pasto alla propria Box.

$script = <<SCRIPT
echo I am provisioning...
date > /etc/vagrant_provisioned_at
SCRIPT
Vagrant.configure("2") do |config|
config.vm.provision "shell", inline: $script
end

Non solo VirtualBox

Una volta imparato a usare Vagrant, avremo comunque basato tutto il nostro lavoro su VirtualBox. Tuttavia, potremmo anche avere qualcosa in contrario sull’uso di VirtualBox, e voler usare altri provider che ci permettano un’amministrazione più efficace o semplicemente il riciclo di competenze che già abbiamo. Ad esempio, Vagrant supporta tramite plugin anche l’integrazione con VMWare o con Xen; questi plugin sono installabili attraverso il gestore integrato nel software, semplicemente tramite un singolo comando, esattamente come in un classico gestore di pacchetti:

# vagrant plugin install vagrant-vmware-fusion

Oppure se invece di VMWare Fusion usate la variante Workstation:

# vagrant plugin install vagrant-vmware-workstation

Una volta installato il plugin, ed ovviamente il software di providing delle macchine virtuali che vogliamo testare, ci bastera’ modificare il Vagrantfile, con istruzioni come queste nell’ esempio:

Esempio tratto da [ http://puppetlabs.com/blog/new-vmware-provider-gives-vagrant-a-boost ]

config.vm.provider :vmware_workstation do |v|
v.vmx["memsize"] = "2048"
end

Vagrant può ovviamente essere configurato per essere alla base di una complessa configurazione in ambiente cloud, o della propria infrastruttura più modesta.

Se questo primo articolo vi ha incuriositi, la documentazione ufficiale, passo passo, vi sta aspettando : VAGRANT DOC

Nel prossimo articolo vedremo come sfruttare le potenzialita’ di Vagrant + Docker.

#VagrantVirtualizzazioneeProvisioning

Puppet: automatizziamo e gestiamo ogni task

Puppet Labs

Puppet Labs

Introduzione a Puppet

Puppet è un software open source, scritto in linguaggio Ruby, che permette la gestione automatizzata e centralizzata di un’infrastruttura di sistemi Linux e Unix, essendo disponibile per tutte le principali distribuzioni Linux, ma anche per le diverse varianti di BSD oltre che Solaris e AIX.

Con Puppet è possibile gestire praticamente ogni risorsa di un sistema: programmi da insallare, servizi da avviare, file di configurazione con contenuti diversi a seconda di diverse logiche, utenti, cron jobs, mount point, esecuzione di comandi specifici ecc.
Praticamente permette di automatizzare ogni attività sistemistica cambiando di fatto il modo con sui si opera su sun server.

La logica di Puppet è di definire lo stato di un sistema e fare in modo che questo sia tale ogni volta che il client Puppet viene eseguito.
La prima volta che lo si esegue, vengono installati pacchetti, avviati servizi, modificati file di configurazione secondo quanto definito sul PuppetMaster, le volte successive, se non sono intervenute modifiche manuali sul sistema, o cambiamenti delle configurazioni sul master, non dovrebbe cambiare nulla, altrimenti verranno upgradati eventuali file di configurazione o servizi, cosi come indicato sul PuppetMaster.
Questo è un concetto importante per il sistemista, e’ un vero e proprio cambio di paradigma sul suo modo di operare, poiche’ in un sistema gestito con Puppet non si devono modificare a mano i file che Puppet gestisce, perchè questi vengono aggiornati al successivo collegamento/verifica con il Master e, visto che nelle condizioni ideali, Puppet gestisce tutte le risorse di un sistema (non è obbligatorio che sia così, ma è comunque consigliabile), di fatto, salvo in casi di emergenza, un sistemista non dovrà mai intervenire a mano sui suoi server.

Se da un lato tutto questo può risultare laborioso e in qualche modo “innaturale” nella gestione dall’altro comporta una serie di vantaggi clamorosi:
– Si può configurare il profilo di un server ed applicarlo a decine o centinaia di host, tutti uguali, tutti allineati, tutti configurati con la stessa logica.
– La procedura di setup e configurazione di un sistema è riproducibile, evitando cosi’ di trovarsi a gestire dei sistemi che poi non si sanno più reinstallare.
– E’ facile e quasi intrinseco prevedere per ogni host il suo corrispettivo di sviluppo, collaudo e produzione, non avendo limiti nel numero di ambienti previsti e avendo la certezza di avere i sistemi fra di loro allineati.
– I manifest di puppet sono generalmente gestiti con un sistema di versioning (git, subversion, cvs vanno tutti bene), questo comporta automaticamente una gestione formale, reversibile, documentata e tracciata delle modifiche fatte sui sistemi.

Il risultato è che, già in infrastrutture di qualche decine di host, Puppet diventa uno strumento unico e insostituibile per una gestione rapida ed efficace del parco macchine, lo sforzo inizlae di definizione delle sue configurazioni viene ampiamente ripagato nel tempo con tempi di gestione e setup dei sistemi enormemente ridotti.
Insomma, con Puppet ci si può dedicare al miglioramento e l’affinamento della propria infrastruttura risparmiando il tempo speso in attività ordinarie ripetitive e noiose.

Per chi volesse provare le potenzialita’ di Puppet oggi e’ possibile scaricare una versione Free Trial direttamente dal sito del produttore [To try Puppet Enterprise for free on up to 10 nodes].
Vi verranno richieste soltanto alcune informazioni formali, prima di poter ottenere il file installabile per la versione della nostra distro (sia 32 che 64 bit).
Potrete cosi’ scaricare il pacchetto puppet-<vostra versione>.tar.gz sul vostro Puppet Server; una volta estratto il contenuto del file, ad esempio sotto /opt , per lanciare l’installazione del pacchetto vi bastera’ lanciare lo script :

cd /opt/puppet

# sudo ./puppet-enterprise-installer

L’installazione procedera’ sostanzialmente da sola, all’inizio ci verra’ soltanto chiesta la conferma (premendo Y ) per avviare il processo d’installazione e copia dei file necessari, dopodiche’ bastera’ avere un po’ di pazienza.

Altrimenti e’ possibile questa ulteriore strada (ad esempio per un sistema Ubuntu 14.x)

wget https://apt.puppetlabs.com/puppetlabs-release-trusty.deb
sudo gdebi puppetlabs-release-trusty.deb 
sudo apt-get update 
sudo aptitude install puppet-common=3.7.3-1puppetlabs1 puppet=3.7.3-1puppetlabs1
sudo apt-get install puppetmaster-passenger

Nel caso in cui invece dobbiate solo fare un upgrade all’ultima versione vi bastera’ eseguire :

$ sudo apt-get update
$ sudo puppet resource package puppetmaster ensure=latest

Se poi non avete il tempo da impiegare nell’installazione, ma non volete perdere l’occasione di testare un prodotto cosi interessante potete anche scaricare una VM gia pronta al seguente link puppetlabs_VM

Configurazione

– Il puppet master
Raggiungete la macchina prescelta come puppet master che chiameremo, senza troppa fantasia, master e installate i programmi necessari:

root@master:

~# apt-get install puppetmaster

Questa operazione installerà anche le dipendenze, compreso il pacchetto per l’agent puppet.
L’installazione terminerà con uno sconfortante errore: niente paura! semplicemente il master non è ancora stato configurato a dovere e gli script di init non sono in grado di avviarlo correttamente.
Preoccupiamoci innanzitutto di permettere l’accesso ai file che verranno serviti dal nostro master, editate il file /etc/puppet/fileserver.conf e aggiungete una riga per permettere l’accesso alla sottorete 192.168.0.0/24 (per esempio).

 

Prepariamo un piccolo laboratorio con 3 macchine

Name                 IP                     OS                    Descrizione
puppet01        192.168.1.10            CentOS 6.5               puppet master
puppet02        192.168.1.20            CentOS 6.5               puppet client
puppet03        192.168.1.30            CentOS 5.10              puppet client

** configuriamo il file /etc/hosts

# vim /etc/hosts

192.168.1.10    puppet01
192.168.1.20    puppet02
192.168.1.30    puppet03

– Inseriamo queste due righe nel [main] edl file /etc/puppet/puppet.conf

certname = puppet
dns_alt_names = puppet,puppet01.localdomain

– Configuriamo il certificato
Con questo comando si creerà il certificato CA e il certificato per il puppetmaster

puppet01 # puppet master –verbose –no-daemonize

notice: Starting Puppet master version 2.7.25
(una volta apparsa la riga qui sopra potete chiudere con un Ctrl-C)

* verifichiamo: # puppet cert list –all
+ “srv-c6.localdomain” (10:BD:EB:92:CE:98:A7:37:FE:4B:D8:20:5E:C2:44:D5) (alt names: “DNS:puppet”, “DNS:puppet.localdomain”, “DNS:puppet01.localdomain”)

* riavviamo il servizio :

#  /etc/init.d/puppetmaster restart

Installazione dei client

sulle macchine puppet02 e puppet03 installare soltanto il client “puppet” nei seguenti modi :

Ubuntu/Debian : # sudo apt-get install puppet

RHEL/Centos   : # sudo yum install puppet -y

** sulle macchine client andremo a modificare il file puppet.conf indicando il nome della macchina Server, il puppetmaster

# vim /etc/puppet/puppet.conf

[agent]
server = puppet01

su puppet02 e puppet03

# puppet agent –test # si dovrebbe vedere l’agente creare una richiesta di certificato al master

ora su puppet01 eseguite

# puppet cert list –all # dovreste vedere le richieste effettuate dai client 01 e 02

La prima fase e’ cosi terminata, nel prossimo articolo vedremo come installare e configurare la Dashboard di Puppet per avere una gestione centralizzata tramite Browser