Ansible – automazione IT e Configuration Management (II parte)

Ansible + Vagrant Environment

Ansible + Vagrant Environment

 

 

 

 

 

 

Nel primo articolo “Ansible per l’automazione IT ed il Configuration Management” abbiamo descritto le caratteristiche principali di questo interessante prodotto per il Configuration Management. In questo secondo articolo descriveremo con degli esempi come utilizzare nel concreto Ansible.

Per preparare il nostro ambiente di lavoro sfrutteremo un’altro software, che rappresenta, anch’esso una delle grandi novita’ del Web degli ultimi mesi come Vagrant, di cui abbiamo parlato nell’articolo “Virtualizzazione e provisioning senza sforzo“.

configuriamoci l’ambiente Vagrant:

$ vagrant box add pre http://files.vagrantup.com/precise32.box
$ vagrant init precise32
$ vagrant up

a seguito dell’ultimo comando, vedremo dei messaggi come questi:

Bringing machine 'default' up with 'virtualbox' provider...
[default] Importing base box 'precise32'...
[default] Matching MAC address for NAT networking...
[default] Setting the name of the VM...
[default] Clearing any previously set forwarded ports...
[default] Clearing any previously set network interfaces...
[default] Preparing network interfaces based on configuration...
[default] Forwarding ports...
[default] -- 22 => 2222 (adapter 1)
[default] Booting VM...
[default] Waiting for machine to boot. This may take a few minutes...
[default] Machine booted and ready!
Guest Additions Version: 4.2.0
VirtualBox Version: 4.3
[default] Mounting shared folders...
[default] -- /vagrant

Vagrant ha quindi scaricato e creato per noi una macchina virtuale Ubuntu Precise (32bit). Scorrendo i messaggi ci sono due cose importanti da notare: la prima è che il traffico sulla porta 2222 del nostro pc locale sarà inoltrato alla porta 22 della macchina virtuale; la seconda è che l’utente “vagrant” sulla macchina remota può connettersi con la password “vagrant” ed ha già i privilegi per diventare root con sudo. Aggiorniamo quindi l’inventario delle macchine che decidete di coinvolgere modificando il file /etc/ansible/hosts

Dopo aver preso confidenza con Vagrant iniziamo la configurazione dell’ambiente per Ansible, iniziando ad usarlo per automatizzare i compiti di ogni giorno.

Configuriamo il file /etc/ansible/hosts tramite comando:

# sudo bash -c 'echo [web] >> /etc/ansible/hosts'
# sudo bash -c 'echo 127.0.0.1:2222 ansible_ssh_user=vagrant ansible_ssh_pass=vagrant >> /etc/ansible/hosts'

Verifichiamo che ansible sia in grado di leggere correttamente i parametri inseriti nel file hosts usando il seguente comando:

# ansible -m ping all
127.0.0.1 | success >> {
"changed": false,
"ping": "pong"
}

Ansible facts
come possiamo essere sicuri che la macchina a cui ci stiamo connettendo sia quella giusta ? Diamo un’occhiata ai “facts”, ovvero a tutte le informazioni che Ansible raccoglie…

# ansible web -m setup | less

otteniamo cosi’ una serie di dati in formato JSON tra cui notiamo che il nostro nuovo server ha come hostname ‘localhost’.
A titolo didattico scriveremo un playbook per installare un webserver nginx sul nuovo server.

Ora apriamo un editor per iniziare a scrivere il nostro playbook che si chiamera’ nginx.yml :

--- PLAYBOOK ottimizzato su Centos Linux
- name: installa NGINX e avvia il servizio
   remote_user: root
   sudo: yes
   hosts: web
   tasks:
   - name: installazione Nginx
     apt: pkg=nginx state=installed update_cache=true
     notify:
     - start nginx
   handlers:
     - name: start nginx
     service: name=nginx state=started

Come possiamo notare nel playbook abbiamo editato una lista di task, uno per ogni “step” del nostro compito.
Se stiamo usando virtualbox come hypervisor, dobbiamo aggiungere una riga al file (bastera’ solo decommentarla) di configurazione di vagrant perché attivi il forwarding della porta 80 della guest sulla porta 8080 del nostro pc.

