Differences

This shows you the differences between two versions of the page.

--- sysadmin:ansible [2015/01/06 11:47] – [0. Master] kobe
+++ sysadmin:ansible [Unknown date] (current) – removed - external edit (Unknown date) 127.0.0.1
@@ Line 1: / Line 1: @@
-====== 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 [[https://galaxy.ansible.com/|repository]] dove poter scaricare dei role gia' pronti.
-===== Roles =====
-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
-==== 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 [[ssh|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
-===== 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.
-==== Database e server SMTP ====
-L'application server si potra' poi connettere a database relazionali o non, o ad un server di posta.
-==== Cache ====
-Configurazioni piu' avanzate prevedono l'uso di sistemi di cache quali:
-  * Varnish in genere si mette davanti a Nginx
-  * Cache basilare con Nginx
-  * Redis
-  * Memcached