Scuola Politecnica e delle Scienze di Base Corso di Laurea in Ingegneria Informatica Elaborato finale in Reti di Calcolatori Linguaggi e piattaforme per la automazione dei processi di configuration management: Ansible a.a. 2013/2014 Candidato: Adriano Castaldi matr. N46000741 A mia madre, che non mi lascia mai solo. Indice Indice..................................................................................................................................................III Introduzione..........................................................................................................................................4 Capitolo 1: DevOps come modello di sviluppo...................................................................................6 1.1 Storia ed evoluzione...................................................................................................................6 1.2 Il ruolo del professionista DevOps.............................................................................................8 1.3 Tools basati su metodologia DevOps.........................................................................................8 1.3.1 Amazon Machine Engine....................................................................................................8 1.3.2 Chef.....................................................................................................................................9 1.3.3 Puppet..................................................................................................................................9 1.3.4 Salt.....................................................................................................................................10 1.3.5 Ansible...............................................................................................................................10 1.4 DevOps nel mondo del networking..........................................................................................10 1.5 Data Center e Virual Networking con DevOps: il caso Paypal/Ebay......................................12 Capitolo 2: La piattaforma Ansible....................................................................................................14 2.1 Cos'è Ansible............................................................................................................................14 2.2 Il livello trasporto nella comunicazione Ansible: il protocollo SSH........................................14 2.2.1 Autenticazione SSH..........................................................................................................16 2.2.2 Connessione SSH..............................................................................................................16 2.3 Il livello applicativo nella comunicazione Ansible: i tools OpenSSH.....................................17 2.4 Configurazione di Ansible: i Playbooks...................................................................................17 2.5 La sintassi YAML....................................................................................................................19 Capitolo 3: Caso d'uso di Ansible......................................................................................................21 3.1 Installazione di un server LAMP con Ansible.........................................................................21 3.1.1 Installazione dei componenti............................................................................................21 3.1.2 Suddivisione in ruoli.........................................................................................................22 3.1.3 Installazione del database: la M di LAMP........................................................................23 Conclusioni.........................................................................................................................................27 Bibliografia.........................................................................................................................................28 Introduzione Lo scopo di questo elaborato è quello di fornire una panoramica sui linguaggi e le piattaforme utilizzati nei processi di configuration management, nonché sviluppare un approfondimento sulla piattaforma Ansible sufficiente a dimostrarne le potenzialità. La prima domanda che naturalmente ci si pone è: che cos'è il configuration management? La risposta più semplice che si possa dare è che il configuration management è un processo di sviluppo del software. Nello specifico, esso ha lo scopo di permettere la gestione ed il controllo degli oggetti di sistemi complessi quali sistemi software e sistemi ingegneristici. Tale gestione è basata sul database (base di dati) in cui sono censiti gli oggetti sottoposti a controllo di configurazione (i configuration items). In questo contesto va quindi considerato il discorso della collaborazione all'interno della specifica organizzazione che sviluppa un dato prodotto, diventa quindi critica la comunicazione, la condivisione e la sincronizzazione di tali oggetti tra i membri di un determinato team di sviluppo. Entrano quindi in gioco i linguaggi e le piattaforme per la gestione del configuration management che si basano dunque non solo sulle operazioni formali da fornire a tale scopo, ma anche sul rispetto di principi che consentono uno sviluppo del prodotto agile ed ottimizzato. Questi principi sono racchiusi e sviluppati in una filosofia di sviluppo promossa dall'organizzazione DevOps, quest'ultima è l'argomento principale del primo capitolo di questo elaborato. Sempre nel primo capitolo vengono poi passati in rassegna i software per la gestione del configuration management e ne vengono brevemente discussi i dettagli implementativi. Il secondo ed il terzo capitolo sono invece incentrati su una piattaforma in particolare, che è quindi argomento centrale di questo elaborato: Ansible. Ansible è una piattaforma nuova, lanciata nel 2013, che consente di avere una buona 4 flessibilità grazie all'integrazione con diversi servizi quali i cloud forniti da aziende come Amazon e Google. In particolare, nel secondo capitolo, vengono presentati i dettagli tecnici riguardanti la comunicazione tra i nodi Ansible, la gestione del livello trasporto tramite protocollo SSH e di quello applicativo mediante la suite OpenSSH. Nel terzo capitolo viene invece proposto un esempio di utilizzo pratico di Ansible e degli strumenti che esso mette a disposizione al fine di verificarne la semplicità di utilizzo e di modellazione. 5 Capitolo 1: DevOps come modello di sviluppo Il termine DevOps deriva dalla crasi tra i termini development e operations, con esso si indica una metodologia di sviluppo software atta alla cooperazione tra i vari sviluppatori di software all'interno di uno stesso progetto e, più in generale, tra operatori del settore IT. Lo scopo generale è quindi quello di semplificare il rilascio del software assicurando rapidità nel raggiungimento dell'obiettivo finale ed efficienza dello stesso. I maggiori benefici sono ottenuti da quelle organizzazioni che fanno del rilascio frequente di aggiornamenti la propria caratteristica, ne è un esempio Flickr (sito web per la condivisione di foto) che ha sfruttato proprio tecniche DevOps per far fronte alla necessità di 10 rilasci giornalieri. Il numero di rilasci può essere anche molto superiore al caso sopra citato, esistono infatti aziende che attuano metodi come il deployment continuo o il Lean Startup che ben si associano al metodo DevOps, questi ultimi due esulano però dagli scopi di questo elaborato. Scendendo maggiormente in dettaglio, la metodologia DevOps ha come obiettivo non solo il rilascio finale del prodotto, ma anche il suo mantenimento (attraverso bug fixing e minor release) e l'evoluzione, quest'ultima in particolare viene assicurata mediante una stretta collaborazione con il cliente (metodologia agile di sviluppo). 1.1 Storia ed evoluzione Il termine “DevOps” venne coniato da Patrick Debois e si è poi diffuso grazie ad eventi denominati “Devops Days”, di cui il primo nel 2009 in Belgio. In molte organizzazioni, lo sviluppo del software e la gestione dei sistemi sono in divisioni differenti e poiché lo sviluppo è generalmente guidato dalle necessità dell'utente, per continue modifiche e conseguenti rilasci, i gruppi operativi sono concentrati sulla disponibilità e affidabilità dei servizi, nonché sulla gestione dei costi. Ciò produce un 6 "gap" tra sviluppo e gestione dei servizi che rallenta il passaggio in produzione. Questo avviene perché le metodologie di sviluppo che vengono attuate in azienda tra distinte divisioni (IT, QA, sviluppo e rilascio) non forniscono direttive per una stretta collaborazione tra i reparti. La metodologia DevOps, invece, propone una serie di processi e metodi per la comunicazione e la cooperazione tra le divisioni. L'adozione della metodologia DevOps è guidata da diversi fattori, quali: 1. Utilizzo della metodologia agile e altre metodologie di sviluppo del software 2. Necessità di incrementare la frequenza dei rilasci in produzione 3. Ampia disponibilità di un'infrastruttura virtualizzata e in cloud 4. Incremento nell'uso di data center automatizzati e strumenti di configuration management I benefici derivati dall'utilizzo delle DevOps, fondamentali se si pensa alla criticità della fase di rilascio, sono i seguenti: Numero ridotto di modifiche L'adozione del modello agile o modello incrementale, in contrasto con il tradizionale modello a cascata, comporta minori modifiche, anche se più frequenti, con minore impatto e rischio. Accresciuto coordinamento dei rilasci La presenza di un coordinazione del rilascio riduce le distanze tra reparto di 7 sviluppo e reparto di gestione. Automazione Una completa automazione assicura la facile ripetibilità dei rilasci e riduce gli errori nell'operazione. 1.2 il ruolo del professionista DevOps Per quanto scritto in precedenza, è chiaro che, nelle organizzazioni che utilizzano tale metodologia, il professionista DevOps, identificato anche come “coordinatore del rilascio”, è centrale nella produzione del software. Le sue mansioni ricordano quelle del capo ingegnere del “Toyota Production System”, in sostanza quindi non ha poteri reali sulle singole divisioni ma le coordina e ne è responsabile dei risultati. A tale figura è richiesta una conoscenza tecnica profonda al fine di individuare quelle che sono le necessità nella fase di test. E' un ruolo relativamente nuovo nel mondo aziendale e si rende necessario al fine di avvicinare i team di sviluppo del progetto e di gestione, organizzare la produzione di infrastutture complesse (ad esempio quelle multipiattaforma), incrementare i rilasci e coordinare gruppi localizzati in zone geografiche diverse (diverse sedi dell'azienda, utilizzo di strutture esterne, ecc.). 1.3 Tools basati su metodologia DevOps Vengono di seguito passati brevemente in rassegna alcuni dei servizi basati sulla metodologia DevOps. 1.3.1 Amazon Machine Image Amazon Machine Image (AMI) è un dispositivo virtuale utilizzato per instanziare una macchina virtuale all'interno di Amazon Elastic Compute Cloud (EC2), ovvero il servizio di cloud computing fornito da Amazon. 8 Il cuore di AMI è composto da un'immagine di un file system (in modalità read only) che fornisce un sistema operativo (basato su Red Hat Linux) e gli applicativi necessari alla corretta esecuzione di EC2. 1.3.2 Chef Chef è uno strumento di configuration management scritto in Ruby e Erlang. La scrittura dei recipies di configurazione del sistema sono scritti interamente in Ruby, attraverso questi recipies è possibile gestire e configurare server application (come Apache o MySQL). Chef viene utilizzato per semplificare i compiti di configurazione e mantenimento dei server di una società. Si presta bene all'integrazione con servizi cloud come Amazon EC2, Google Cloud Platform e Microsoft Azure. 1.3.3 Puppet Puppet è un tool open source per il configuration management creato con lo scopo di fornire un servizio cross-platform . 9 Puppet viene utilizzato principalmente su sistemi Unix-like, dove fornisce prestazioni superiori rispetto ai sistemi Windows. Nonostante fornisca un proprio linguaggio per la definizione della configurazione di sistema, attraverso il Puppet Manifest l'utente può scegliere di utilizzare anche Ruby. Tra le società che hanno scelto Puppet per fornire i propri servizi troviamo Mozilla, Twitter, Paypal, Oracle e Google, oltre ad alcune istituzioni universitarie. 1.3.4 Salt E' open source e trova la sua particolarità nella forte modularità e nell'estensibilità. I moduli sono scritti in Python e consentono, all'interno di un sistema basato su Salt, la separazione e la modifica di singole interazioni a seconda delle necessità. 1.3.5 Ansible Ansible è una piattaforma open source per la configurazione ed la gestione dei sistemi, combina operazioni di sviluppo con l'utilizzo di task ad-hoc ed il configuration management. Fornisce un proprio linguaggio per la descrizione dei sistemi denominato YAML. La trattazione della piattaforma Ansible è parte integrante del secondo capitolo di questo elaborato. 1.4 DevOps nel mondo del networking Come tutte le novità, anche la metodologia DevOps ha attirato le attenzioni degli esperti del proprio settore raccogliendo diversi pareri positivi e qualche incertezza. Nell'Ottobre del 2011 Stacey Higginbotham, su www.gigaom.com, famoso sito di news e divulgazione su argomenti di networking, firma un articolo dal titolo “Does networking needs a DevOps movement?” [2]. Più riflessivo è invece Nick Lippis che nel suo recente articolo su www.sdncentral.com [1] 10 apre con questa frase “DevOps is the latest in a long line of confusing tech industry buzzwords, one that’s shrouded in a mix of mystery, controversy and indeed apathy”, ovvero “DevOps è l'ultimo di una lunga lista di termini confusionari utilizzati dall'industria tecnologica, rappresenta un miscuglio di mistero, controversie e apatia”. Lippis spiega come segue le tre definizioni che associa a DevOps nel suo articolo: Mistery giustificato da una statistica di Micheal A. Davis che dimostra che solo il 22% degli specialisti nel settore IT conosce l'argomento, mentre solo il 21% ne segue i principi (è facile pensare che siano gli stessi); Controversy Scrive: “Controversy arises when evangelists throw around the term “engineering,” [...] The problem here is that DevOps is more a philosophy and process than field of proscribed endeavor and can be applied to many different areas”. Ovvero “La controversia nasce quando si inizia a girare intorno al termine “ingegneria” […] Il problema è che DevOps è più una filosofia e può essere applicato a molti settori differenti” Apathy Collegata alle statistiche che riportano oltre il 58% delle organizzazioni totalmente all'oscuro del movimento e non intenzionate, almeno nel breve periodo, a dedicarsi a tale metodologia. Nonostante un incipit piuttosto critico e pessimista sulle possibilità di evoluzione della DevOps, Lippis prosegue riportando esperienze di professionisti del settore che esaltano tale metodologia, descrivendo come si siano semplificati rilasci ed aggiornamenti, nonché la stesura della documentazione, una volta adottata. In chiusura del suo articolo, Lippis sottolinea però come, al fine di attuare al meglio strategie basate su una “DevOps attitude”, si richieda un profondo cambiamento culturale dell'azienda attraverso la rivisitazione (o l'apprendimento) di pochi, ma importanti passi 11 per uno sviluppo ottimale del software: Astrazione del problema Automazione dei processi di rilascio e gestione Sviluppare la comunicazione tra le varie divisioni Imparare l'utilizzo di nuove piattaforme come Puppet, Chef o Ansible Conclude infine ricordando il libro di Fred Brooks “The Mythical Man Month” nel quale i principi DevOps sono parzialmente anticipati con una forte critica a quei processi aziendali che puntano su un alto numero di dipendenti e su ritmi di lavoro stressanti. Mike Kavis, nel Febbraio del 2014, aveva in realtà già sollevato alcune problematiche proposte da Lippis nella sua introduzione con l'articolo “No, you're not a DevOps Engineer” [3] nel quale, come da titolo, racconta il suo sconforto dinanzi a professionisti del settore IT che si autodefiniscono “esperti DevOps” pur non comprendendo esattamente cosa la metodologia DevOps proponga: “When I ask them where the development team is, they often say either “we did not invite them,” or even worse, “we don’t talk to them.” This is where I want to interject and say, “no, you are not a DevOps engineer.” ”. In definitiva, risulta chiaro che la metodologia DevOps, come tutte le innovazioni che portano con se una componente ideologica, comporti entusiasmo, quasi esaltazione in alcuni, e dubbi in altri. Risulta però altrettanto chiaro che le idee proposte non sono una novità ne leggi inviolabili, ma più semplicemente principi per un corretto sviluppo aziendale, dove con il termine “sviluppo” si vuole intendere non solo quello di un singolo progetto, ma dell'intera organizzazione in termini economici e sociali. 1.5 Data Center e Virual Networking con DevOps: il caso Paypal/Ebay Vinay Bannai e Igor Bolotin di Paypal/Ebay rappresentano uno straordinario esempio di utilizzo reale della metodologia DevOps. All'ultimo Open Networking Summit (ONS) sono intervenuti illustrando le necessità che avevano in termini di sviluppo e rilascio dei propri servizi. 12 Gli obiettivi prefissati erano i seguenti: Agilità di sviluppo – riducendo i tempi di rilascio e favorendo le innovazioni Creare efficienza – riduzione dei costi ed alta scalabilità per risorse “on demand” Disponibilità di infrastrutture Sicurezza e conformità Attualmente Paypal utilizza Puppet per lo sviluppo ed il CI/CD (Continuous Integration/Continuous Delivery), la piattaforma, basata su logiche DevOps, ha consentito alla società di proporre rilasci a distanza di pochi giorni l'uno dall'altro, mentre in passato gli stessi progetti richiedevano tempi nell'ordine di settimane. Vinay ha poi sottolineato l'esigenza di nuove architetture di rete legate a questa formula di sviluppo, giustificando tale affermazione alle seguenti osservazioni: Necessità di richiamare capacità di calcolo complesse – utilizzo quindi di tecnologie che ne consentano l'utilizzo a prescindere dai confini di rete Aumentando la sicurezza (e quindi la zona “sicura” ricoperta) si evitano reti isolate Non sono preferibili topologie rigide – sono le reti a doversi adattare allo sviluppo e non il contrario Scarsa diffusione dell'automazione delle reti – attualmente è richiesto ancora un largo intervento manuale da parte dei network administrator La loro rete è attualmente basata su due rack contenenti 96 server ciascuno ed utilizzano switch di livello 3 e router. Hanno inoltre introdotto un livello “di confine”, denominato “virtual switch layer” che fornisce ad ogni server 4 porte virtuali. Le due rack formano poi domini di livello 2 ed ogni server lancia un certo numero di virtual machine. Attraverso i virtual switch viene composta una overlay network grazie alla quale ogni virtual machine si connette alle altre senza necessità di ulteriori dispositivi per attuare il tunneling e senza necessità di stretti legami tra lo specifico data center e l'indirizzo fisico. 13 Capitolo 2: La piattaforma Ansible 2.1 Cos'è Ansible Dalla documentazione ufficiale [5]: “Ansible is an IT automation tool. It can configure systems, deploy software, and orchestrate more advanced IT tasks such as continuous deployments or zero downtime rolling updates”. Gli obiettivi di Ansible sono quelli di consentire una semplicità d'uso massima. La piattaforma si focalizza inoltre sulla sicurezza e l'affidabilità attraverso l'utilizzo del protocollo OpenSSH per il livello trasporto ed i relativi tools per il livello applicativo. Ansible offre inoltre un linguaggio dedicato, di facile comprensione, chiamato YAML, trattato nel seguito di questo elaborato. Sempre dalla documentazione ufficiale si legge: “We believe simplicity is relevant to all sizes of environments and design for busy users of all types”. E' chiaro quindi che Ansible è una di quelle piattaforme che seguono i principi promossi da DevOps. 2.2 Il livello trasporto della comunicazione Ansible: il protocollo SSH Lo scopo principale del livello di trasporto è quello di facilitare una comunicazione sicura tra due host al momento dell'autenticazione e subito dopo. Il livello di trasporto dello stack TCP/IP, ricerca tale scopo cifrando e decifrando i dati, 14 verificando che il server corrisponda alla macchina corretta per l'autenticazione e fornendo una protezione integrale di pacchetti di dati durante la comunicazione. Inoltre, grazie alla compressione dei dati, può aumentare la velocità di trasferimento delle informazioni. Quando un client contatta un server utilizzando un protocollo SSH, i due sistemi “costruiscono” il livello trasporto della comunicazione mediante la negoziazione dei seguenti parametri: Scambio delle chiavi Algoritmo della chiave pubblica Algoritmo della cifratura simmetrica Algoritmo per l'autenticazione del messaggio Algoritmo hash Durante lo scambio delle chiavi il server si identifica al client tramite una chiave host. Naturalmente, se questo client non ha mai comunicato con questo particolare server, non sarà in grado di riconoscere la chiave del server, il chè può rappresentare una limitazione nelle comunicazioni. OpenSSH supera questo problema autorizzando il client ad accettare la chiave host del server la prima volta che avviene una connessione SSH. Nelle connessioni successive, la chiave host del server può essere verificata con una versione salvata sul client, in modo che il client sia "sicuro" di comunicare con il server corretto. SSH è stato ideato per funzionare con quasi ogni tipo di algoritmo per le chiavi pubbliche o di formato in codice. Lo scambio iniziale delle chiavi genera due valori: un valore hash, usato per gli scambi e 15 un valore segreto condiviso. I due sistemi, successivamente, calcolano nuove chiavi e algoritmi per proteggere l'autenticazione e i dati futuri inviati tramite la connessione. 2.2.1 Autenticazione SSH Dopo aver costruito un tunnel sicuro per inviare le informazioni da un sistema all'altro, il server indica al client i diversi metodi di autenticazione supportati, come per esempio una firma privata codificata o la digitazione di una password. Il client poi tenta di autenticarsi al server tramite uno dei metodi supportati. Poiché i server possono essere configurati per autorizzare diversi tipi di autenticazione, questo metodo fornisce un buon controllo da entrambe le parti. Il server stabilisce i metodi di cifratura supportati e il client può scegliere l'ordine dei metodi di autenticazione da utilizzare. La maggior parte degli utenti che richiedono una shell sicura utilizzano una password per l'autenticazione. A differenza di altri schemi di autenticazione per la sicurezza, la password viene trasmessa al server in chiaro. Comunque, dal momento che l'intera password è cifrata quando si sposta sul livello di trasporto, può essere inviata in modo sicuro attraverso qualsiasi rete. 2.2.2 Connessione SSH Ad autenticazione avvenuta, vengono aperti dei canali multipli, ognuno dei quali gestisce la comunicazione per una diversa sessione del terminale. Sia i client e che i server possono creare un nuovo canale, assegnandogli un numero diverso ad ogni estremità. Quando una parte tenta di aprire un nuovo canale, viene inviato insieme alla richiesta il suo numero per il canale. Questa informazione viene memorizzata dall'altra parte e utilizzata per indirizzare una particolare comunicazione di servizio per il canale. In questo modo i diversi tipi di sessione non si disturbano a vicenda e i canali possono essere chiusi senza interrompere la connessione primaria SSH tra i due sistemi. I canali supportano inoltre il controllo del flusso, che gli consente di inviare e ricevere i dati ordinatamente. In questo modo i dati non sono inviati attraverso il canale finché l'host non riceve il messaggio che il canale è in grado di ricevere. 16 I canali sono particolarmente utili con X11 forwarding (per programmi grafici) e TCP/IP port forwarding. E' possibile configurare in modo diverso canali separati, forse per usare una dimensione del pacchetto massima differente oppure per trasferire un tipo particolare di dati. Ciò consente a SSH una gestione flessibile dei diversi tipi di connessioni, senza dover modificare l'infrastruttura fondamentale del protocollo. Il client e il server stabiliscono la configurazione di ogni canale entro la connessione SSH in modo automatico. 2.3 Il livello applicativo della comunicazione Ansible: i tools OpenSSH OpenSSH (Open Secure Shell) è un insieme di programmi che rendono disponibili sessioni crittografate di comunicazione in una rete di computer usando il protocollo SSH. OpenSSH è stato creato dal team di OpenBSD come alternativa al software originario SSH di Tatu Ylönen, che ora è distribuito con licenza proprietaria. Gli sviluppatori di OpenSSH dichiarano che il loro prodotto sia più sicuro dell'originale, sia per la loro politica di produrre codice pulito e controllato, sia per il fatto, a cui la parola Open nel nome si riferisce, che è rilasciata sotto la licenza open source BSD. Sebbene il codice sorgente dell'originale SSH sia disponibile, le varie restrizioni che sono imposte sul suo uso e distribuzione fanno di OpenSSH un progetto molto più attraente per molti sviluppatori software. OpenSSH è stato rilasciato la prima volta all'interno di OpenBSD 2.6. L'ultima versione, 5.9, è stata rilasciata il 6 settembre 2011. 2.4 Configurazione di Ansible: i Playbooks Ansible utilizza il linguaggio YAML per la configurazione e l'amministrazione dei vari task. I Playbooks sono file sorgente che contengono le istruzioni YAML, attraverso quest'ultimi è quindi possibile gestire gli host remoti con semplici strutture o un intero processo di 17 sviluppo, attraverso una sintassi più complessa. Ogni Playbook è composto di una lista di “play” i quali si occupano di assegnare agli host remoti dei ruoli, raggruppando anche più host in un unico ruolo se necessario. Ogni ruolo esegue dei task dedicati, in sostanza questi task non fanno altro che richiamare dei moduli che Ansible mette a disposizione per le varie operazioni di configuration management. I moduli forniscono quindi una serie di operazioni di base (controllo remoto di file, pacchetti e opzioni), gli sviluppatori possono inoltre creare i propri moduli per lo svolgimento di specifiche operazioni. Il linguaggio YAML non intende essere un vero e proprio linguaggio di programmazione, ma piuttosto uno strumento per la modellazione dei play contenuti nei playbooks. Un semplice esempio di playbook, contenente un unico play, è riportato nella seguente immagine: La prima parte indica i target del play, ovvero gli host che dovranno essere interpellati per lo svolgimento dei task. Nell'immagine è presente un unico host, ma possono esserne indicati diversi. I task vengono eseguiti in successione, uno dopo l'altro, da tutti gli host indicati nella 18 prima parte del testo. Se un host fallisce un task, terminerà la sua esecuzione del playbook. I moduli, richiamati nei task sono idempotenti, ciò vuol dire che, una volta richiamati, effettueranno solo i cambiamenti necessari, ovvero quelli non eseguiti in un esecuzione precedente. In questo modo si assicura una certa sicurezza del sistema e una buona salvaguardia dei dati. Ad ogni task va assegnato un nome, al suo interno vengono dichiarati i moduli e per ogni modulo viene seguita una sintassi del tipo keyword=value. La figura seguente chiarifica quanto sopra riportato. L'ultima parte del playbook riportato nell'esempio è dedicata agli handlers, attraverso quest'ultimi il playbook riconosce cambiamenti del sistemi ai quali deve rispondere in qualche modo. Nello specifico osserviamo 2.5 La sintassi YAML Come già indicato nel precedente paragrafo, YAML non si pone come un vero e proprio linguaggio di programmazione, ma solo come un linguaggio di modellazione per facilitare la scrittura dei playbooks. La scelta di Ansible di utilizzare un linguaggio ad hoc è dovuta alla semplicità del linguaggio stesso, esso è infatti progettato per essere facile da leggere e scrivere soprattutto rispetto ad altri linguaggi utilizzati nelle piattaforme DevOps come JSON o XML. 19 Cosi come già fatto per il paragrafo riguardante i playbooks, viene di seguito riportato un esempio completo di sintassi YAML, successivamente discusso. Le tre righe iniziali indicano l'inizio del documento YAML. In seguito osserviamo una semplice sintassi del tipo “keyword: value” nella quale vengono inseriti i dati di un ipotetico dipendente. La keyword “foods” è invece seguita da una lista di elementi, posta su un livello di indentazione successivo. 20 Capitolo 3: Caso d'uso di Ansible 3.1 Installazione di un server LAMP con Ansible In questo paragrafo viene riportato un semplice esempio di installazione di un server LAMP con l'utilizzo di playbooks Ansible. LAMP è un acronimo che indica una piattaforma per lo sviluppo di applicazioni web, il nome nasce dalle iniziali dei quattro componenti sui quali esso si basa: Linux, Apache web server, il database server (MySQL/MariaDB) ed il linguaggio di scripting (Perl/Python/PHP). Per questo esempio applicativo è stato scelto MariaDB per la gestione del database e PHP per lo scripting. 3.1.1 Installazione dei componenti Il primo playbook contiene le istruzioni necessarie ad installare i componenti del server LAMP: il quarto task riguarda un semplice script in PHP, il file index.php viene creato con la 21 seguente riga nella shell Linux: Il risultato dell'esecuzione del playbook è il seguente: E collegandosi alla pagina http://10.0.0.10/index.php è possibile visualizzare il proprio “Hello World”. 3.1.2 Suddivisione in ruoli A questo punto abbiamo un web server attivo, necessitiamo quindi dell'installazione del DB server. L'idea di base potrebbe essere quella di installarlo sulla stessa macchina di Apache, il che andrebbe bene per un progetto dimostrativo come questo, ma ponendoci nell'ottica di un'azienda che deve sviluppare software è probabile che il database risieda su un server diverso. Nasce quindi l'esigenza di creare una distinzione di ruoli all'interno del progetto, distinzione che Ansible, come spiegato nel capitolo 2, offre come possibilità. 22 Per ora possiamo semplicemente creare una struttura di questo tipo: ed ottenere il risultato precedente con il playbook 3.1.3 Installazione del database: la M di LAMP A questo punto manca solo l'installazione del database del nostro server LAMP, la miglior cosa da fare è procedere in sei diversi passi: 1. Installare MariaDB 2. Avviare MariaDB 3. Creare il database 4. Aggiungere un utente al database 5. Importare il database 6. Installare un estensione MySQL per l'utilizzo di PHP E' chiaro che va anche aggiornata la struttura dei ruoli, precedentemente creata, introducendo quindi un ruolo per il database server, distinto da quello del web server Apache. La struttura cosi pensata risulta essere la seguente: 23 A questo punto possiamo aggiungere i task necessari al main.yml del ruolo “database”: 24 In questo modo, con i primi 3 tasks, installiamo il database, mentre con i restanti arriviamo al punto 4 della lista precedentemente stilata. Resta quindi da rendere operativo il database importando una struttura di base (una tabella). Vanno quindi aggiunti ulteriori tasks al playbook precedente: A questo punto è tutto pronto per la copia dell' “Hello World” scritto in php sul database. Osserviamo che nello specifico il file dump.sql (task 5) è creato come segue: E la seguente query fa il resto: 25 Basterà quindi far ripartire il playbook con il comando: E nuovamente, all'indirizzo http://10.0.0.10/db.php comparirà “Hello World”, ma stavolta fatto attraverso un database. 26 Conclusioni Quanto riportato in questo elaborato mette in evidenza la necessità e l'importanza di un'adeguata struttura organizzativa all'interno di un organismo aziendale o istituzionale. DevOps offre una via semplice ed immediata per arrivare a tale scopo, non solo attraverso dei principi basilari che cerca di divulgare ma anche attraverso piattaforme che sono predisposte ad un utilizzo che favorisca la metodologia agile di sviluppo. D'altronde tali norme vengono mostrate in ambiente universitario già agli studenti. Nei corsi che toccano argomenti come lo sviluppo software, il ciclo di vita di quest'ultimo, la cooperazione in team e la suddivisione delle mansioni, ogni docente preme sull'importanza di una comunicazione all'interno del team di progetto, di un'approfondita analisi del problema e di una suddivisione equa e bilanciata del carico di lavoro nonché sulla necessità di continui confronti al fine di testare al meglio le applicazioni sviluppate. Ansible, in quanto argomento prevalente dello scritto, è stato chiaramente messo in evidenza rispetto alle altre piattaforme, di cui si fornisce un cenno nel primo capitolo, ma il caso d'uso riportato nel terzo capitolo rappresenta comunque una dimostrazione della filosofia che questa categoria di prodotti cerca di promuovere: facilità di creazione, di modifica, di aggiornamento e di realizzazione del progetto nel suo complesso, nonché semplicità di condivisione. 27 Bibliografia [1] www.sdncentral.com, http://www.sdncentral.com/education/devops-thinking-like- programmer-can-make-better-network-manager/2014/05/ ,15/07/2014 [2] www.gigaom.com, http://gigaom.com/2011/10/21/does-networking-need-a-devops- movement/ ,15/07/2014 [3] www.virtualizationpractice.com, http://www.virtualizationpractice.com/devops- engineer-25120/ ,22/07/2014 [4] www.opennetsummit.org, http://www.opennetsummit.org/blog/2014/03/03/devopsopenstacksdn-real-world-perspective/ ,22/07/2014 [5] www.ansible.com, http://docs.ansible.com/index.html ,10/08/2014 [6] www.redhat.com, http://archive.download.redhat.com/pub/redhat/linux/7.1/de/doc/RHDOCS/it/rhl-rg-it-7.1/s1-ssh-protocol.html ,13/08/2014 [7] http://labs.qandidate.com/, http://labs.qandidate.com/blog/2013/11/21/installing-a- lamp-server-with-ansible-playbooks-and-roles/ ,25/09/2014 [8] www.wikipedia.com, http://it.wikipedia.org/wiki/Gestione_della_configurazione , 29/09/2014 [9] www.wikipedia.com, http://en.wikipedia.org/wiki/Ansible_(software), 3/10/2014 [10]www.redhat.com,http://archive.download.redhat.com/pub/redhat/linux/7.1/de/doc/RHDOCS/it/rhl-rg-it-7.1/s1-ssh-protocol.html , 2/10/2014 [11] J. Kurose, K. Ross - Reti di calcolatori e Internet. Un approccio top-down, Pearson Addison-Wasley, 2008 28
© Copyright 2025 ExpyDoc
