Come aggiornare una distribuzione con Ansible

Nel precedente articolo Primi passi con Ansible, abbiamo visto come configurare l’ambiente Ansible e come predisporre i sistemi pronti ad essere controllati con Ansible. Ora vediamo come aggiornare i pacchetti delle distribuzioni che abbiamo nel nostro parco macchine.

La cosa in se è molto semplice, basta preparare un playbook che permetta l’aggiornamento con gli ultimi update. Eccolo qua:

- hosts: all
  user: ansible_service
  become: yes
  become_user: root
  tasks:
    - name: update all packages
      yum: name=* state=latest

Il tutto è molto succinto e funziona sia su distribuzioni derivate da Red Hat, SuSE e Debian derivate.

Per poter aggiornare un sistema dobbiamo essere root. Quindi il nostro utente di servizio, che abbiamo creato su tutti i server da gestire, chiamato ansible_service deve diventare root: questo è possibile perchè lo avevamo aggiunto nel file sudoers (vedi precedente articolo).

Notare anche che abbiamo fatto uso del modulo yum, che permette l’aggiornamento anche di sistemi senza il comando yum, perchè esso non è il comando yum ma corrisponde ad un modulo che fornisce gli strumenti per la gestione degli update su tutti i sistemi.

Il nostro file inventory contiene i seguenti host, il cui nome in parentesi quadre riporta la distribuzione:

[oracle_linux_8]
192.168.217.14
[suse_15]
192.168.217.10
[linux_mint]
192.168.217.11
[opensuse_15]
192.168.217.13

Dopo aver lanciato il playbook ci troviamo con questo risultato, non proprio “roseo”:

Il primo host con IP 192.168.217.10 (SuSE 15) è fallito.

L’host 192.168.217.11 (Linux Mint) e 192.168.217.13 (Opensuse) non sono stati aggiornati. Il motivo si può scoprire analizzando i log sui due server, ma il troubleshooting è semplice: nessun nuovo pacchetto è disponibile perchè le distribuzioni sono state aggiornate recentemente.

L’ultimo host, quello con IP 192.168.217.14 (Oracle Linux), in giallo è stato aggiornato; questo lo si può desumere perchè non è fallito (failed=0) e che è cambiato (changed=1). Il fatto che esso sia changed indica che il comando impartito ha provocato una modifica nel sistema e la cosa è ovvia visto che è stato aggiornato.

Un errore come “FAILED! => {“msg”: “Missing sudo password”}” può stare a significare che l’utente ansible non ha i privilegi di root, verificate di averli assegnati.

Ad ogni modo, vediamo perchè il primo host è fallito.

Nello screenshot sotto si può leggere che il primo host 192.168.217.10 non è stato aggiornato perchè si sono verificati degli errori, in particolare il tool zypper (l’equivalente di yum/dnf per SuSE) non è riuscito a raggiungere i server dove sono riposti gli update col messaggio “Problem retrieving the repository…” e “The requested URL returned error…”.

Forse leggere l’output in console per qualche server non è un grosso problema ma se avessimo anche solo una decina di host sarebbe preferibile avere un file con il log del comando.

Uno dei modi può semplici per fare ciò è quello di utilizzare il comando tee che consente l’output in console e anche l’output su file. Per esempio col comando:

ansible-playbook -i ~/ansible/inventory/inventory.list ~/ansible/playbooks/yum.yaml | tee ~/update.log

viene creato un file chiamato update.log nella home dell’utente. Il file ~/ansible/inventory/inventory.list è l’elenco dei server da aggiornare, ~/ansible/playbooks/yum.yaml è il playbook che abbiamo creato prima.