(vedi https://docs.vagrantup.com/v2/networking/forwarded_ports.html)

config.vm.network "forwarded_port", guest: 80, host: 8080

e dare il comando per ricaricare la virtual machine con la nuova configurazione:

vagrant reload
[default] Attempting graceful shutdown of VM...
[default] Clearing any previously set forwarded ports...
[default] Clearing any previously set network interfaces...
[default] Preparing network interfaces based on configuration...
[default] Forwarding ports...
[default] -- 22 => 2222 (adapter 1)
[default] -- 80 => 8080 (adapter 1)
[default] Booting VM...
[default] Machine booted and ready!

Ora possiamo lanciare il playbook

# ansible-playbook nginx.yml

PLAY [installa NGINX e avvia il servizio] *****************************

GATHERING FACTS ***************************************************************
ok: [127.0.0.1]

TASK: [installazione Nginx] ***************************************************
changed: [127.0.0.1]

NOTIFIED: [start nginx] *******************************************************
changed: [127.0.0.1]

PLAY RECAP ********************************************************************
127.0.0.1 : ok=3 changed=2 unreachable=0 failed=0

sulla macchina virtuale potrete visualizzare, dal syslog, quello che sta accadendo:

ansible-apt: Invoked with dpkg_options=force-confdef,force-confold upgrade=None force=False package=[‘nginx’] purge=False state=installed update_cache=True pkg=nginx default_release=None install_recommends=True deb=None cache_valid_time=None
Mar 19 15:59:33 precise32 ansible-service: Invoked with name=nginx pattern=None enabled=None state=started sleep=None arguments= runlevel=default

ora sulla macchina virtuale mi ritrovo con l’nginx attivo e rispondente all’indirizzo 127.0.0.1:8080

Welcome to nginx!

Come gia accennato nel primo articolo la curva di apprendimento di questo ottimo strumento di Management dei server e’ davvero bassa e funzionale, ed in poco tempo si e’ in grado di gestire un ambiente ad alto volume di macchine.

Questa è solo una semplice introduzione al mondo di Ansible, e prima di concludere vi faccio inoltre presente che Ansible non è solo usufruibile da linea di comando ma presso il sito ufficiale è disponibile una web dashboard che permette di controllare i job, avere report, statistiche e così via.

Esiste anche Ansible Galaxy , che è invece un repository comunitario di “ricette”, playbooks, task moduli e tutto quello che si può immaginare … Quindi se doveste installare e configurare software come tomcat, oracle, mongodb, jenkins, drupal, rabbitmq e tanti altri, troverete già tutto pronto.
Di sicuro una base di partenza molto comoda per le vostre personalizzazioni!

Se tutto ciò non bastasse ancora, Ansible ha una API estremamente chiara e flessibile per scrivere moduli custom in Python o qualsiasi altro linguaggio, un esempio concreto

#AnsibleConfigurationManagement

Nginx HTTP 2.0 supportato entro fine 2015

Nginx e supporto HTTP 2.0

Nginx e supporto HTTP 2.0

Nginx supporta da sempre l’attuale protocollo HTTP 1.1 ed il protocollo di Google SPDY. Con l’annuncio di HTTP 2.0, Nginx è pronta a convertire il supporto SPDY verso il neonato HTTP 2.0 entro la fine di quest’anno.

Il protocollo HTTP 2.0 è la nuova generazione del protocollo attuale e su cui si basa l’intera Internet, che viene adesso rinnovato dopo circa 16 anni.

Questo non significa certo che lo standard è stato finalizzato ed è appropriato all’operatività, ma indica che tutte le sue specifiche sono state definite in modo conclusivo e la documentazione può passare al gruppo RFC per l’approvazione finale come standard definitivo.

Comunque, anche dopo la dichiarazione a standard, il protocollo non entrera’ subito in attività, anche perché dovrà, prima di tutto, essere implementato e supportato nei browser e nei Web server.

Fra i Web server, Nginx si dice comunque pronto a supportare questa nuova tecnologia e il motivo di questa sicurezza sta nel pieno supporto alla versione draft 3.1 di SPDY, di cui Google ha deciso l’interruzione dello sviluppo e l’esclusione da Chrome.

Il fatto che il protocollo HTTP 2.0 sia gran parte basato su SPDY permette a Nginx di avere già una solida base di codice pronto per essere riutilizzato ai fini di ospitare il nuovo HTTP quando questo diventerà lo standard. Secondo Owen Garrett, responsabile di prodotto per Nginx : ” l’implementazione nel Web browser sarà facile e snella, in quanto la maggior parte dei siti Web SPDY già viene eseguita correttamente in Nginx “.

HTTP/2 si baserà, inoltre, sulle stesse API che già conoscono e usano gli sviluppatori del web, ma in più offrirà feature esclusive a cui questi possono attingere. Fino ad oggi, ad esempio, bisognava adottare alcune tecniche di ottimizzazione per impedire alla pagina di effettuare troppe richieste HTTP. Il nuovo protocollo permetterà invece l’esecuzione di un numero superiore di richieste contemporanee, attraverso una tecnica chiamata multiplexing , senza che queste blocchino il caricamento degli elementi della pagina.

HTTP/2 effettua un numero di connessioni inferiore rispetto alle tecnologie attuali, fattore che si traduce con un carico minore richiesto ai server e alle reti per il caricamento dei dati. Il nuovo protocollo supporta TLS ma non obbligherà all’implementazione del layer di crittografia.

Uno dei più importanti cambiamenti di HTTP 2.0 infatti sara’ la crittografia basata su protocollo TLS, a cui Nginx dice di voler dare un approccio implementativo persistente. Inoltre, il nuovo protocollo Internet introduce alcune differenze nella gestione delle priorità, in modo da fornire un maggiore controllo sui flussi di traffico. Sempre secondo Garrett, la maggiore sfida non sarà tanto nell’implementazione nei browser e nei Web server, quanto nell’adeguamento dei siti Web, che dovranno essere ottimizzati per il protocollo HTTP 2.0.

“Ci potrebbe essere molto lavoro di ottimizzazione e re-ingegnerizzazione dei siti Web, soprattutto per mantenere la compatibilità con i client più anziani” ha detto Garrett.

 

Docker – costruire i contenitori

Docker costruire i contenitori

Docker costruire i contenitori

Recentemente abbiamo parlato della virtualizzazione tramite Docker (vedi articolo Docker – cosi cambia la virtualizzazione) e, prima di proseguire sara’ meglio rifare una piccola introduzione.

Docker e’ indubbiamente una valida alternativa alla virtualizzazione tradizionale nel mondo Linux. Questo tipo di virtualizzazione, detta a “container” non emula un’ intero hardware come fanno invece gli hypervisor tipo VMware, Virtualbox, Xen o KVM, ma crea invece dei “contenitori” nel sistema operativo dove possono essere messe in esecuzione applicazioni di vario genere in modo del tutto separato una dall’altra.

Dato che con il cloud il ruolo del sistema operativo diventa sempre meno importante perchè si punta più sullo strato applicativo, PaaS, rendendo il tutto più flessibile. A questo punto se dovessimo far girare 1000 clienti su un ambiente condiviso, diventerebbe interessante disporre di una tecnologia di virtualizzazione che riduca al minimo fisiologico gli overhead.

La virtualizzazione classica non è così, perchè per ogni ambiente applicativo, riservato ad un cliente, si dovrebbe  lanciare una intera macchina virtuale con dentro l’intero sistema operativo. E allora perchè non condividere lo stesso sistema operativo e invece isolare solo gli ambienti di esecuzione delle applicazioni , tipo application server, DB ecc…

I container sono dunque alla base dei moderni servizi cloud di tipo PaaS (Platform as a service) che usano questo tipo di virtualizzazione per misurare il consumo di risorse ed assegnarne i limiti.

Ad esempio, se su uno stesso server fisico, con una soluzione di virtualizzazione di tipo hypervisor si possono ospitare, supponiamo 50 virtual machines, con la virtualizzazione a container si potra’ arrivare anche a 1000 container. Questo perchè un container di per sè è solo un contenitore di processi, mentre una virtual machine completa contiene tutto un ambiente operativo emulato.

Il container può anche essere portabile, infatti ci basta copiare la directory che contiene il filesystem modificato dall’utente dopo la creazione del container, un piccolo file di configurazione, ed il container diventera’ eseguibile su qualsiasi sistema che supporti LXC.

Il concetto è talmente interessante, che qualcuno ha pensato di fare un sistema operativo Linux interamente basato sui container, in cui non c’è nemmeno un package manager perchè si assume che gli applicativi saranno solo in forma di container. Coreos è nato proprio con il principio di supportare ambienti di esecuzione a container, togliendo dal sistema tutto quello che non è strettamente necessario per farlo funzionare.

INSTALLAZIONE

Abbiamo tre possibili metodi d’installazione :

1) Centos

