Differences

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

--- sysadmin:ansible [2015/01/11 15:58] – [Server di posta] 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.
-===== 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 [[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
-===== Role per i servizi e le applicazioni =====
-Attualmente abbiamo N role ogni servizi e 1 solo role le applicazioni.
-  * 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.
-  * il role ''webapp'' mira a standardizzare quanto piu' possibile il deploy di tutte le applicazioni usando strumenti potenti, affidabili e flessibili.
-Di seguito descriveremo il nostro stack.
-==== 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):
-  * [[https://www.phusionpassenger.com/|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)
-  * Postfix
-    * /etc/aliases o /etc/postfix/virtual
-    * Spamassassin
-  * Dovecot
-  * Mailman3
-  * Mailman2 e Sympa vanno Ansiblizzati?  Probabilmente non ne vale la pena..
-==== 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
-  * [[http://www.haproxy.org/|HAProxy]]