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.

L'idea e' di realizzare:

• 3-4 role di base
• per ogni applicazione:
  • un role (es: django)
  • un altro role che testa la buona riuscita del primo (es: django_test)

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

Il role webapp mira a standardizzare quanto piu' possibile il deploy di tutte le applicazioni usando strumenti potenti, affidabili e flessibili. In particolare il nostro stack punta attualmente ad avere:

Comunica con l'esterno in HTTP(S), si occupa di gestire le sessioni TLS, serve file statici e demanda le richieste dinamiche (o comunque non cachate) al layer inferiore (app server). In genere le singole richieste vengono bufferizzate e inviate al layer sottostante solo quando sono arrivate del tutto dal client, in modo da minimizzare il lavoro dei workers dell'application server; fanno eccezione le websocket che sono real-time e quindi nessun buffer.

protocollo di comunicazione in uwsgi, molto semplice e simile a SCGI. Se non supportato dall'app server si ricorre a FastCGI o nel caso peggiore rimane HTTP (viene comunque gestito il TLS).

Da non confondersi con il quasi omonimo protocollo, e' il cuore del deploy ed e' colui che si occupa effettivamente di lanciare gli interpreti e servire le richieste. E' uno strumento molto avanzato e potente. Attualmente si ha un master ed N+M workers che servono le richieste (dove N e' il numero minimo ed M i potenziali workers che vengono lanciati in caso di necessita').

• Ogni singolo worker puo' avere piu' thread (noi per ora ne abbiamo solo uno) per aumentare la reqs/s a parita' di RAM occupata (occhio pero' che l'applicazione dev'essere thread-safe!).
• Ogni singolo worker viene lanciato con tutta l'applicazione al suo interno, quindi in caso di aggiornamento dell'applicazione, i workers possono essere ricaricati uno alla volta, avendo sempre almeno N-1 worker a servire le richieste, e quindi gli utenti sperimenteranno un zero downtime in fase di aggiornamento.

uWSGI attualmente supporta Python, Ruby, PHP, Perl… purtroppo il supporto per NodeJS/V8 non e' ancora del tutto pronto. Sebbene ora lo usiamo solo con applicazioni Python, da Debian Jessie possiamo usarlo sostituendo le applicazioni PHP, Python e Perl che attualmente usano FastCGI.

Alternative (su cui siamo rimasti scoperti da uWSGI):

• Passenger per NodeJS

L'application server si potra' poi connettere a database relazionali o non, quali:

• relational: PostgreSQL, MySQL, SQLite
• documental: MongoDB
• key-value: Redis
• time-series: InfluxDB

Server SMTP, IMAP (TODO)

Configurazioni piu' avanzate prevedono l'uso di sistemi di cache quali:

• Varnish (in genere si mette davanti a Nginx))
• Nginx, cache base
• Redis
• Memcached
• HAProxy