sudo yum -y install docker-io

2) Debian/Ubuntu

sudo apt-get update 
sudo apt-get install docker.io 
sudo sudo apt-get install lxc-docker

3) Download con Curl

sudo curl -sSL https://get.docker.io/ubuntu/ | sudo sh

* Linkiamo docker alla nostra bash

ln -sf /usr/bin/docker.io /usr/local/bin/docker
sed -i '$acomplete -F _docker docker' /etc/bash_completion.d/docker.io

* Rendiamo docker attivo all’avvio

update-rc.d docker.io defaults

P.S.: Ci sono molti contenitori già disponibili nella community docker, che possono essere trovati attraverso una ricerca. Ad esempio con questo comando cerchero’ la parola debian:

# docker search debian

NAME    DESCRIPTION      STARS     OFFICIAL   AUTOMATED
debian  Debianbaseimage  310         [OK]
google/debian            31                     [OK]

….e molte altre che potrete leggere dall’output completo.

** Installiamo e facciamo provisioning con una immagine Centos

# docker pull blalor/centos  # GitHub blalor/docker-centos-base  image

oppure per chi fosse interessato ad una immagine con gia inserito il tool Ansible (per il Configuration Management ed IT Automation) di cui ho da poco parlato, potra’ scegliere quest’altra immagine.

