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
© Copyright 2024 Paperzz