devops | Tutti per Linux

DevOps

DevOps (da development + operations) è una metodologia di sviluppo del software che punta alla comunicazione, collaborazione e integrazione tra sviluppatori e addetti alle attivita’ di gestione dell’information technology (IT). DevOps vuole rispondere all’interdipendenza tra sviluppo software e IT operations, e punta ad aiutare le aziende a sviluppare in modo più rapido ed efficiente i loro prodotti e servizi software.

La complessità delle strutture e infrastrutture It ha alimentato negli ultimi anni conflitti inter-organizzativi impoverendo l’It service delivery. Situazione che non risulta però più sostenibile rispetto al contesto economico in cui operano le aziende ‘servite’ dall’It in cerca di maggior flessibilità, dinamicità e velocità di risposta, senza però perdere in qualità e sicurezza. Ecco perché sta crescendo ed evolvendo la metodologia DevOps che mira a migliorare l’It service management.

Le aziende che tipicamente potrebbero avere maggiori benefici da un orientamento DevOps sono quelle con rilasci di software frequenti. Flickr, ad esempio, ha utilizzato la metodologia DevOps per supportare la necessità di dieci rilasci al giornalieri; ma tali cicli di rilasci potrebbero essere anche più frequenti in aziende che producono applicazioni multi-focus o multi-funzione, spesso indicati come deployment continuo, e associato spesso alla metodologia Lean Startup.

La metodologia DevOps aiuta dunque le aziende nella gestione dei rilasci, standardizzando gli ambienti di sviluppo. Le aziende con problemi di automazione dei rilasci solitamente hanno già un processo automatico in essere ma lo vorrebbero più flessibile e controllabile, senza per questo dover agire da riga di comando per ottenere ciò. Idealmente tale automazione potrebbe essere utilizzata anche da risorse non operative (non appartenenti all’IT Operations) su ambienti non di produzione. In questo modo gli sviluppatori avrebbero a disposizione un maggiore controllo degli ambienti, dando all’infrastruttura una visione più incentrata sull’applicazione.

L’integrazione DevOps ha come obiettivo il rilascio del prodotto, il collaudo del software, l’evoluzione e il mantenimento (bug fixing e “minor release”) in modo tale da aumentare affidabilità e sicurezza e rendere più veloci i cicli di sviluppo e rilascio. Molte delle idee che costituiscono DevOps provengono dalla gestione di sistemi aziendali e dalla “Metodologia Agile“.

Il termine “devops” è stato coniato da Patrick Debois e reso popolare attraverso una serie di “DevOps Days” iniziati nel 2009 in Belgio. Da allora si sono svolte conferenze “DevOps Days” in India, USA, Brasile, Australia, Germania e Svezia.

Le metodologie di sviluppo (ad esempio la Metodologia Agile) che vengono attuate nelle organizzazioni tradizionali mediante distinte divisioni tra IT operations e QA da un lato, sviluppo e rilascio dall’altro, sono prive di una profonda integrazione interdipartimentale. DevOps promuove invece un’ insieme di processi e metodi indirizzati alla comunicazione e collaborazione tra le divisioni.

L’adozione della metodologia DevOps è guidata da diversi fattori, come:

Utilizzo della metodologia agile e altre metodologie di sviluppo del software
Necessità di incrementare la frequenza dei rilasci in produzione
Ampia disponibilità di un’infrastruttura virtualizzata e in cloud
Incremento nell’uso di data center automatizzati e strumenti di configuration management

La metodologia DevOps è cosi’ descrivibile come “una relazione più collaborativa e produttiva tra i gruppi di sviluppo e quelli di operation”. Ciò incrementa l’efficienza e riduce i rischi di frequenti modifiche in produzione.

Invece, 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 invece sono concentrati sulla disponibilità e affidabilità dei servizi, nonché sulla gestione dei costi. Ciò produce un “gap” tra sviluppo e gestione dei servizi che rallenta il passaggio in produzione.

Impatto sui rilasci applicativi
In molte aziende i rilasci applicativi sono eventi ad alto impatto e rischio, coinvolgendo più gruppi di lavoro. Con la metodologia DevOps tale rischio si riduce per i seguenti motivi:

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 una coordinazione del rilascio riduce le distanze tra sviluppo e gestione.
Automazione : Una completa automazione assicura la facile ripetibilità dei rilasci e riduce gli errori nell’operazione.

I processi chiave che caratterizzano le metodologie DevOps sono quindi:

Cloud e Virtualizzazione: la necessità di avere a disposizione servizi e strumenti che offrono una modalità veloce di verifica e gestione della complessità di un’applicazione. Esempi di tali strumenti sono le API di cloud provisioning quali Amazon EC2, o servizi SaaS quali New Relic e Loggly, che offrono capacità operazionali cloud, oppure strumenti di gestione della configurazione quali Chef, Puppet e Ansible.

Continuous Delivery (letteralmente consegna continua): significa miglioramento continuo, significa testing ad ogni modifica, significa costruire molti prototipi, e non andare avanti finché non si abbia la certezza che ciò che abbiamo finora sviluppato è stato verificato a livello di qualità e compatibilità, se non addirittura di user testing. Le attività prettamente ingegneristiche coinvolte per assicurare uno sviluppo caratterizzato da continuous delivery sono: controllo codice sorgente, versioning configuration, integrazione continua, testing di unità e testing integrato e deployment automatizzato.

Considerazione finale
Dietro questa cura maniacale dell’organizzazione e della fase di testing c’è l’idea che sia meglio affrontare nella realizzazione di un prodotto tanti piccoli cambiamenti continui causati dal dialogo tra sviluppatori e sistemisti, che non dover validare un’intera applicazione solo alla fine di un’intero ciclo di sviluppo, o peggio ancora offrire al cliente un prodotto di cui non abbiamo la minima certezza su bug e qualità del funzionamento. Quest’ultima pratica deleteria porta poi a sostenere costi di supporto al cliente e di assistenza che in passato hanno costituito la causa maggiore del collasso di aziende e business IT.

#Devops#MetodologiaAgile

Ansible e l’automazione IT

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

Che cos’e’ Ansible

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

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

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

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

Configuration Management in breve

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

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

Esempio:

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

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

Ansible, un po’ di storia

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

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

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

* Chef richiede anche la conoscenza del linguaggio Ruby

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

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

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

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

I vantaggi di Ansible

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

Curva di apprendimento bassa

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

Non sono richieste capacita’ di coding

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

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

Install Httpd
yum: name=httpd state=latest

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

Modulare e Open Source

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

Ansible, i concetti chiave

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

Ansible: l’inventario

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

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

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

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

Ansible ed i Tasks

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

Ansible e gli Handlers

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

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

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

Ansible ed i Playbook

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

Ansible ed i Moduli

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

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

#AnsibleConfigurationManagement