INTRODUZIONE
Ansible è uno strumento di Configuration Management e IT Automation: permette di definire lo stato di uno piu’ server in modo prevedibile, replicabile, consistente. Simile in questo a Puppet, Chef, Saltstack, CFEngine, ma che basa la sua filosofia su una parola chiave: semplicità.
A differenza di molti tool enterprise, Ansible non necessita di altro che una connessione SSH tra la macchina “controllore” e i nodi da controllare, e tutto si gestisce con file di testo.
BREVE STORIA
Nel 2012 la scena DevOps era dominata da Puppet e Chef. L’autore di Cobbler, Michael de Haan, con alle spalle un passato da sistemista IBM, Red Hat e Puppet Labs,
decide di semplificare al massimo le attività di Configuration Management creando un nuovo strumento, che in poco tempo è entrato nella Top10 dei progetti più seguiti su GitHub. Come piccola curiosità, la parola “ansible” si riferisce all’omonimo dispositivo che nel romanzo di fantascienza “Il Gioco di Ender” di Orson Scott Card permetteva di controllare remotamente le astronavi.
CARATTERISTICHE
- non richiede di installare “agent” sulle macchine da gestire
- semplice ed immediato da usare, non richiede conoscenza di linguaggi di programmazione
- multipiattaforma (scritto in python)
- particolarmente leggero e performante
- permette un approccio graduale: puoi iniziare ad usarlo con gli script che hai già fatto
- curva di apprendimento bassa: in pochi minuti dalla lettura del manuale sei già operativo
CONCETTI CHIAVE
L’inventario è una lista di server, opzionalmente raggruppati, sui quali ansible potrà operare. Di solito è contenuto all’interno del file /etc/ansible/hosts anche se è possibile specificare una posizione a piacere o, per avere un pochino più di dinamicità, appoggiarlo su un database.
I Tasks sono i compiti, ovvero insiemi di istruzioni che Ansible esegue in ordine
Gli Handlers sono istruzioni che vanno eseguite come conseguenza di una determinata azione. Ad esempio dopo l’installazione di una applicazione potremmo voler avviare il servizio.
I Playbook sono insiemi di Tasks e Handlers. Un esempio di playbook potrebbe essere quello per l’installazione e la configurazione di un sistema Apache, php e mysql, che comprende vari step da eseguire in sequenza.
I Moduli sono l’equivalente delle risorse in Puppet, e sostanzialmente sono i “verbi” del nostro linguaggio. Ci sono moduli per installare pacchetti, per copiare file, per eseguire comandi remoti, ma anche per interagire con i servizi cloud di Amazon, Google, Openstack, Vmware. La libreria dei moduli è in continua espansione e come vedremo è semplice sviluppare un modulo custom per estendere Ansible sulle nostre esigenze.
INSTALLAZIONE E CONFIGURAZIONE
Installeremo Ansible solo sulla macchina “controllore”, mentre sui nodi da controllare basta che sia presente python2.4 o successivi.
Il software è disponibile già pacchettizzato per le maggiori distribuzioni, ma se volessimo provare l’ultimissima versione possiamo agevolmente prendere il sorgente:
$ git clone git://github.com/ansible/ansible.git --recursive $ cd ./ansible $ source ./hacking/env-setup |
installare, se non già presente, il package manager di python pip:
$ sudo easy_install pip |
e un paio di moduli necessari:
$ sudo pip install paramiko PyYAML Jinja2 httplib2 |
a questo punto siamo già pronti per operare: non serve configurare un database nè far partire demoni, e per gestire le macchine probabilmente le porte del firewall sono già aperte per SSH 🙂
UN PRIMO ESEMPIO
per le prime prove mettiamo da parte il file originale di “inventario” e lo compiliamo con una entry corrispondente al nostro stesso pc:
$ sudo mv /etc/ansible/hosts /etc/ansible/hosts.orig $ sudo bash -c 'echo [local] > /etc/ansible/hosts' $ sudo bash -c 'echo 127.0.0.1 >> /etc/ansible/hosts' |
il file hosts ci permette di raggruppare sotto un’unica dicitura insiemi di macchine; per esempio:
[web] 192.168.22.10 192.168.22.11 web01.intranet.mydomain.net web02.intranet.mydomain.net [database] db01.intranet.mydomain.net db02.intranet.mydomain.net [devel] 192.168.22.10 192.168.22.11 db01.intranet.mydomain.net [prod] web01.intranet.mydomain.net web02.intranet.mydomain.net db02.intranet.mydomain.net
in caso di configurazioni avanzate, è possibile anche alimentarlo dinamicamente
una volta pronto il target su cui eseguire i comandi, proviamo la connessione:
$ ansible local -m ping |
127.0.0.1 | success >> {
"changed": false,
"ping": "pong"
}
abbiamo eseguito il modulo “ping” sul target “local”; in caso di successo, tale modulo non fa altro che ritornare un “pong” in formato JSON, quindi significa che ora siamo in grado di “parlare” con il nostro server remoto 🙂
Per ora chiudiamo qui la prima parte; nella prossima approfondiremo i moduli e faremo automazione IT scrivendo i primi playbook.
