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 '/var/lib/puppet/ssl/ca/requests/puppetmaster.example.com.pem' Notice: Removing file Puppet::SSL::CertificateRequest puppetmaster.example.com at '/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