Ansible – automazione IT e Configuration Management (II parte)

Ansible + Vagrant Environment

Ansible + Vagrant Environment

 

 

 

 

 

 

Nel primo articolo “Ansible per l’automazione IT ed il Configuration Management” abbiamo descritto le caratteristiche principali di questo interessante prodotto per il Configuration Management. In questo secondo articolo descriveremo con degli esempi come utilizzare nel concreto Ansible.

Per preparare il nostro ambiente di lavoro sfrutteremo un’altro software, che rappresenta, anch’esso una delle grandi novita’ del Web degli ultimi mesi come Vagrant, di cui abbiamo parlato nell’articolo “Virtualizzazione e provisioning senza sforzo“.

configuriamoci l’ambiente Vagrant:

$ vagrant box add pre http://files.vagrantup.com/precise32.box
$ vagrant init precise32
$ vagrant up

a seguito dell’ultimo comando, vedremo dei messaggi come questi:

Bringing machine 'default' up with 'virtualbox' provider...
[default] Importing base box 'precise32'...
[default] Matching MAC address for NAT networking...
[default] Setting the name of the VM...
[default] Clearing any previously set forwarded ports...
[default] Clearing any previously set network interfaces...
[default] Preparing network interfaces based on configuration...
[default] Forwarding ports...
[default] -- 22 => 2222 (adapter 1)
[default] Booting VM...
[default] Waiting for machine to boot. This may take a few minutes...
[default] Machine booted and ready!
Guest Additions Version: 4.2.0
VirtualBox Version: 4.3
[default] Mounting shared folders...
[default] -- /vagrant

Vagrant ha quindi scaricato e creato per noi una macchina virtuale Ubuntu Precise (32bit). Scorrendo i messaggi ci sono due cose importanti da notare: la prima è che il traffico sulla porta 2222 del nostro pc locale sarà inoltrato alla porta 22 della macchina virtuale; la seconda è che l’utente “vagrant” sulla macchina remota può connettersi con la password “vagrant” ed ha già i privilegi per diventare root con sudo. Aggiorniamo quindi l’inventario delle macchine che decidete di coinvolgere modificando il file /etc/ansible/hosts

Dopo aver preso confidenza con Vagrant iniziamo la configurazione dell’ambiente per Ansible, iniziando ad usarlo per automatizzare i compiti di ogni giorno.

Configuriamo il file /etc/ansible/hosts tramite comando:

# sudo bash -c 'echo [web] >> /etc/ansible/hosts'
# sudo bash -c 'echo 127.0.0.1:2222 ansible_ssh_user=vagrant ansible_ssh_pass=vagrant >> /etc/ansible/hosts'

Verifichiamo che ansible sia in grado di leggere correttamente i parametri inseriti nel file hosts usando il seguente comando:

# ansible -m ping all
127.0.0.1 | success >> {
"changed": false,
"ping": "pong"
}

Ansible facts
come possiamo essere sicuri che la macchina a cui ci stiamo connettendo sia quella giusta ? Diamo un’occhiata ai “facts”, ovvero a tutte le informazioni che Ansible raccoglie…

# ansible web -m setup | less

otteniamo cosi’ una serie di dati in formato JSON tra cui notiamo che il nostro nuovo server ha come hostname ‘localhost’.
A titolo didattico scriveremo un playbook per installare un webserver nginx sul nuovo server.

Ora apriamo un editor per iniziare a scrivere il nostro playbook che si chiamera’ nginx.yml :

--- PLAYBOOK ottimizzato su Centos Linux
- name: installa NGINX e avvia il servizio
   remote_user: root
   sudo: yes
   hosts: web
   tasks:
   - name: installazione Nginx
     apt: pkg=nginx state=installed update_cache=true
     notify:
     - start nginx
   handlers:
     - name: start nginx
     service: name=nginx state=started

Come possiamo notare nel playbook abbiamo editato una lista di task, uno per ogni “step” del nostro compito.
Se stiamo usando virtualbox come hypervisor, dobbiamo aggiungere una riga al file (bastera’ solo decommentarla) di configurazione di vagrant perché attivi il forwarding della porta 80 della guest sulla porta 8080 del nostro pc.

(vedi https://docs.vagrantup.com/v2/networking/forwarded_ports.html)

config.vm.network "forwarded_port", guest: 80, host: 8080

e dare il comando per ricaricare la virtual machine con la nuova configurazione:

vagrant reload
[default] Attempting graceful shutdown of VM...
[default] Clearing any previously set forwarded ports...
[default] Clearing any previously set network interfaces...
[default] Preparing network interfaces based on configuration...
[default] Forwarding ports...
[default] -- 22 => 2222 (adapter 1)
[default] -- 80 => 8080 (adapter 1)
[default] Booting VM...
[default] Machine booted and ready!

Ora possiamo lanciare il playbook

# ansible-playbook nginx.yml

PLAY [installa NGINX e avvia il servizio] *****************************

GATHERING FACTS ***************************************************************
ok: [127.0.0.1]

TASK: [installazione Nginx] ***************************************************
changed: [127.0.0.1]

NOTIFIED: [start nginx] *******************************************************
changed: [127.0.0.1]

PLAY RECAP ********************************************************************
127.0.0.1 : ok=3 changed=2 unreachable=0 failed=0

sulla macchina virtuale potrete visualizzare, dal syslog, quello che sta accadendo:

ansible-apt: Invoked with dpkg_options=force-confdef,force-confold upgrade=None force=False package=[‘nginx’] purge=False state=installed update_cache=True pkg=nginx default_release=None install_recommends=True deb=None cache_valid_time=None
Mar 19 15:59:33 precise32 ansible-service: Invoked with name=nginx pattern=None enabled=None state=started sleep=None arguments= runlevel=default

ora sulla macchina virtuale mi ritrovo con l’nginx attivo e rispondente all’indirizzo 127.0.0.1:8080

Welcome to nginx!

Come gia accennato nel primo articolo la curva di apprendimento di questo ottimo strumento di Management dei server e’ davvero bassa e funzionale, ed in poco tempo si e’ in grado di gestire un ambiente ad alto volume di macchine.

Questa è solo una semplice introduzione al mondo di Ansible, e prima di concludere vi faccio inoltre presente che Ansible non è solo usufruibile da linea di comando ma presso il sito ufficiale è disponibile una web dashboard che permette di controllare i job, avere report, statistiche e così via.

Esiste anche Ansible Galaxy , che è invece un repository comunitario di “ricette”, playbooks, task moduli e tutto quello che si può immaginare … Quindi se doveste installare e configurare software come tomcat, oracle, mongodb, jenkins, drupal, rabbitmq e tanti altri, troverete già tutto pronto.
Di sicuro una base di partenza molto comoda per le vostre personalizzazioni!

Se tutto ciò non bastasse ancora, Ansible ha una API estremamente chiara e flessibile per scrivere moduli custom in Python o qualsiasi altro linguaggio, un esempio concreto

#AnsibleConfigurationManagement

DevOps: la metodologia che unisce IT e Business

DevOps

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