Archivi tag: open source

Ansible per l’automazione IT ed il Configuration Management

Ansible e l’automazione IT

Ansible e l’automazione IT

Ansible e’ un tool di Configuration Management ed IT Automation che sta riscuotendo un notevole successo tra gli addetti ai lavori in virtu’ della sua immediatezza, della sua semplicita’ di utilizzo e del superamento delle limitazioni della tipica configurazione basata su “server & agent”.

Che cos’e’ Ansible

Ansible quindi e’ un tool di Configuration Management ed IT Automation che rientra nella sfera degli strumenti tipici del metodo DevOps.

DevOps e’ un movimento nato per abbattere il muro di gomma che nel corso degli anni si e’ innalzato tra Developer e Sysadmin. Per usare un’analogia, DevOps e’ una cultura che ha lo scopo di creare una pipeline (in pratica un ponte di comunicazione) tra sviluppatori ed amministratori di sistema.

L’obiettivo e’ uno solo: aumentare costantemente la soddisfazione del cliente producendo ed erogando software allo stato dell’arte con continue release correttive.

Per raggiungere un obiettivo cosi’ ambizioso e’ importante poter contare non solo sulle persone ma anche sugli strumenti. Cosi’ sono nati tool agili ed intuitivi che hanno lo scopo di automatizzare lo sviluppo, il testing e la configurazione di server ed applicazioni. Questa famiglia di tool per il Configuration Management comprende gia diversi nomi blasonati come ad esempio Puppet, Chef, Saltstack e CFEngine.

Configuration Management in breve

Il Configuration Management e’ un processo utilizzato per definire la configurazione delle applicazioni web e dei server in modo consistente, possibilmente sotto controllo di versione. Con il Configuration Management e’ possibile definire a priori come dovra’ essere configurato il server X o l’applicazione Y. Il tutto in linguaggio sorgente o sotto forma di meta-linguaggio.

I tool di Configuration Management leggono le configurazioni a partire da un file sorgente ed applicano le stesse su uno o piu’ server, in modo automatico e prevedibile.

Esempio:

inizio configurazione
1 assicurati che apache2 sia installato
2 assicurati che php5 sia installato
3 assicurati che mysql sia installato
fine configurazione

Un tool di Configuration Management puo’ leggere queste istruzioni ed applicarle su uno o piu’ server. In questo modo l’operatore puo’ replicare la stessa configurazione su decine di server oppure ricostruire la stessa in pochi secondi quando uno o piu’ server vengono messi fuori uso.

Ansible, un po’ di storia

Lanciato nel 2012, Ansible  nasce da un’idea di Michael de Haan, creatore tra l’altro di Cobbler. De Haan un bel giorno sente la necessita’ di scrivere un software che potesse semplificare all’ennesima potenza le attivita’ di Configuration Management ed Automazione IT.

Fino a quel momento il panorama del Configuration Management era dominato da Puppet e Chef (che comunque mantengono e sicuramente manterranno  anche in futuro quote di mercato molto vaste). Ma seppure ottimi, sia Puppet che Chef hanno alcuni punti deboli, che fanno storcere il naso ai Sysadmin piu’ esigenti:

* Puppet e Chef funzionano principalmente in modalita’ server – agent

* Chef richiede anche la conoscenza del linguaggio Ruby

Anche se non si tratta di limitazioni insormontabili ci sono comunque alcuni svantaggi in questo tipo di approccio.

Prima di tutto non sempre e’ possibile installare un agent sul server di destinazione, poiche’ un agent e’ comunque un piccolo software che rimane in esecuzione permanente su uno o piu’ server ed ha lo scopo di attendere comandi e configurazioni impartite dal server master.

Sia Chef che Puppet utilizzano questo approccio che spesso non e’ possibile mettere in pratica.

Pensiamo ad esempio ad ambienti server che per ragioni di conformita’ o sicurezza non possono ospitare agenti o software estranei oppure a quei server con un discreto numero di anni sulle spalle, dove l’installazione di una versione aggiornata di Ruby (richiesta, ad esempio, da Puppet) potrebbe causare effetti imprevedibili.

I vantaggi di Ansible

Perche’ dunque adottare Ansibile ?
Se sei un Sysadmin o un Developer potrai trarre sicuramente grande beneficio dall’uso di questo tool: con Ansible non e’ mai stato cosi’ semplice definire lo stato di un server e delle tue applicazioni web.
Con Ansible quindi il risparmio di tempo e di codice e’ notevole rispetto a Puppet o Chef.

Curva di apprendimento bassa

