Elaborato Amoruso Pasquale N46-001033

Scuola Politecnica e delle Scienze di Base
Corso di Laurea in Ingegneria Informatica
Elaborato finale in Reti di Calcolatori
Analisi di strumenti software per l’automazione
dei processi di Configuration Management dei
sistemi: Puppet Software Tool
Anno Accademico 2013/2014
Candidato:
Pasquale Amoruso
matr. N46001033
Alla mia famiglia,
per essermi stata sempre vicina.
Sempre.
Indice
Indice .................................................................................................................................................. III
Introduzione ......................................................................................................................................... 4
Capitolo 1: Il movimento DevOps ....................................................................................................... 7
1.1 I principi e le finalità secondo DevOps ...................................................................................... 8
1.2 DevOps & Mobile .................................................................................................................... 11
1.3 DevOps & Business: Opinioni ................................................................................................. 12
Capitolo 2: Puppet.............................................................................................................................. 13
2.1 Puppet Management Tool ........................................................................................................ 14
2.1.1 Come funziona Puppet (Master/Agent) ?.......................................................................... 15
2.1.2 Come installare e configurare Puppet? ............................................................................. 16
2.1.3 Puppet Enterprise Console (PE Console).......................................................................... 27
Capitolo 3: Panoramica su Chef, Ansible e Salt ................................................................................ 31
3.1 Chef .......................................................................................................................................... 31
3.2 Ansible ..................................................................................................................................... 32
3.3 Salt ........................................................................................................................................... 33
Conclusioni ........................................................................................................................................ 35
Bibliografia ........................................................................................................................................ 38
Introduzione
Puppet è uno degli strumenti software open-source (disponibile anche nella versione
commerciale) nati negli ultimi dieci anni allo scopo di gestire sistemi e infrastrutture di rete
durante il loro ciclo di vita in maniera del tutto automatica, dalla configurazione e
provisioning fino al reporting, e di mantenere sempre aggiornata un'enorme quantità di
servizi da essi offerti, garantendo così costi sempre più bassi [1].
L’esigenza di nuove funzionalità e l’inevitabile crescita della rete Internet e della potenza dei
server, accompagnate dalla nascita di nuove tecnologie come il cloud computing, hanno
portato ad un aumento significativo del numero di server da gestire all'interno e all'esterno di
un'organizzazione. Ciò ha incrementato la necessità di automatizzare i processi di gestione
del software e dei servizi distribuiti, per esempio, su strutture virtuali o in esecuzione sul
cloud oppure su istanze ospitate in data center remoti, superando così le difficoltà dovute alla
loro gestione manuale che rendeva man mano sempre più onerose e costose le operazioni di
manutenzione e complicava di conseguenza l’espansione, lo sviluppo del software e le
relative operazioni di testing.
Grazie a questi software management tools si è in grado di seguire l’intero ciclo di vita di un
sistema, a partire dalla creazione e inizializzazione della sua prima istanza fino ad
automatizzare operazioni di modifiche e di aggiornamento della stessa.
Esistono due principali approcci alla gestione: Standalone (Single-Host) e Master/Agent.
4
Le infrastrutture più piccole e meno complesse possono beneficiare del modello Masterless
per sviluppare e testare rapidamente nuove configurazioni, evitando il sovraccarico del
modello Client/Server consigliato, invece, per distribuzioni più complesse che richiedono
maggior centralizzazione ma, allo stesso tempo, maggior parallelismo delle operazioni di
gestione. Infatti, il modello Standalone (Fig. 1) consiste nel testare e inviare cataloghi da una
workstation locale, in cui è installato il software tool, in grado di funzionare sia da client che
da server.
Figura 1: Modello Standalone per la gestione delle istanze software
Secondo il modello Master/Agent (Fig. 2), invece, ogni client (Agent) esegue autonomamente
il software tool con cui è in grado di richiedere nuovi cataloghi al server (Master), il quale è
in grado di stabilire connessioni in entrata e in uscita con tutti i nodi della rete e di gestire
separatamente le informazioni di configurazione per ciascuno di essi.
Figura 2: Modello Master/Agent per la gestione delle istanze software
5
Oltre al Puppet, esistono altri tools (open-source o in versione Enterprise), come Chef, Salt e
Ansible, tutti in grado di configurare e manutenere decine, centinaia o addirittura migliaia di
server. Essi forniscono un proprio DSL (Domain-Specific Language) in modo da poter
definire all’interno di ciascun file di configurazione lo stato finale desiderato per il sistema da
gestire.
In questo elaborato è effettuata una panoramica sulle caratteristiche di ciascun tool
sovracitato, soffermando maggiormente l’attenzione sul modello Master/Agent di Puppet di
cui sarà illustrata la procedura di configurazione e il tipo di informazioni trasmesse durante la
comunicazione tra due host di riferimento. Inoltre, è mostrato l’utilizzo della Puppet
Enterprise Console (PE Console), l’interfaccia web utente presente all’interno della versione
Enterprise del software che consente di realizzare il classifying di un agent locale e gestire la
sua esecuzione tramite Live Management.
6
Capitolo 1: Il movimento DevOps
Col termine DevOps si intende il principio secondo cui imprenditori e sviluppatori, operation
managers e servizi di garanzia della qualità, appartenenti ad una stessa organizzazione IT
(Information Technology), lavorano uniti allo scopo di migliorare la produttività e la velocità
di sviluppo e distribuzione del software, automatizzando i flussi di lavoro e misurando
continuamente le prestazioni delle applicazioni [2].
Tradizionalmente, Dev (Developers) e Ops (Operations Team) lavorano separatamente: da
un lato, uno sviluppatore costruisce l’applicazione; dall’altro, un team operativo si occupa di
tutto il resto, come il controllo di qualità del software, l’ottimizzazione della gestione delle
risorse, ecc. Questa distinzione dava i suoi frutti quando realizzare un’applicazione richiedeva
ancora settimane o mesi. Ma nell’attuale era degli app store e dei software-as-a-service la
durata dello sviluppo del software si è ridotta a pochi giorni e quindi il divario tra developers
e operations è stato messo quasi subito in discussione. Inoltre, molto spesso viene progettata
un’applicazione al di là di ciò che l’infrastruttura IT può realmente offrire: infatti può
succedere, ad esempio, che non ci sono abbastanza risorse disponibili per eseguire
l’applicazione su larga scala.
Il movimento DevOps nasce nel 2009 quando fu organizzata una serie di DevOps Days
(iniziati in Belgio e poi svolti in India, USA, Brasile, Australia, Germania e Svezia) per
discutere sul divario operativo e lasciare che ingegneri del software potessero parlare dei
modi migliori per raggiungere dimensioni e velocità ottimali nella distribuzione del codice.
7
In questo contesto molte imprese incominciarono ad assumere dei professionisti del
DevOps come agenti intermediari di scambio culturale fra le due entità, e in parallelo altre
aziende, quali SaltStack, AnsibleWorks, Chef e Puppet Labs, trovarono il loro successo nella
costruzione di strumenti software per favorire lo sviluppo delle metodologie portate avanti dal
movimento.
Il DevOps ha trovato terreno fertile soprattutto grazie all’avvento del cloud computing, un
insieme di servizi e tecnologie che permettono di memorizzare e elaborare dati grazie
all’utilizzo di risorse hardware/software distribuite e virtualizzate in rete, favorendo
l’automazione e la continuità in termini di sviluppo e distribuzione del software.
L’idea fondamentale di DevOps, quindi, è “descrivere un’infrastruttura come codice” per
consentire il provisioning e la configurazione di ambienti DevOps, grazie all’utilizzo di alcuni
tools essenziali come Git-GitHub e Jenkins. Il primo è una repository per la memorizzazione
di versioni del codice che può essere scaricato e condiviso, noto anche come sistema di
revisione e di controllo; il secondo, invece, è un open source continuous integration server
essenziale per testare il nuovo codice, prima della distribuzione tramite tools come Chef,
Puppet, Salt e Ansible. Questi ultimi sono capaci di spingere le infrastrutture IT verso nuovi
radicali cambiamenti, accelerando i progressi tecnologici e rendendo numerose aziende
sempre più competitive perché pronte a rispondere rapidamente alle richieste di mercato.
1.1 I principi e le finalità secondo DevOps
Lo sviluppo e l’adozione di qualsiasi nuova funzionalità richiede, tipicamente, persone,
processi e tecnologia. Anche se il termine DevOps suggerisce questo, esso è qualcosa di
concettualmente più grande poiché coinvolge tutte le parti interessate in un’organizzazione,
come imprenditori, architetture, design, sviluppo, qualità, sicurezza, partner e fornitori.
DevOps è cultura: alla radice c’è, infatti, un movimento culturale. Un’organizzazione può
adottare gli strumenti e i processi più automatizzati possibile, ma questi sono inutili senza la
presenza di un team di persone in grado di eseguire tali operazioni e utilizzare tali strumenti.
8
Alla base vi è un elevato grado di collaborazione tra le persone dell’organizzazione, ognuna
con le proprie esperienze e capacità, unite per formare, quindi, una cultura basata sulla
fiducia, individuando gli obiettivi di business comuni ed eliminando ogni forma di
competizione.
DevOps non è l’obiettivo, ma aiuta a raggiungere gli obiettivi. Esso, infatti, investe su tre
punti fondamentali:
- Miglioramento dell’esperienza dell’utente finale: il business deve continuamente soddisfare
le richieste dei clienti, grazie al feedback raccolto da tutti gli stakeholder dell’applicazione,
come linee di business, utenti, fornitori, partner, ecc.
- Incremento della capacità di innovazione: obiettivi primari sono ridurre gli sprechi e
riorganizzare le risorse per applicazioni di maggior valore.
- Incremento della velocità di valutazione: sono richiesti strumenti e nozioni per facilitare la
pianificazione di un rilascio efficiente e migliorare la prevedibilità e il successo.
Il movimento DevOps si basa su alcuni principi ancora in evoluzione, tra cui:
- Sviluppo e testing tramite shift-left: lo scopo è quello di implementare e testare il software,
osservando continuamente il comportamento dell’applicazione durante le varie fasi di
sviluppo attraverso l’approccio dello shift-left (Fig. 3) prima che sia pronta per la
distribuzione.
Figura 3: Rappresentazione grafica dell’approccio shift-left
9
- Supporto alla distribuzione mediante processi affidabili e ripetibili: qui l’automazione è
essenziale affinché l’organizzazione possa implementare test automatici sulla distribuzione
del software, riducendo il rischio di fallimenti al momento del rilascio.
- Monitoring e convalida della qualità operativa: in base a questo principio è necessario
monitorare le caratteristiche, funzionali e non, dell’applicazione attraverso l’utilizzo e la
valutazione di determinate metriche sulla qualità. Questi parametri devono essere acquisiti in
un formato tale da poter essere compresi e utilizzati da tutti gli stakeholder dell’azienda.
- Amplificazione dei cicli di feedback: questo principio richiede alle organizzazioni di creare
canali di comunicazione affinché gli stakeholder possano accedere e operare sul feedback.
Le funzionalità che caratterizzano DevOps sono organizzate in modelli di riferimento per le
aziende, costituiti da un insieme di persone specializzate, pratiche ben definite e strumenti di
automazione, nel rispetto di quattro set di procedure:
- Pianificazione e Misura: consiste in una pratica concentrata sulle linee di business e sulla
loro pianificazione. Le aziende devono essere in grado di rispondere rapidamente al feedback
dei clienti, attuando tecniche di lean thinking allo scopo di aumentare l’efficienza e ridurre gli
sprechi. Secondo queste tecniche bisogna partire da risultati e risorse necessarie al
soddisfacimento dei vincoli di business, per poi regolare lo sviluppo e gli aggiornamenti del
software in base alle esigenze e ai progressi compiuti.
- Sviluppo e Testing: i responsabili di queste operazioni lavorano in squadre che spesso sono
distribuite in più sedi. In base allo sviluppo collaborativo, queste si trovano a lavorare
insieme, condividendo pratiche e piattaforme che possono utilizzare per creare e distribuire il
software. La caratteristica di base di questo tipo di sviluppo è l’integrazione continua del
lavoro svolto dagli sviluppatori con quello degli altri membri del team. In particolare, ciò
consente di verificare di volta in volta il codice integrato con le funzioni e con gli altri
componenti dell’applicazione e testarla continuamente in fase di sviluppo, con l’aiuto di
processi automatizzati e servizi virtualizzati.
10
- Rilascio e Distribuzione: l’obiettivo è quello di rilasciare nuove funzionalità agli utenti il più
presto possibile.
- Monitoraggio e Ottimizzazione: il monitoring permette alle aziende di ottenere risultati più
facilmente e rapidamente ed ottimizzare, se necessario, i loro piani aziendali. Questa
procedura fornisce dati e metriche di valutazione della qualità del progetto che, insieme al
feedback che i clienti forniscono utilizzando personalmente l’applicazione, permette di
prendere misure appropriate per migliorare le applicazioni e la customer experience.
1.2 DevOps & Mobile
Discorso a parte, invece, va fatto per le applicazioni mobili: lo sviluppo e la conseguente
consegna del software mobile sono più complessi e richiedono una serie di servizi dipendenti
tra loro da portare a termine in modo coordinato con affidabilità ed efficienza. In particolare,
per le app mobili aziendali è necessario coordinare i rilasci dei propri servizi con le altre app
mobili con cui interagiscono. Infatti, secondo DevOps si dovrebbe adottare un team formato
dagli utenti insieme al resto del team aziendale.
Inoltre, la maggior parte delle applicazioni non possono essere distribuite direttamente ma
devono essere immagazzinate negli store online. Infatti, anche per correzioni di bug critici, le
nuove versioni di un’applicazione devono passare prima per altre due fasi, cioè quelle di
presentazione e recensione sugli app store. Nonostante ciò, è ancora possibile effettuare
testing grazie all’esistenza di simulatori per dispositivi mobili su cui andranno poi a girare le
applicazioni. L’utilizzo dei simulatori è essenziale anche per testare l’hardware: infatti la
collaborazione tra sviluppo/testing ed ingegneri dei sistemi, che progettano e costruiscono
hardware dedicato ai dispositivi, è fondamentale per garantire che hardware e software siano
sviluppati e consegnati coordinatamente, nonostante essi seguono processi di creazione e
distribuzione differenti.
11
1.3 DevOps & Business: Opinioni
“DevOps è ampiamente compreso come un modo per risolvere un problema IT,
consentendo alle operations e allo sviluppo di collaborare per la consegna e la distribuzione
del software. Ma non è il suo obiettivo finale”, come ha detto Damon Edwards, co-fondatore
della DTO Solutions. “Il punto di DevOps”, ha aggiunto poi, “è quello di consentire alle
attività di business di reagire alle forze di mercato nel modo più rapido, efficiente e affidabile
possibile. Senza il business non c’è ragione di parlare di questioni relative a DevOps, né tanto
meno spendere tempo a risolverle”.
Anche l’IBM (International Business Machines Corporation) dichiara una visione più
olistica a riguardo, vedendo DevOps come un approccio allo sviluppo del software businessdriven, cioè un approccio che consente alle aziende di avere una maggiore attenzione al
mondo del business, a partire da un’idea fino alla sua produzione, catturando il feedback da
parte dei clienti e sviluppando poi miglioramenti sulla base di tale informazione.
“DevOps non riguarda i software tools, si tratta di cultura”, come ha detto Patrick Debois
che ha coniato il termine del movimento e ha fondato la conferenza DevOps Days. Secondo
Debois i tools giocano un ruolo importante nella gestione del software ma DevOps non
definisce di per sé una categoria di strumenti software.
12
Capitolo 2: Puppet
Puppet è uno strumento di gestione delle risorse e del software, rilasciato nel 2005 dalla
Puppet Labs, grazie al quale è possibile automatizzare facilmente operazioni ripetitive,
sviluppare rapidamente applicazioni critiche e gestire proattivamente cambiamenti all’interno
di un’infrastruttura (hardware-software) in poco tempo.
Esso consente di:
- definire lo stato desiderato della configurazione dell’infrastruttura grazie ad un linguaggio
di tipo dichiarativo;
- simulare modifiche alla configurazione stessa prima di renderla definitiva per
quell’infrastruttura;
- applicare lo stato desiderato in maniera automatica, correggendo così eventuali variazioni
nella configurazione;
- confrontare gli stati reali dell’infrastruttura con quelli desiderati apportando, se necessario,
modifiche alla configurazione per il raggiungimento dello stato finale.
Per poter definire, quindi, lo stato desiderato del sistema, ci sono più di 2000 moduli di
configurazione pre-compilati messi a disposizione online dal Puppet Forge Marketplace da
cui sono scaricabili gratuitamente. Inoltre, è possibile definire nuovi moduli in base alle
proprie specifiche di realizzazione utilizzando il DSL di Puppet. Infine, si possono realizzare
dei complete application configuration stacks in modo che più moduli condividano lo stesso
tipo di configurazione.
13
Puppet Software è disponibile nelle due distribuzioni OpenSource (personalizzabile,
flessibile e disponibile sotto la licenza Apache 2.0) e Enterprise (che include più di 40 servizi
open-source come Puppet, PuppetDB, PE Console, ecc.). In particolare, in questo elaborato
vengono illustrate le istruzioni necessarie per:
- installare la versione gratuita su due sistemi linux-based Ubuntu, in esecuzione su due
VMware virtual machines, una per ospitare il server e l’altra per il client, collegate alla stessa
rete interna (indirizzi IP del tipo: 192.168...);
- automatizzare semplici attività di configurazione all’interno di un’infrastruttura IT locale.
E’ stata poi scaricata gratuitamente la Learning VM, una macchina virtuale pre-impostata e
configurata con PE 3.2.1 (versione di prova), messa a disposizione dalla Puppet Labs al fine
di mostrare il funzionamento della GUI (Graphical User Interface) per la Configuration
Management di un nodo [3].
2.1 Puppet Management Tool
Puppet Management Tool rappresenta lo strumento più completo in termini di azioni
disponibili, moduli di configurazione e interfaccia utente. La versione open-source offre le
funzionalità fondamentali sulla gestione a quasi tutti i principali sistemi operativi. Tutti i
moduli e le configurazioni sono scritti con un linguaggio specifico, basato su Ruby,
richiedendo particolari competenze di programmazione. Per quanto riguarda l’interfaccia
utente, Puppet ha la GUI più completa tra i tools sovracitati, con pieno supporto per Linux,
Microsoft Windows, Unix/Unix-like e MacOS X, consentendo il controllo in tempo reale dei
nodi gestiti mediante moduli e cataloghi precedentemente compilati ma limitando la
possibilità di configurarli. Il reporting, invece, è ben sviluppato in quanto fornisce dettagli
sullo stato dei sistemi e sulle modifiche di volta in volta apportate.
Dopo aver installato il software, possono essere necessarie modifiche ai file di configurazione
a seconda del caso specifico. In particolare, secondo la modalità Master/Agent, i client agent
riceveranno le informazioni dal server master tramite operazioni di polling.
14
2.1.1 Come funziona Puppet (Master/Agent) ?
E’ caratterizzato da un server master Puppet e da uno o più client agent Puppet. In realtà, è
possibile configurare più di un master per evitare il sovraccarico delle richieste da parte dei
client. Tutte le possibili configurazioni sono salvate sul server e da questo poi distribuite ai
vari hosts ad esso connessi.
Come illustrato in Fig. 4, ogni client contatta il server sulla porta 8140 (impostata di
default). La connessione che si stabilisce tra loro è crittografata: il client genera una key
auto-firmata prima di collegarsi al server, dopodiché gliela invia e attende che la verifichi. In
seguito, l’agent invia una richiesta di certificato che il master deve convalidare per poter
stabilire definitivamente una connessione sicura, cioè il server si comporta come “autorità di
certificazione”. In questo modo il client potrà richiedere (polling) le impostazioni di
configurazione compilate precedentemente sul server e applicarle poi sul proprio sistema.
Figura 4: Rappresentazione grafica della connessione crittografata tra client e server
15
Dopo aver creato le due istanze virtuali, si può procedere con l’installazione e la
configurazione del software Puppet. I comandi che seguono provvedono anche ad installare
Ruby, come linguaggio di programmazione, e il tool facter, che legge tutte le informazioni
di sistema (come hostname, indirizzo IP, sistema operativo, ecc…) e le rende disponibili a
Puppet . Infatti, il facter deve essere installato su tutti i client Puppet consentendo loro di
inviare dettagli specifici utili al server ad esso collegati, prima di procedere alla fase di
configurazione.
2.1.2 Come installare e configurare Puppet?
1. Scaricare i packages richiesti da Puppet su ciascuna macchina (server e client);
dalla Command Line Interface (CLI) quindi digitare :
#sudo apt-get update
#sudo apt-get install irb libopenssl-ruby libreadline-ruby rdoc ri ruby ruby-dev
2. Installare Rubygems (servizio di hosting della comunità di Ruby),
#cd /usr/local/src
#sudo wget http://production.cf.rubygems.org/rubygems/rubygems-1.5.2.tgz
#sudo tar -xzf rubygems-1.5.2.tgz
#cd rubygems-1.5.2
#sudo ruby setup.rb
#sudo update-alternatives --install /usr/bin/gem gem /usr/bin/gem1.8 1
#sudo gem update –system,
grazie al quale sarà installato Puppet open-source:
#sudo gem install puppet
16
3. Digitare ifconfig per conoscere il proprio IP, mentre digitare nmap –sP
192.168.1.1/24 per conoscere gli IP degli host connessi alla rete (interna) di
riferimento, potendo così settarli nel file /etc/hosts di ciascun sistema attraverso il
seguente comando:
#echo 192.168.1.- puppetmaster.example.com puppetmaster puppet >> /etc/hosts #IP server master
#echo 192.168.1.- puppetclient.example.com puppetclient >> /etc/hosts #IP client agent
4. Configurare quindi il server master Puppet:
#cd /etc
#sudo wget http://bitfieldconsulting.com/files/powering-up-with-puppet.tar.gz
#sudo tar -xzf powering-up-with-puppet.tar.gz
A tal proposito, si noti che è stato scaricato un archivio (powering-up-with-puppet.tar.gz)
che si può usare come modello di configurazione base, reso disponibile da John Arundel
della Bitfield Consulting, per creare le seguenti due directories: /etc/puppet/modules/,
contenente il codice Puppet, e /etc/puppet/manifests/, in cui è specificato come applicare il
codice ai client. In particolare, si possono aggiungere moduli nella directory …/modules/
dopo averli scaricati gratuitamente dal sito della Puppet Forge.
5. Aprire il terminale su ciascun sistema e accedervi come root, digitando:
#sudo –i
6. Impostare correttamente il firewall. Per semplicità può essere disattivato al boot del
sistema col seguente comando:
#ufw disable
17
In realtà, bisognerebbe impostare il firewall in base alle proprie specifiche di
comunicazione. In questo caso specifico, bisogna consentire tutto il traffico dati attraverso
l’interfaccia loopback lo (locale) della workstation:
#iptables -A INPUT -i lo -j ACCEPT
Per quanto riguarda la comunicazione col server, invece, bisogna consentire tutto il traffico
dati che dall’esterno chiede di entrare attraverso la sua porta (di default 8140):
#iptables -A INPUT -p tcp --dport 8140 -j ACCEPT
7. Cancellare eventuali vecchi certificati di connessione presenti sul server:
#puppet cert clean --all
8. Cancellare eventuali precedenti richieste di certificato presenti sul client:
#cd /etc/puppet/ssl/
#cd certificate_requests/
#rm –rf /etc/puppet/ssl/*
9. Avviare il server Puppet:
#puppet master --mkusers --verbose
#per la prima volta
Info: Creating a new SSL key for puppetmaster.example.com
Info: csr_attributes file loading from /etc/puppet/csr_attributes.yaml
Info: Creating a new SSL certificate request for puppetmaster.example.com
Info: Certificate Request fingerprint (SHA256):
Notice: puppetmaster.example.com has a waiting certificate request
Info: Autosigning puppetmaster.example.com
Notice: Signed certificate request for puppetmaster.example.com
18
Notice:
Removing
file
Puppet::SSL::CertificateRequest
puppetmaster.example.com
at
puppetmaster.example.com
at
'/var/lib/puppet/ssl/ca/requests/puppetmaster.example.com.pem'
Notice:
Removing
file
Puppet::SSL::CertificateRequest
'/var/lib/puppet/ssl/certificate_requests/puppetmaster.example.com.pem'
Notice: Starting Puppet master version 3.6.1
10. Avviare l’agent dalla root directory del client:
#puppet agent (–server hostname) --verbose –waitforcert 60 (--test)
Info: Creating a new SSL key for ubuntu.homenet.telecomitalia.it
Info: csr_attributes file loading from /etc/puppet/csr_attributes.yaml
Info: Creating a new SSL certificate request for ubuntu.homenet.telecomitalia.it
dove hostname è il nome del server a cui il client desidera collegarsi. Questo coincide con
uno dei nomi del server assegnati dal Domain Name System (DNS) [4], tra cui compare
anche quello associato al proprio certificato. In questo caso tale informazione può essere
omessa in quanto è presente un unico server.
Così l’agent Puppet trova il master Puppet e gli invia la richiesta di certificazione, ma poi si
interrompe perché non ancora autorizzato ad accedere alle configurazioni salvate sul server.
In particolare, si può configurare il master in modo tale da convalidare in automatico,
tramite il meccanismo dell’autosign, il certificato richiesto dall’agent, modificando il file
/etc/puppet/puppet.conf :
[master]
autosign=true
19
Dalla CLI del server si leggerà così:
Notice: ubuntu.homenet.telecomitalia.it has a waiting certificate request
Info: Autosigning ubuntu.homenet.telecomitalia.it
Notice: Signed certificate request for ubuntu.homenet.telecomitalia.it
Notice:
Removing
file
Puppet::SSL::CertificateRequest
ubuntu.homenet.telecomitalia.it
at
'/var/lib/puppet/ssl/ca/requests/ubuntu.homenet.telecomitalia.it.pem'
Intanto il client riceverà la convalida e avvierà il processo puppet:
Info: Certificate Request fingerprint (SHA256):
Info: Caching certificate for ubuntu.homenet.telecomitalia.it
Notice: Starting Puppet client version 3.6.1
11. Creare uno script puppetmaster nella directory /etc/init.d del master per la gestione
del corrispondente processo:
#!/usr/bin/env ruby
module PuppetMaster
def self.puppetmaster_cmd
'puppet master --mkusers --verbose --no-daemonize'
end
def self.start
puts "Starting Puppet Master in Verbose+NoDaemon mode"
puts "Started." if system("#{puppetmaster_cmd}")
end
def self.stop
puppet_master_ps = %x{ps aux | grep -e '#{puppetmaster_cmd}' | grep -v grep}
puppet_master_pid = puppet_master_ps.split[1]
20
if system("kill -9 #{puppet_master_pid}")
puts "PuppetMaster with pid:#{puppet_master_pid} has been killed."
else
puts "Failure killing PuppetMaster with pid:#{puppet_master_pid}."
end
end
def self.status
puppet_master_ps = %x{ps aux | grep -e '#{puppetmaster_cmd}' | grep -v grep}
puppet_master_pid = puppet_master_ps.split[1]
if puppet_master_pid.nil?
puts "No PuppetMaster found."
else
puts "Running @ #{puppet_master_ps}"
end
end
end
case ARGV.first
when 'start'
PuppetMaster.start
when 'stop'
PuppetMaster.stop
when 'restart'
PuppetMaster.stop
PuppetMaster.start
when 'status'
PuppetMaster.status
else
puts <<-PMUSAGE
$service puppetmaster (start|stop|restart|status)
PMUSAGE
end
end
end
end
21
case ARGV.first
when 'start'
PuppetMaster.start
when 'stop'
PuppetMaster.stop
when 'restart'
PuppetMaster.stop
PuppetMaster.start
when 'status'
PuppetMaster.status
else
puts <<-PMUSAGE
$service puppetmaster (start|stop|restart|status)
PMUSAGE
end
dove l’opzione no-daemonize indica che il processo non eseguirà in background ma sulla
shell saranno visibili le informazioni circa l’andamento dell’esecuzione.
12. Creare un modulo start.pp che, invocando il processo (puppetmaster) abilita
l’esecuzione automatica del servizio Puppet al boot del sistema :
service { 'puppetmaster':
enable => true }
13. Applicare la nuova impostazione digitando:
#puppet apply start.pp
22
14. Ripetere gli ultimi tre procedimenti per il client. In particolare, si può configurare
l’agent in modo tale che dopo un certo intervallo di tempo invia automaticamente al
server una richiesta di aggiornamento della propria configurazione tramite il
meccanismo del polling, modificando il file /etc/puppet/puppet.conf,
[agent]
runinterval=10
#dove 10 è l’attesa tra un messaggio di polling e un altro, espresso in secondi
dalla CLI del server si leggerà:
Info: Caching node for ubuntu.homenet.telecomitalia.it
Notice: Compiled catalog for ubuntu.homenet.telecomitalia.it in environment production in 0.01sec
(attesa di 10 secondi ...)
Info: Caching node for ubuntu.homenet.telecomitalia.it
Notice: Compiled catalog for ubuntu.homenet.telecomitalia.it in environment production in 0.02sec
Intanto il client riceverà il nuovo catalogo e applicherà la nuova configurazione:
Info: Retrieving pluginfacts
Info: Retrieving plugin
Info: Loading facts in /var/lib/puppet/lib/facter/gemhome.rb
Info: Caching catalog for ubuntu.homenet.telecomitalia.it
Info: Applying configuration version '1403110270'
Notice: Finished catalog run in 0.25 seconds
23
15. Stabilita la connessione tra i due host, è possibile inserire nuovi moduli di
configurazione nella directory /etc/puppet/modules del server; per esempio, si può
creare un nuovo folder hello, al cui interno creiamo altre due cartelle, manifests e
tests, e inseriamo nella prima directory il file init.pp che definisce la classe
principale del modulo :
class hello {
file { '/tmp/hello':
ensure => present,
content => "Per il momento ... tt ok!\n"
}
}
All’interno di questo .pp è stata definita una class chiamata “hello” al cui interno troviamo
una risorsa di tipo file che crea o sovrascrive, nel caso fosse già presente, nella directory
/tmp del client un file generico “hello” dal contenuto specificato alla riga successiva.
Se tentando di ri-eseguire il master (per esempio per aggiornare i moduli) compare il
seguente errore :
#Error: could not run: Could not create PID file: /var/run/puppet/master.pid
vuol dire che è già in esecuzione in background un’istanza del server precedentemente
sospesa. Riavviare il processo puppetmaster col seguente comando :
#service puppetmaster restart
24
16. Modificare il file site.pp del server (considerato il main manifest o il site manifest),
presente nella cartella /etc/puppet/manifests, per poter inviare queste nuove
informazioni a tutti gli agent connessi al master:
import "nodes"
import "templates"
include hello
Per comunicare, invece, tali informazioni solo a determinati client è possibile specificarlo
nel file nodes.pp in /etc/puppet/manifests/ del server in questo modo :
node base {
include hello
}
node “certname” inherits base { }
dove certname è il nome (equivalente all’hostname completo del nodo) associato al
certificato del client, modificabile nel proprio file puppet.conf sotto la sezione [agent].
Si noti che ogni risorsa che compare in questi file ha una serie di attributi e di valori da
impostare tramite la sintassi offerta dal linguaggio Ruby di Puppet. Ciascuna è infatti
definita da un tipo, un nome e un set di proprietà variabili.
Inoltre, poichè su ogni client può girare un sistema operativo piuttosto che un altro, in questi
moduli.pp è necessario modificare le risorse in base all’architettura e al tipo di client.
Per questo sono necessarie alcune informazioni di sistema che, come detto in precedenza,
sono rese disponibili dal facter.
25
Infatti, aggiungendo le seguenti righe di codice al site.pp del server, verrà installato il
package relativo al servizio apache in base al tipo di sistema operativo presente sul client :
case $::operatingsystem {
'CentOS': { $apache_pkg = 'httpd' }
'Redhat': { $apache_pkg = 'httpd' }
'Debian': { $apache_pkg = 'apache2' }
'Ubuntu': { $apache_pkg = 'apache2' }
default: { fail("Unrecognized operating system") }
}
package { $apache_pkg : #dove $apche_pkg definisce una variabile per il tipo di s.o. dell’host
ensure => present,
}
17. Configurare, infine, l’agent in modo tale da inviare reports al server alla fine di
ciascun processo di configurazione :
[agent]
report=true
Questi rapporti, in particolare, sono salvati nella directory /var/lib/puppet/reports del
master e contengono :
-
messaggi di log generati durante l’esecuzione di una determinata configurazione
-
informazioni su time, resources e changes che descrivono quello che è successso
nella transazione.
26
2.1.3 Puppet Enterprise Console (PE Console)
Utilizzando la macchina virtuale offerta dal sito della Puppet Labs, è possibile configurare la
VM come webserver per ospitare una pagina html caricabile dal browser.
1. Scaricare e installare il package apache dalla Puppet Forge tramite il seguente
comando :
puppet module install puppetlabs-apache
2. Creare una classe dedicata al caricamento della pagina web desiderata nella directory
/etc/puppetlabs/puppet/modules/exhtml/manifests:
class exhtml (
$document_root = '/var/www/html/exhtml',
$port = '80', #porta del servizio web (di default)
){
class { 'apache':
default_vhost => false,
#viene settato il servizio apache diverso da quello di default
}
apache::vhost { 'learning.puppetlabs.vm':
#viene settato il web server nel modo desiderato
port => $port,
docroot => $document_root,
}
file { '/var/www/html/exhtml': #ci si assicura che la directory della webpage esista e contenga i
file specificati da source
ensure => directory,
owner => $::apache::params::user,
group => $::apache::params::group,
source => 'puppet:///modules/exhtml/html',
recurse => true,
require => Class['apache'],
}}
27
3. Digitare ifconfig da terminale per conoscere l’IP della VM su cui è in esecuzione la
PE Console.
4. Aprire il browser e digitare https://<ip-address>, dove <ip-address> è l’indirizzo IP
appena conosciuto. Se, invece, gli è stato associato un hostname pubblico, si può
accedere alla console digitando il nome al posto dell’IP. Si aprirà una schermata di
login in cui inserire [email protected] come username e learningpuppet come
password.
Effettuato il login, compare la schermata principale dei nodi da gestire: in questo caso è
presente solo learn.localdomain, cioè quello relativo alla VM che, in quanto configurata
come server master, è in grado di funzionare anche da client agent.
5. Aggiungere
configurazione
alle
classi
di
quella
relativa
al
modulo exhtml di interesse, cliccando
su Add classes presente in basso a
sinistra.
Qui vengono raccolti tutti i moduli che possono
essere aggiunti, in un secondo momento, alla
configurazione di uno o più nodi desiderati.
28
6. Nella sezione Nodes cliccare su learn.localdomain,
e poi su Edit in alto a destra.
7. Effettuare il classifying del
nodo
in
questione,
aggiungendo la classe exhtml
definita al punto 2.
8. Salvare le nuove impostazioni e cliccare sulla sezione Live Management, dove è
possibile gestire l’esecuzione del processo puppet del client.
9. Cliccare su Control Puppet e poi su runonce per eseguire nuovamente il processo.
10. Nella sezione Reports saranno elencate tutte le modifiche applicate al nodo.
29
Dopo aver applicato il catalogo, l’host sarà configurato come webserver per ospitare il sito
desiderato. Basta poi digitare nel browser http://<ip-addres> e il risultato sarà la seguente
pagina web:
30
Capitolo 3: Panoramica su Chef, Ansible e Salt
3.1 Chef
Chef è un altro strumento di gestione delle risorse e del software, rilasciato nel 2009, che
semplifica il compito di configurare e manutenere server e altri dispositivi appartenenti ad
un’organizzazione IT [5].
Chef è molto simile al Puppet; infatti, oltre nella modalità Chef-solo (Standalone), può essere
eseguito anche in quella Server/Client (Master/Agent) in cui il server master conserva tutte le
“ricette” per le configurazioni da inviare ai client in collegamento. In realtà, oltre ad un server
master, è richiesta anche una workstation dedicata per controllarlo. Per esempio, grazie al
comando knife –ssh (analogo di puppet), dalla Security Shell (SSH) della workstation è
possibile installare facilmente i software agent sui nodi e successivamente questi saranno in
grado di comunicare con il master attraverso l’uso di certificati.
Inoltre, non fornendo la funzione push al server, i client dovranno contattarlo periodicamente
per essere aggiornati sulle possibili modifiche di configurazione. Come Puppet, anche il
linguaggio di Chef è basato su Ruby e l’interfaccia utente, malgrado non sia altrettanto
completa, consente il controllo delle informazioni di stato di ciascun nodo gestito.
31
3.2 Ansible
Ansible, invece, è stato rilasciato nel 2012 dalla AnsibleWorks ed è basato su Python [6].
A differenza dei precedenti, esso fornisce un approccio meno complesso e una gestione più
snella e veloce, pur garantendo le stesse funzionalità degli altri tools.
Non è richiesta l’installazione del software agent sui nodi; quindi, con comandi semplici e
intuitivi, Ansible esegue tutte le funzioni tramite SSH, da cui è possibile trasferire (pushing)
agli hosts direttamente gli script Python oppure scrivere moduli specifici da eseguire.
Ad ogni nodo saranno associate le chiavi di accesso alla comunicazione da stabilire col server
Ansible che sarà in grado, così, di eseguire tutte le operazioni richieste sui nodi in
collegamento. Inoltre i file di configurazione possono essere memorizzati in un apposito
sistema di controllo centralizzato.
Qualora la comunicazione avvenga con sistemi che non consentono di default l’accesso alla
SSH come root, Ansible accetta credenziali di tipo sudo per eseguire comandi e operazioni su
tali sistemi. Per operazioni semplici, come ad esempio verificare che un servizio sul sistema è
in esecuzione o innescare aggiornamenti del sistema e riavvii dello stesso, lo scambio di
informazioni tra hosts avviene senza l’utilizzo di particolari file di configurazione. Per
operazioni più complesse, invece, vengono usati file di configurazione, chiamati playbooks,
scritti in linguaggio YAML (basato su Python) che contengono tutta una serie di attività da
eseguire per impostare lo stato desiderato delle istanze. In realtà, i comandi e le istruzioni
possono essere scritti in qualsiasi altro linguaggio di programmazione e poi distribuiti come
moduli JSON universali. Inoltre, all’interno di una inventory list sono presenti le informazioni
di tutti gli hosts da gestire e ciascun utente, a tal proposito, deve essere in grado di realizzare
un proprio inventario (statico o dinamico).
Per quanto riguarda l’interfaccia utente, Ansible non offre ancora una GUI completa e
sincronizzata con la CLI. E’ comunque possibile utilizzarle entrambe o in alcuni casi soltanto
la seconda.
32
I moduli di gestione Ansible racchiudono sia l’azione che le variabili necessarie al
completamento dell’operazione su una determinata risorsa. In generale, le azioni sono attivate
attraverso una state variable settata come present o absent a seconda se sia presente o meno
quella risorsa sull’istanza correntemente gestita.
Infine, i moduli si definiscono idempotent, nel senso che cercano di evitare modifiche al
sistema a meno che non debba essere fatto qualche aggiornamento specifico. Esso, infatti, è
un meccanismo essenziale per favorire un approccio iterativo con cui aggiornare un playbook
e riapplicarlo in modo che vengano effettuate le giuste modifiche in esso specificate,
assicurando così al sistema di raggiungere correttamente lo stato desiderato.
3.3 Salt
Salt è stato rilasciato nel 2011 dalla Salt Stack ed è molto simile ad Ansible in quanto si tratta
di uno strumento basato su CLI e che fornisce un metodo push per la comunicazione clientserver [7]. In particolare, qui i client sono chiamati minions (ovvero servi) e passano sotto il
controllo di un server master solo dopo averlo richiesto esplicitamente. La comunicazione è
abbastanza semplice in quanto avviene attraverso la SSH ma è resa più veloce grazie all’uso
di un file server asincrono che, appunto, velocizza il file serving con i client.
Salt può essere eseguito nelle due modalità Standalone o Master/Agent: la prima è spesso
usata per piccole infrastrutture o per testare le modifiche di configurazione in un sistema
isolato, prima di procedere con la modalità Master/Agent; secondo quest’ultima, invece, il
minion (servitore) riceverà la propria configurazione tramite file, chiamati SLS (Salt States),
raccolti, compilati e successivamente inviategli dal master.
33
Come Ansible, per le operazioni più semplici si possono scrivere e inviare comandi ai
minions dalla CLI oppure usare gli states (analoghi ai playbooks di Ansible), scritti anch’essi
in YAML, per gestire operazioni più complesse. Esistono, inoltre, anche dei pillars
(letteralmente pilastri) in cui sono salvati set di dati a cui gli states possono accedere durante
l’esecuzione.
Inoltre, Salt prevede l’installazione di un comando chiamato salt-cloud per la gestione delle
istanze sul public cloud attraverso un sistema di profili. Un profilo, più precisamente, è una
collezione di impostazioni riguardanti, ad esempio, la location e la machine type di ciascuna
istanza. Questo comando fornisce anche funzionalità per eliminare istanze e per realizzare
information query. Per quanto riguarda l’interfaccia utente, la Web UI di Salt è più nuova ma
non completa come quella di altri sistemi. Poiché è in fase di miglioramento, attualmente
offre la possibilità di tracciare file di log degli eventi, di seguire lo stato corrente dei nodi
gestiti e di inviare loro semplici comandi.
Una caratteristica di Salt, che lo accomuna a Puppet, è la possibilità di disporre più server
master su più livelli, distribuendo così il carico totale delle richieste dei client ma, allo stesso
tempo, rischiando di aumentare la ridondanza dei dati. Infine, grazie al sistema di peering, i
masters, dopo aver ricevuto richieste dai minions, possono a loro volta delegare le risposte ad
altri masters. Per esempio, questo meccanismo risulta efficace quando deve essere analizzato
in tempo reale un database per il recupero di dati utili al completamento di una
configurazione per un client.
34
Conclusioni
In questo elaborato sono stati discussi gli aspetti critici che caratterizzano il movimento
DevOps e sono stati presentati Chef, Puppet, Salt e Ansible come i software management
tools oggi più diffusi e ancora in via di sviluppo.
In particolare, è stata focalizzata l’attenzione sul tool della Puppet Labs, spiegando le
caratteristiche fondamentali del modello Master/Agent implementato con due sistemi
Ubuntu in comunicazione. E’ possibile raggiungere le stesse conclusioni anche con sistemi
operativi differenti ma che siano supportati dal software Puppet.
Per una conoscenza più approfondita e per un utilizzo a livello professionale è consigliato
acquistare la versione commerciale completa del software, avendo così la possibilità di
usufruire di molti più servizi, come il provisioning di Amazon Elastic Compute Cloud
(Amazon EC2) [8] e Google Compute Engine VMs, per gestire sistemi non solo a livello
locale ma in tutta la rete pubblica mondiale. A tal proposito, nelle pagine seguenti vengono
riportate le immagini relative all’acquisto di un’istanza server virtuale di prova
dell’Amazon Cloud Computing Web Services e al corrispondente accesso effettuato sulla
stessa Learning VM utilizzata in precedenza. Le fasi successive riguarderanno la
configurazione dell’istanza come master o agent Puppet al fine di comunicare in modo
automatico con hosts Puppet sparsi in tutto il mondo.
35
Figura 5: Creazione dell’istanza server Amazon EC2. Sono illustrate tutte le informazioni specifiche dell’istanza
acquistata; in particolare si tiene presente il Public DNS (associato al Public IP) con cui è possibile stabilire
connessioni con altri hosts della rete.
36
Figura 6: Connessione remota col server EC2 effettuata dalla Learning VM. E’ stato effettuato il login sul
server di Amazon attraverso il terminale della virtual machine a disposizione. A tal proposito, è stato necessario
salvare il file .pem relativo alla chiave di accesso impostata al momento della creazione dell’istanza in questione.
C
o
m
e
Figura 7: Installazione del software Puppet Enterprise 3.2.3 sul server Amazon EC2.
37
Bibliografia
[1] What is Puppet?, http://puppetlabs.com/puppet/what-is-puppet, 11 Giugno 2014
[2] What is DevOps?, http://devops.com/category/features/, 16 Giugno 2014
[3]
Try Puppet Enterprise, http://puppetlabs.com/download-puppet-enterprise#pe-form-
instructions, 22 Giugno 2014
[4] James F. Kurose, Keith W. Ross, Reti di Calcolatori e Internet: Un approccio top-down,
Pearson Addison Wesley, IV edizione
[5] Chef, http://www.getchef.com/chef/, 23 Giugno 2014
[6]
Ansible, http://www.ansible.com/home, 23 Giugno 2014
[7] SaltStack, http://www.saltstack.com/, 23 Giugno 2014
[8] What is Amazon EC2?,
http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/concepts.html, 25 Giugno 2014
38

Download Report