Il codice relativo ad Ansible e' suddiviso in roles (una sorta di moduli, pacchetti). Un role puo' gestire la configurazione di un db, piuttosto che di un'applicazione web (come Gasista Felice). O delle funzionalita' di base di un server (es: SSH).

A role is just an organizational container that you can apply to one or multiple hosts in any configuration.

Un role puo' avere come dipendenza un altro o piu' roles. Ansible Galaxy e' una sorta di gestore pacchetti dei roles e s'interfaccia con un repository dove poter scaricare dei role gia' pronti.

Premesse:

1. sul mio portatile o su un altro server (non master) e' gia' pronto un ambiente Ansible funzionante (vedi piu' sotto)
2. sul server c'e' il repository git

L'idea e' di realizzare:

• 3 role di base
• role specifici per le varie app o funzionalita'

I role di base differiscono principalmente per:

• server su cui agiscono
• frequenza con cui vengono rieseguiti

• Target: master (la prima volta viene lanciato dal proprio portatile o da un altro server con Ansible, poi sempre dal master stesso)
• Obiettivo: si assicura che e' installato/aggiornato un ambiente ansible operativo
• Tasks:
  • installazione di Ansible e Cron
  • configurazione di Ansible (symlink a ~/.ansible.cfg o env_var ANSIBLE_CONFIG)
  • configurazione client SSH (symlink a ~/.ssh/config)
  • cronizzazione di tutti i role di Ansible, alta e bassa priorita' (compreso questo)
• Cron: ogni 30 minuti?

Nota: una volta lanciato questo dal portatile non bisogna fare piu' niente, si attiva tutto da solo

• Target: all
• Obiettivo: si assicura che il server SSH, i demoni e processi essenziali* e le risorse principali sul server siano OK, in caso contrario invia una mail o un messaggio su jabber
• Cron: ogni 5 minuti?

*In caso di interventi manuali, sara' comunque possibile creare un file di lock per evitare il controllo di certi demoni/processi, da cancellare poi alla fine dell'operazione.

core_high sta ad indicare i task ad alta priorita'. Si differenzia da un nuovo role chiamato core_low che invece raccoglie quelli a piu' bassa priorita' (es: da eseguire una volta al giorno invece che ogni X minuti).

• Target: 1-2 server
• Obiettivo: si assicura che tutti gli URL ritornino 200, in caso contrario invia una mail o un messaggio su jabber
• Cron: 5 minuti?

Nota: non puo' essere unito a 1 perche' in 1 tutti i server vengono controllati, mentre nel 2 a partire da 1-2 server vengono fatte le richieste a tutti gli URL → quindi gli URL sono slegati dai server

• Target: all (dipende da quali app/funzionalita' sono presenti nei vari server)
• Obiettivi:
  • template bashrc/vimrc per tutti i server (compreso master)
  • backup/logrotate/rsync
  • git rebase master dal branch prod di 1ring
  • installazione/configurazione (o verifica di essi) delle app (gasista felice, etc)
  • app della SPES (rilettore..)
  • tutti gli altri task a priorita' minore
• Cron: 1 volta al giorno?

Vedi README.rst nella root di 1ring.

• gather_facts: no dove non necessario e/o nei task ad alta priorita'