Dalla lettura della documentazione alla scrittura dei primi Playbooks il passo sara’ breve, ed in pochi minuti vi sara’ possibile iniziare a lavorare con Ansible senza dover penare con configurazioni di server Master e agenti vari.

Non sono richieste capacita’ di coding

Puppet e Chef nascono entrambi da un team di sviluppatori follemente innamorati di Ruby. Per la definizione dello stato dei server e delle configurazioni Puppet adotta un linguaggio simile al codice Ruby mentre per definire lo stato di un server con Chef e’ addirittura essenziale conoscere il linguaggio, invece Ansible supera completamente questa limitazione.

In Ansible ad esempio e’ possibile definire che il server X dovra’ contenere Apache con due righe:
es:

Install Httpd
yum: name=httpd state=latest

Come si puo’ notare, a differenza di Puppet, Chef e Saltstack, Ansible non ha bisogno di nessun agente per applicare le configurazioni su un server. Ansible utilizza di default il trasporto SSH: questo elimina la necessita’ di installare software estraneo sui nodi.

Modulare e Open Source

Ansible e’ composto da numerosi moduli. Per analogia i moduli di Ansible hanno la stessa funzione delle risorse in Puppet. Ogni modulo svolge delle funzioni ben precise e gestisce un singolo aspetto di ogni sistema. Questa architettura consente di espandere Ansible praticamente all’infinito, senza contare che i moduli possono essere scritti in qualsiasi linguaggio di programmazione. Inoltre Ansible e’ Open Source e la comunita’ continua a crescere rapidamente.

Ansible, i concetti chiave

Prima di terminare con questa introduzione su Ansible vediamo quali sono i concetti chiave ed i componenti che ruotano attorno a questo software.

Ansible: l’inventario

L’inventario e’ una lista di server sui quali Ansible applica, a comando, le configurazioni di sistema e le istruzioni di automazione. L’inventario di solito e’ contenuto all’interno del file /etc/ansible/hosts anche se e’ possibile specificare una posizione a piacere.

All’interno dell’inventario l’operatore puo’ specificare la lista dei server “bersaglio”. E’ chiaramente obbligatorio che ogni server abbia una corrispondenza DNS anche se e’ possibile specificare ogni server con il proprio indirizzo IP . Un esempio di inventario:

[webservers]
webserver1.example.com
webserver2.example.com

[dbservers]
dbserver1.example.com
dbserver2.example.com

Ansible ed i Tasks

In Ansible i Tasks sono dei “compiti” ovvero una serie di istruzioni che Ansible esegue in ordine di apparizione. Ogni istruzione contiene la definizione e/o la configurazione che dovra’ essere applicata ad ogni sistema.

Ansible e gli Handlers

Gli Handlers in Ansible sono delle istruzioni che vengono eseguite a seguito di una determinata azione. Ad esempio dopo aver installato httpd un operatore puo’ voler avviare Apache automaticamente. Un esempio di Handler che avvia Apache su CentOS:

name: start httpd
service  : name=httpd state=started enabled=yes

Gli Handlers si basano sul modulo service di Ansible (questo modulo viene utilizzato per gestire i servizi di sistema).

Ansible ed i Playbook

In Ansible i Playbook sono delle collezioni di Tasks. Ogni Playbook puo’ contenere un determinato numero di Tasks e di Handlers. I Playbook devono essere definiti in linguaggio YAML.


Ansible ed i Moduli

Ansible e’ composto da numerosi moduli. Esistono moduli per gestire i servizi di Cloud Computing (EC2 su AWS), Rackspace e Google Compute Engine, esistono moduli per installare pacchetti software su server Linux con apt e yum, moduli per gestire file di configurazione e database e molto altro ancora.

Per una lista completa dei moduli puoi consultare la documentazione ufficiale: Ansible Modules.

#AnsibleConfigurationManagement

Twemproxy il proxy per Memcached

twemproxy2

Twemproxy (repository GitHub) è un proxy server che consente di ridurre il numero di connessioni aperte verso un server Memcached o Redis. Per cosa può essere utile questo strumento?

 

 

Le caratteristiche principali sono :

– ridurre il numero di connessioni al cache server agendo come un proxy;

– sharding di dati automatico tra più cache server;

– supporto per l’hash con diverse strategie e funzioni di hashing;

– configurabile per disabilitare i nodi caduti;

– esecuzione di istanze multiple, consentendo al client di connettersi al primo proxy server disponibile;

– pipelining e batching di richieste con risparmio di round-trip;

– configurabile per disabilitare i nodi non più funzionanti, e richiamarli successivamente, dopo un po’ di tempo;

