L'obiettivo e' di passare da un approccio artigianale nell'amministrazione di tutti i server gestiti da beFair ad uno piu' industriale, ovvero automatizzando tutta una serie di operazioni tra cui:

• deploy e monitoraggio delle applicazioni
• monitoraggio dei processi principali (attivi e disattivi)
• monitoraggio delle risorse hardware (CPU load, RAM, Swap, disco..)
• assicurarsi che tutti i server siano sempre accessibili via SSH
• test sugli URL e redirect (verifica ritorno status code 200/30x su richieste HTTP)
• inviare notifiche a sysadmin-alert@befair.it nel caso di errori o superamento di alcune soglie

I luoghi di riferimento di questo progetto sono:

• questa stessa pagina wiki
• l'alias sysadmin@befair.it
• gli alert arrivano all'alias sysadmin-alert@befair.it

Il master (befair2) dispone di un repository Git in /root/1ring contenente del codice per Ansible, strutturato a partire dalle buone pratiche consigliate. In breve:

doc/            documentazione
inventories/    info su tutti gli host e gruppi di host
  group_vars/     dati sui gruppi di host
  group_files/    file ricorrenti tra piu' host, come le chiavi SSH
  host_vars/      dati per ogni singolo host
  host_files/     file specifici per host
  prod.ini        inventario con tutti gli host e i gruppi
  dev.ini         inventario per i test
playbooks/      script da lanciare, applica 1+ role ad 1+ host
  jobs_high.yml   script per i task ad alta priorita' (ogni 10 minuti)
  jobs_low.yml    script per i task giornalieri
roles/          contiene i role, cioe' i "pacchetti" di Ansible
secrets/        contiene l'archivio keepassx ed eventualmente altri file cifrati
utils/          script di varia utilita'
ansible.cfg     file principale di configurazione
README.rst      guida per installare/configurare Ansible

Nota: per info sui nostri role tutti i dettagli qui

Alcune FAQ su dove trovare cosa:

• archivio keepassx? secrets/befair.kdb
• chiavi SSH? inventories/group_files/all/ssh/id_*.pub
• info sulle installazioni di Gasista Felice? inventories/host_vars/befair2.yml → gf_flavours
• messaggio motd per host befair0? inventories/host_vars/befair0.yml → motd
• demoni/processi per host spes_hosting? inventories/host_vars/spes_hosting.yml
• limite swap su tutti i server spes? inventories/group_vars/spes.yml → swap_perc_limit
• info per accedere via SSH ai server? inventories/group_vars/staff.yml → hosts
• ci sono variabili globali? inventories/group_vars/all.yml

Il repository Git disponde di 2 branch:

• master: branch di sviluppo dove pushiamo direttamente le modifiche (dopo aver fatto pull + rebase)
• prod: branch di checkout, attivo sul server che verra' usato

L'idea e' fare periodicamente il rebase del branch prod con il master.

E' possibile clonarsi il repository in locale con:

$ git clone root@befair2.befair.it:1ring

Al momento vengono archiviati i dati relativi al load_avg e alla memoria. Con l'imminente uscita di InfluxDB 0.9 che dovrebbe aggiungere funzionalita' e standardizzare la struttura dei dati, aggiungeremo anche il supporto alle partizioni che e' rimasto temporaneamente escluso.

E' possibile accedere all'interaccia web Grafana:

$ ssh root@befair2 -L 8889:localhost:8889 -L 8086:localhost:8086

Ora visitare http://localhost:8889/

Ho aggiunto solo un paio di grafici, ma se ne possono aggiungere altri (anche se non vengono memorizzati sul server ← IMHO questo e' l'unico vero problema di Grafana). Per ulteriori info sulla configurazione di Grafana vedere http://grafana.org/docs/features/influxdb/

Inoltre e' possibile accedere ai dati da client Python:

$ ssh root@befair2

# workon 1ring && ipython

 > from influxdb import InfluxDBClient
 > client = InfluxDBClient(host='127.0.0.1', port=8086,
   username='1ring', password='fajw49849f4jp', database='1ring')

Ecco 3 query di esempio:

> client.get_list_series()

> client.query('select mem_usage from befair1')

> client.query('select * from befair1')

Per info sul linguaggio per le query vedere http://influxdb.com/docs/v0.8/api/query_language.html

Il limite e' sul load_avg normalizzato, ovvero il load_avg diviso per il numero di core. Se il limite e' 3 e un VPS ha 2 core, viene inviata una mail nel caso il load_avg supera 6 (3 * 2).

Sono attive notifiche via Mail e XMPP (che in futuro potrebbero passare a Telegram, al momento non c'e' un modulo apposito):

• se un valore supera il limite che ci siamo dati (es: 80% spazio di una partizione) –> warning –> notifica XMPP
• se un valore supera la meta' di quel che e' rimasto (es: 90% di una partizione) –> critical –> notifica mail a tutti i sysadmin

Quindi se un limite e' all'85%, la notifica via mail arriva al 92.5%, se invece il limite e' al 50%, la notifica via mail arriva al 75%.

Per modificare gli account a cui inviare gli alert via XMPP, modificare il file inventories/group_vars/all.yml variabile alert_xmpp_accounts in 1ring.

Per gli alert via mail, modificare il file /etc/aliases variabile sysadmin-alert nel server befair/jagom, quindi dare newaliases && service postfix reload.

Da valutare:

• Sentry (Python)
• Logster (Python)
• Logstash (Ruby), componente di Elastic Search

• comparativa principali sw automazione: A B
• visita la sezione dedicata alla ricerca di nuove soluzioni
• come reagire automaticamente ad eventuali problemi? Runbook