sudo docker pull ansible/centos7-ansible # GitHub Ansible on Centos7
Pulling repository ansible/centos7-ansible
fff2afd18a57: Download complete

Avviamo un container docker

Attiveremo ora un contenitore centos-base con una shell bash, utilizzando il comando run. Docker eseguira’ questo comando in un nuovo contenitore, -i attribuisce stdin e stdout, -t assegna un terminale.

docker run -i -t centos /bin/bash

Questo è tutto! Adesso stai usando una shell bash all’interno di un contenitore centos.
Per scollegarsi dalla shell la sequenza di escape e’ : Ctrl-p + Ctrl-q.

Diamo un’occhiata ai processi attivi tramite :

# docker ps -a
CONTAINER   ID IMAGE          COMMAND     CREATED
fff2afd18a57     blalor/centos     /bin/bash         About an hour ago

Il Dockerfile
Per automatizzare la procedura di creazione e modifica di un container docker, possiamo utilizzare il Dockerfile, che è una delle parti principali di Docker, infatti attraverso il Dockerfile è possibile non solo fare il deploy istantaneo automatizzato di più istanze e più container, ma è anche possibile eseguire il provisioning di queste istanze, automatizzando task di gestione del sistema, installazione del software e molto altro.

Nel prossimo articolo vedremo un esempio utile, utilizzando ad esempio un’applicazione leggera, che puo’ lavorare molto bene in un contenitore, come NGINX, il noto server web/cached per la gestione di siti web/proxy ad alto carico.

#DockerContainerAvviato

NGINX ecco le ragioni per cui dovreste usarlo

nginx fast web servernginx (pronunciato come “engine-x”) è un web server/reverse proxy leggero ad alte prestazioni; è anche un server proxy di posta elettronica (IMAP / POP3), rilasciato sotto licenza BSD-like. Funziona su sistemi Unix, Linux, varianti di BSD, Mac OS X, Solaris e Microsoft Windows.

 

