Articolo precedente: introduzione ad Ansible

Continua il nostro viaggio alla scoperta di Ansible, parlando di altri tasselli fondamentali nella struttura e per l’utilizzo del software.

Play e playbook: differenza?

Un esempio di playbook è riportato nell’immagine qui di seguito, nella quale si vede il contenuto del file YAML costituente il playbook stesso. Questo particolare playbook contiene in realtà un solo play, quindi siamo di fronte al caso limite in cui playbook e play coincidono.

Il play contiene due task con la definizione degli host destinatari (hosts: web), il comando become (dove il parametro yes indica che gli host divengono tali dopo l’installazione) e le variabili che definiamo con il parametro var: .

Esistono numerose funzionalità essenziali associate ai playbook, quali Templates, Loops, Conditionals, Tags e Blocks. 

I Template sono file che vengono costruiti dinamicamente sulla base di variabili all’esecuzione di un playbook. Un esempio pratico può essere l’installazione di PHP: al posto di creare tanti playbook quante sono le versioni disponibili, è sufficiente impostare un Template, contenente come variabile la versione da installare come parametro. In sostanza, i template sono modelli di playbook che consentono, dinamicamente, di settare e modificare variabili dei play, generare file come quelli di configurazione partendo da variabili, gestire il tutto secondo una logica condizionale. La costruzione dei template avviene attraverso un motore chiamato Jinja2 templating engine integrato in Ansible.

I Loop possono eseguire task o operazioni multiple, come nel caso in cui sia necessario creare utenti multipli, installare numerosi pacchetti software o, in generale, tutte quelle attività di tipo “bulk”.

Per esempio, nell’immagine seguente creiamo un loop per installare un certo numero di pacchetti su un nodo utilizzando un unico task invece di tanti; il pacchetto è httpd (la sua ultima versione). Il nome del task (che fa uso del solito modulo yum) è virgolettato e tra parentesi abbiamo item, che rimanda alla descrizione degli oggetti da installare. In altre parole il comando in cui il nome non è univoco ma contiene “{{item}} avrà per parametri quelli specificabili nell’apposita sezione che segue e che vedete chiamata with_tems: dove in questo caso è possibile elencare, ciascuno preceduto su un trattino e su una riga (perché l’esecuzione è sequenziale, come già spiegato…), i nomi dei pacchetti.

I Conditionals sono in pratica l’esecuzione di task (attività) condizionata al verificarsi di certe condizioni valutate in corso d’esecuzione(run-time) come variabili, fact o il risultato di un task precedente. Ad esempio:

- yum:
  name: httpd
state: latest
when: ansible_os_family == “RedHat”

dove la condizione impone che il task sia eseguito solo se sul server remoto risulti installata una distribuzione di Linux RedHat. Questo permette di installare un certo pacchetto solo a condizione che il server remoto (il nodo) sia in grado di utilizzarlo.

I Tag sono utili per eseguire un sottoinsieme di playbook su richiesta.

I Role in Ansible

I Role rappresentano una serie di contenuti strettamente correlati, che possono essere condivisi più semplicemente rispetto ai singoli play e che permettono di gestire e mantenere in modo ottimizzato una serie di playbook complessi. I role possono raggruppare playbook, file, template con numerosi vantaggi:

• Miglioramento di affidabilità e la leggibilità dei playbook
• Facilitano la condivisione, il riutilizzo e la standardizzazione di processi di automazione della configurazione degli host;
• Consentono ai contenuti Ansible di esistere indipendentemente da playbook, progetti e anche organizzazioni
• Forniscono vantaggi funzionali come risoluzione di percorsi di file e valori predefiniti   

Ansible Galaxy

Un servizio molto utile collegato ad Ansible è Galaxy (http://galaxy.ansible.com) ed è sostanzialmente un portale dove cercare, riutilizzare e condividere progetti Ansible. Questo consente di realizzare i propri progetti di automazione delle configurazioni partendo da contenuti esistenti elaborati da membri della comunità, con evidente risparmio nei tempi di sviluppo; permette anche agli sviluppatori di condividere i propri lavori a beneficio dei membri della community. Per i possessori di un account GitHub, è possibile utilizzare le stesse credenziali per accedere anche questo portale. Prima di iniziare a lavorare con Ansible è consigliabile dare un’occhiata a Galaxy perché fornisce molti spunti utili e progetti già sviluppati e sui quali fare pratica.

Lavorare con Ansible

Partendo proprio da Galaxy, dove già nella schermata principale si trovano esempi divisi per distribuzione Linux. Risulta molto utile la funzione di ricerca su parola chiave, vista la vastità di progetti disponibili: Una volta trovato il progetto di nostro interesse (che si trova in un repository GitHub) basta accedere al repository e cliccare sul nome, per eseguire il pull dell’interno repository in locale

Il trasferimento e l’installazione si effettuano eseguendo il comando $ ansible-galaxy install seguito dal nome del progetto all’interno dell’ambiente Ansible.

Volendo partire da zero, possiamo creare un file chiamato hosts dall’editor di testo e di introdurvi per esempio il contenuto mostrato nella figura seguente (qui l’editor è quello di MacOS).

Il file hosts definisce la rete e, come preannuncia il nome, contiene i nomi dei nodi, che nel nostro esempio, sono tre e divisi in due gruppi chiamati webservers e server03; al file viene passata la variabile globale [all:vars] che stabilisce che l’utente del computer locale (su cui gira Ansible) autorizzato ad operare sui nodi è l’utente root. La variabile è globale perché è di tipo all.

Chiudiamo e salviamo questo file di configurazione, quindi torniamo alla riga di comando e impartiamo un classico comando Ansible: ansible all -i -m ping, che esegue il modulo ping verso tutti i nodi presenti nell’inventario (-i). La risposta dovrebbe essere quella visibile nell’immagine seguente, ossia contente tre risposte, ciascuna proveniente dagli host dei due gruppi.

Nel caso si voglia arrestare il servizio apache sull’unico nodo appartenente al gruppo server03: il comando da impartire è:

ansible server03 -i hosts -m service -a “name=apache state=stopped2”

dove -i definisce che il comando è per un nodo dell’inventario, -m indica il modulo service e -a il comando riguardante il servizio, che in questo caso riceve lo stato “stopped”. Per far ripartire tale servizio sullo stesso server è sufficiente impartire il comando:

ansible server03 -i hosts -m service -a “name=apache state=started2”

Creazione di un playbook Ansible

Per costruire un playbook occorre aprire l’interfaccia a riga di comando e impartire il comando (che dipende dal sistema operativo) per creare il nostro file: nello specifico lo chiameremo apache.yml (l’estensione di YAML).

L’installazione dei pacchetti viene specificata dal comando with_items, cui segue l’elenco corrispondente e sarà eseguita su tutti i nodi (hosts: all) dall’utente remoto root. È fondamentale rispettare l’indentazione, altrimenti al momento dell’esecuzione il playbook restituirà messaggi d’errore e non sarà eseguito.

Per eseguire il playbook si lancia il comando seguente:

ansible-playbook -v apache.yml

Una volta intuito il meccanismo di base, grazie alla documentazione Ansible e ai moduli disponibili, sarà possibile iniziare a costruire propri playbook sempre più complessi. Sulla documentazione del software è possibile trovare i passaggi dettagliati per la prima installazione in base alla vostra piattaforma e l’utilizzo iniziale.