Ansible Roles

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.

Role per l'infrastruttura di base

Qui abbiamo 3-4 role di base (che nel tempo sono leggermente aumentati) finalizzati a tenere su un'infrastruttura di base, che pero' non fornisce servizi o applicazioni.

Questi role differiscono principalmente per:

server su cui agiscono

frequenza con cui vengono rieseguiti

0. Master

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

1. Core_high

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).

2. Test

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

3+. Tutti gli altri roles

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

Role per i servizi

Ogni servizio (database, server smtp, web server) ha un role che installa/configura quel servizio su un certo host. Questi fungono da prerequisiti per le applicazioni che li sfruttano.

WebApp role

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:

Nginx (web server)

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).

uWSGI (application server)

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

Database

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 di posta

Server SMTP, IMAP (TODO)

Cache

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