Twemproxy è stato reso open source da Twitter (che lo ha sviluppato per le proprie esigenze) all’inizio del 2012, con il supporto a memcached, e recentemente ha aggiunto anche il supporto a Redis. Twitter fa uso estensivo dei cache server ed il sistema sul quale gira Twemproxy, per Twitter, è di dimensioni impressionanti; immaginate che i sistemisti devono gestire centinaia di cache server, che a loro volta amministrano svariati TB di dati ciascuno per oltre trenta servizi diversi, in-memory, inclusa la memorizzazione dei tweet. Parliamo di almeno due milioni di miliardi di query al giorno, ossia più di ventitré milioni di query al secondo, per un’infrastruttura che, peraltro, continua a crescere in maniera esponenziale.

Leggi anche articolo (“Ottimizzazre grazie a Memcached“)

 

GlusterFS: Storage Scalabile e Distribuito

glusterfsIntroduzione

GlusterFS è un file system open source distribuito e scalabile orizzontalmente, la cui capacità può essere dinamicamente espansa mediante l’aggiunta di nuovi nodi. GlusterFS è in grado di arrivare a gestire fino a diversi Peta Byte, migliaia di client e diverse aree dati (storage) organizzandole in blocchi che rende accessibili su Infiniband RDMA (remote direct memory access, fibra ottica) o connessioni TCP/IP.

Le risorse {memoria e disco} vengono rese disponibili sotto un unico punto di condivisione e tali risorse possono essere montate dai client mediante tre diversi protocolli: CIFS, NFS oppure tramite il client nativo Gluster.

Inoltre GlusterFS supporta la replica geografica ossia la replica dei dati di un Volume su un Server dislocato in un area geografica diversa da quella dove sono presenti gli altri nodi.

Iniziamo a prendere confidenza con alcune terminologie di GlusterFS:

  • Volume: Identifica la condivisione effettiva che viene messa a disposizione
  • Brick: Identifica il file system locale di un server su cui opera GlusterFS
  • Translator: Identifica delle componenti ( librerie ) che estendono le funzionalità del file system
  • Server: Identifica la macchina o le macchine ( reali o virtuali ) dove risiedono i dati
  • Client: Identifica la macchina che monta il volume

La logica quindi è la seguente:

Si installa GlusterFS su ogni server che fa parte del pool di storage del cluster, si definiscono i blocchi ( bricks ) da esportare ( directory ) andando cosi a creare la condivisione effettiva chiamata Volume.

Successivamente su ogni Client interessato installiamo allo stesso modo GlusterFS, e tramite i protocolli citati prima ( NFS, CIFS, GlusterFS Client ) andiamo a montare il cluster rendendo disponibile la condivisione ( Volume ).

Vediamo adesso le diverse TIPOLOGIE DI VOLUME ossia come i dati possono essere organizzati:

  • Distributed: Definisce un {Volume Distribuito} dove i file vengono distribuiti in maniera random tra i vari brick del Volume che compongono il Cluster. Questo comporta maggior scalabilità ma molta meno ridondanza,infatti nel caso in cui ci fosse un Volume cosi configurato, un guasto del Server ( Brick ) comporta la perdita dei dati in esso contenuti.
  • Replicated: Definisce un Volume Replicato dove i file vengono replicati tra i Brick del Volume che compongono il Cluster. Questo comporta una riduzione dello spazio disponibile per lo Storage ma una maggior ridondanza e tale configurazione è consigliabile per avere un Elevata Affidabilità e un Elevata Disponibilità.
    Nel caso in cui ci fosse un Volume cosi configurato, un guasto del Server ( Brick ) NON comporterebbe la perdita dei dati visto che ne abbiamo una replica a disposizione. Le repliche dei dati è consigliabile averle in brick separati cioè che non si trovino sulla stessa macchina.
  • Striped: Definisce un Volume Striped dove i file vengono memorizzati in blocchi nei brick del Volume che compongono il Cluster.
    Questo comporta maggiori prestazioni in lettura e scrittura su file di grandi dimensioni e maggior spazio a disposizione ma una minor ridondanza. Nel caso in cui ci fosse un Volume cosi configurato, un guasto del Server ( Brick ) comporta la perdita dei dati in esso contenuti.
  • Distribuited Striped: Definisce un Volume Distribuito e Striped dove il Volume memorizza i file in blocchi tra 2 o più nodi del Cluster. Nel caso in cui ci fosse un Volume cosi configurato, un guasto del Server ( Brick ) comporta la perdita dei dati in esso contenuti.
  • Distribuited Replicated: Definisce un Volume Distribuito Replicato dove il Volume distribuisce e replica i file tra i Brick del Cluster. Questo comporta la combinazione dei pregi delle singole soluzioni distributedd e Replicated.
    Nel caso in cui ci fosse un Volume cosi configurato, un guasto del Server ( Brick ) NON comporterebbe la perdita dei dati visto che ne abbiamo una replica a disposizione e il Volume resterebbe sempre accessibile.
  • Striped Replicated: Definisce un Volume Striped Replicato dove il Volume fa lo Stripe dei file e li replica tra i Brick del Cluster.
    Si combinano i pregi dello Stripe ossia maggiori prestazioni in lettura e scrittura utile per esempio su file di grandi dimensioni con i pregi della Replicazione sui Brick del Cluster per avere cosi prestazioni e ridondanza.
    Nel caso in cui ci fosse un Volume cosi configurato, un guasto del Server ( Brick ) NON comporta la perdita dei dati in esso contenuti.