nginx fornisce rapidamente i contenuti statici con un utilizzo efficiente delle risorse di sistema. È possibile distribuire contenuti dinamici HTTP su una rete che utilizza i gestori FastCGI (ad esempio php5-fpm, php-fastcgi) per gli script, e può servire anche come un bilanciatore di carico software molto capace.

nginx utilizza un approccio asincrono basato su eventi nella gestione delle richieste in modo da ottenere prestazioni più prevedibili sotto stress, in contrasto con il modello del server HTTP Apache che usa un approccio orientato ai thread o ai processi nella gestione delle richieste.

nginx è più leggero e meno dispendioso di memoria rispetto ad Apache e già questo è un punto a favore del web server russo. Poi, nonostante sia più compatto, garantisce prestazioni migliori rispetto al concorrente, infatti con un bassissimo utilizzo di risorse, nginx garantisce tempi di risposta eccellenti anche in presenza di un numero molto elevato di connessioni concomitanti e, con un’occupazione di memoria pari a un quarto di quella pretesa da Apache, nginx è capace di garantire fino a quattro volte il numero di connessioni contemporanee gestite dal concorrente. Di fronte a questa verità, siti ad alto traffico come WordPress.com, YouTube e tanti altri non potevano non effettuare il cambio e spostarsi su nginx.

Secondo il Web Server Survey Netcraft di febbraio 2014, nginx è risultato essere il terzo server web più utilizzato in tutti i domini (15,00% dei siti esaminati) e il secondo server web più utilizzato per tutti i siti “attivi” (13,46% dei siti esaminati).

Una cosa importante da capire, comunque, è che nginx possiede un’architettura event-based ovvero, detta in modo semplice, non necessita di effettuare la creazione di tanti processi per quante richieste siano in esecuzione, ottimizzando l’uso di memoria al contrario di Apache che, in certi casi, può provocare problemi di memoria su WordPress o altri CMS. Apache usa infatti un thread per connessione, mentre nginx lavora in modo asincrono con thread non bloccanti, il che riduce l’uso di RAM ed ottimizza l’esecuzione dei processi.

Una delle caratteristiche che più colpisce di nginx è la capacità di supportare nativamente il load balancing, per cui possiamo utilizzare questa tecnica per scalare velocemente i server HTTP. Con il load balancing di nginx possiamo distribuire il traffico fra differenti server, definiti in un gruppo nel file “nginx.conf”, in questo modo, ad esempio, se in un particolare momento operativo dobbiamo aggiungere un nuovo webserver al nostro stack LAMP, possiamo semplicemente inserirlo nel gruppo di server gestito dal file nginx.conf. In seguito al reload della configurazione (nginx -s reload), nginx effettuerà le operazioni di load balancing fra tutti i server indicati nel file di configurazione, compreso l’ultimo appena inserito.

Anche l’installazione di nginx è semplicissima e si può effettuare da qualsiasi shell-bash con una sola riga di comando. Nello specifico sulle distribuzioni Ubuntu e Debian scriveremo:

apt-get install nginx

mentre per CentOS, Red Hat Linux Enterprise e Fedora digiteremo:

yum install nginx

Caratteristiche HTTP di base

  • Gestione dei file statici, file di indice, e auto-indicizzazione
  • Reverse proxy con caching
  • Bilanciamento del carico
  • Tolleranza agli errori
  • Supporto SSL
  • Supporto FastCGI con il caching
  • Server virtuali basati su nome ed IP
  • Streaming FLV
  • Streaming MP4, utilizzando il modulo streaming MP4
  • Autenticazione di accesso nelle pagine web
  • Compressione gzip
  • Capacità di gestire più di 10000 connessioni simultanee
  • Riscrittura degli URL
  • Log personalizzato
  • include server-side
  • resistente agli attacchi di Slowloris
  • WebDAV

Nel prossimo articolo inizieremo a vedere in modo dettagliato quali siano le migliori configurazioni.