INSTALLIAMOLO
Per procedere all’installazione e testare il software dovremo avvalerci di almeno due macchine, decidete voi se reali o VM, dopodiche’ inizieremo dividendo il lavoro; partiamo con la macchina che fara’ da Server :

modifichiamo a dovere il file /etc/hosts, io ho fatto nel seguente modo

# vim /etc/hosts
192.168.2.138    server1.example.com     server1
192.168.2.182    client1.example.com     client1

aptitude install glusterfs-server

…ora dobbiamo creare le seguenti directory

mkdir /data/
mkdir /data/export
mkdir /data/export-ns
cp /etc/glusterfs/glusterd.vol /etc/glusterfs/glusterd.vol_orig
cat /dev/null > /etc/glusterfs/glusterd.vol
vim /etc/glusterfs/glusterd.vol
volume posix
  type storage/posix
  option directory /data/export
end-volume

volume locks
  type features/locks
  option mandatory-locks on
  subvolumes posix
end-volume

volume brick
  type performance/io-threads
  option thread-count 8
  subvolumes locks
end-volume

volume server
  type protocol/server
  option transport-type tcp
  option auth.addr.brick.allow 192.168.2.182 # inserire qui l'indirizzo od il nome host del vostro client
  subvolumes brick
end-volume
/etc/init.d/glusterfs-server start

…ora passiamo a lavorare sul client

aptitude install glusterfs-client glusterfs-server
mkdir /mnt/glusterfs  

cp /etc/glusterfs/glusterd.vol /etc/glusterfs/glusterd.vol_orig
cat /dev/null > /etc/glusterfs/glusterd.vol
vim /etc/glusterfs/glusterd.vol


volume remote
  type protocol/client
  option transport-type tcp
  option remote-host server1.example.com # inserite qui l'indirizzo od il nome host del server
  option remote-subvolume brick
end-volume

volume writebehind
  type performance/write-behind
  option window-size 4MB
  subvolumes remote
end-volume

volume cache
  type performance/io-cache
  option cache-size 512MB
  subvolumes writebehind
end-volume

ora dobbiamo lanciare uno di questi due comandi :

glusterfs -f /etc/glusterfs/glusterd.vol /mnt/glusterfs

oppure

mount -t glusterfs /etc/glusterfs/glusterd.vol /mnt/glusterfs

….se non avete avuto errori eseguendo il comando mount dovreste vedere qualcosa del genere

# mount
/etc/glusterfs/glusterd.vol on /mnt/glusterfs type fuse.glusterfs (rw,default_permissions,allow_other,max_read=131072)

# [client1] df -h
/etc/glusterfs/glusterd.vol
143G   33G  103G  25% /mnt/glusterfs

che nel mio caso equivale alla partizione /home della macchina server
# [server1] df -h
/home/server1/.Private            143G   33G    103G  25% /home/server1/Private

…come notate dalle dimensioni dei due filesystems

a questo punto non ci rimane altro che modificare il file /etc/fstab in modo da rendere immediato il mount al boot del client

# vim /etc/fstab

/etc/glusterfs/glusterfs.vol  /mnt/glusterfs  glusterfs  defaults  0  0

Questo era solo un semplice esercizio per imparare a capire il software in questione ovviamente con le dovute aggiunte e modifiche del caso si potranno creare Volumi e directory ad hoc della grandezza desiderata in cui salvare tutti i dati per noi importanti.

Buon divertimento !

Torino verso Linux

comune_torinoUbuntu e ODF liberano Torino

Torino ha deciso di puntare su Linux, sistema operativo libero che consentirà di guadagnare più di 6 milioni di Euro di soldi pubblici, nello specifico la versione prescelta sara’ Ubuntu.

Cosi dopo Udine anche la città di Torino ha deciso di dire addio a Windows e Microsoft Office per puntare su Linux e il software libero (ed era ora) . La migrazione da Microsoft Windows e Office consentirà non solo di risparmiare moltissimi soldi ma fornirà sistemi e software più sicuri e stabili garantendo cosi ai propri cittadini servizi molto più affidabili.

Ad annunciarlo è stato il portale di Repubblica.it indicando che con Microsoft Windows e Office ogni uno dei 8300 personal computer dell’amministrazione costava circa 300 Euro di licenze per il software proprietario, la migrazione ad Ubuntu Linux consentirà quindi di non avere più nessuna spesa facendo risparmiare circa 6 milioni di Euro di soldi pubblici che potranno essere investiti per migliorare i servizi comunali.

Tutto questo parlare di soldi ha chiaramente il suo valore ma mi dispiace notare che nessuno parli invece dell’accrescimento che queste operazioni possono portare verso una migliore gestione sistemistica, per tutto cio’ che sta dietro ai portali inerenti a Regione, Anagrafe, Comune ecc….., portandoli cosi’ anche verso una unificazione del formato dei documenti digitali verso Il formato OpenDocument (ODF); quest’ultimo è un formato aperto per file di documento per l’archiviazione e lo scambio di documenti per la produttività di ufficio, come documenti di testo (memo, rapporti e libri), fogli di calcolo, diagrammi e presentazioni, dal momento che un obiettivo dei formati aperti come OpenDocument è quello di garantire accesso a lungo termine ai dati senza barriere legali o tecniche.

Per quanto riguarda i documenti nel formato OpenDocument, le estensioni più comuni sono:

.odt – documenti di testo

.ods – fogli di calcolo

.odp – presentazioni

.odg – grafica

.odb – database.

Torino diventerà presto una città completamente open source, come già accaduto a Monaco, Bolzano e molte altre città, visto anche i tanti vantaggi ottenuti dalla migrazione ben presto anche l’intera regione Piemonte potrebbe migrare verso il software libero.

Linuxcon Europe – 2014

LinuxCon EuropeLinuxCon Europe – Linux Foundation

La Linux Foundation, l’organizzazione non-profit che sostiene la crescita di Linux e dello sviluppo collaborativo, ha annunciato i relatori della LinuxCon + CloudOpen + Embedded Linux Conference Europe, che si terrà dal 13 al 15 ottobre presso il Centro Congressi di Düsseldorf.

LinuxCon Europe è il luogo in cui apprendere dai migliori e più intelligenti, grazie agli interventi dei più importanti utilizzatori, sviluppatori e project leader della comunità Linux.

Non esiste un altro evento in Europa che permetta a sviluppatori, amministratori di sistemi, architetti e talenti tecnici di qualsiasi tipo e livello di riunirsi sotto un unico tetto per imparare, collaborare e risolvere problemi allo scopo di fare avanzare ulteriormente la piattaforma Linux.

LinuxCon prevede oltre 100 sessioni, con novità sugli ultimi aggiornamenti del kernel, sulle tecnologie e interfacce di storage, sulla sicurezza e l’Internet of Things, nonché interventi sulle best practice e la collaborazione open source.

I relatori della conferenza LinuxCon + CloudOpen + ELC Europe di quest’anno illustreranno i passi in avanti compiuti da Linux e dall’open cloud, nonché il modo in cui i metodi e i principi di Linux e dell’open source si stiano diffondendo in altri settori della società, tra cui la vendita al dettaglio e la sanità.

Tra i relatori confermati:

● Jono Bacon, Senior Director of Community di XPRIZE, che nel suo intervento “Building Exponential Communities” parlerà di come sfruttare al meglio il lavoro in un ambiente comunitario

● Paul Biondich, fondatore e presidente di OpenMRS, che parlerà di come le comunità open source stiano aiutando a migliorare la salute dei più poveri in tutto il mondo

● Joanna Rutkowska, fondatrice e CEO di Invisible Things Lab, che parlerà di Qube OS e di come esso rappresenti un approccio pratico alla sicurezza dei sistemi client

● Chris Schlaeger, Direttore Generale dell’Amazon Development Center, che farà una presentazione sugli elementi fondamentali degli Amazon Web Services

Inoltre, l’attesissima presentazione del Linux Kernel Panel vedrà come protagonista Linus Torvalds, creatore e membro della Linux Foundation, insieme ad altri importanti sviluppatori e addetti alla manutenzione del kernel, che parleranno dello stato del kernel Linux, nonché delle attività future e in corso.

Per iscriversi all’evento bastera’ seguire questo link : LinuxConEurope.