Il miracoloso NodeJS

piattaforma Open Source event-driven

NodeJS – una piattaforma Open Source event-driven

Ok, ammetto che fino a non molto tempo fa mi ero quasi scordato di Javascript, nonostante fosse stato uno dei primi linguaggi da me studiati, nel lontano 1997, quando mi approcciai al mondo del web; negli anni successivi pero’, non essendo io uno sviluppatore, le tecnologie di gestione e deploy dei server web che dovevo gestire si erano spostate verso un grande quantitativo di linguaggi, in particolare per la parte back-end , passando cosi dal php, perl, python, java, ruby, lua etc……

Come stavo dicendo, per me javascript era rimasto in sordina come un linguaggio di scripting che intercorreva tra l’hmtl ed il css, nella composizione piu’ o meno dinamica di una pagina web ,prima che i pesi massimi sopra citati entrassero in campo per svolgere il duro lavoro.

Poi, un giorno, a ciel sereno……BOOOOOOOMMMM ! scopro l’esistenza di NodeJS, ed iniziai a chiedermi a cosa si dovesse tutto l’interesse di cui stavo leggendo; scopro quindi che NodeJS e’ una piattaforma Open Source event-driven per l’esecuzione di codice JavaScript Server-side, costruita sul motore V8 di Google Chrome. Mmmmhhhh, ok bene, ma quindi? cosa fa?

Ebbene questa piccola rivoluzione creata da Google consente agli sviluppatori di realizzare web application con JavaScript non più solo lato client, ma anche sfruttandolo come linguaggio di programmazione lato server.

E gli sviluppi sono davvero moltissimi, cosi tanti che mettere un’elenco sarebbe noioso e stancante ma, tanto per farne uno molto odierno, con NodeJS possiamo, ad esempio, realizzare dei ChatBot.

Ma qual’e’ dunque il funzionamento che lo rende cosi appetitoso? Innanzitutto partiamo dal dire che Node funziona con una logica a eventi: quando un evento viene generato, allora viene eseguita un’azione. Grazie a questa tecnica non bisogna attendere che le istruzioni precedenti siano terminate, rendendo cosi il tutto molto veloce.

Nella pratica, non c’e’ bisogno di sapere come funziona il V8 per poter utilizzare NodeJS, basti sapere che e’ l’interprete javascript piu’ veloce al mondo, poiche’ e’ stato altamente ottimizzato utilizzando un tipo di programmazione JIT (Just In Time), che trasforma rapidamente il codice javascript in linguaggio macchina.

Ma la cosa che, almeno a parere personale, mi ha maggiormente colpito, e’ stato quello che possiamo chiamare come “Modello non bloccante” , questo si basa sul concetto degli eventi, ma per meglio chiarire dovremmo spiegare un minimo la differenza tra modello bloccante e NON bloccante.

Immaginiamo di dover creare un programma che ci permetta di scaricare un file da internet e che alla fine dell’esecuzione del download ci mostri un messaggio.

Bene, con il modello classico (bloccante) basato sulla programmazione sincrona potremmo schematizzare il processo nel seguente modo:

  • Scarica il file
  • Mostra il messaggio
  • Fai qualcos’altro

Ci aspetteremmo quindi che le azione vengano eseguite in ordine, leggendo le operazioni da eseguire dall’alto verso il basso.

Nel sistema asincrono di NodeJS invece le operazioni verranno svolte nel seguente modo:

  • Scarica file
  • Fai qualcos’altro
  • Mostra il messaggio

Perche’ questa diversita’ nell’esecuzione rende il tutto piu’ veloce e performante? Beh perche’ mentre il sistema effettua il download del file, il programma non rimane in attesa che il processo venga portato a termine ma anzi nell’attesa il programma esegue altre operazioni.

Il codice in oggetto avra’un aspetto tipo questo:

request(‘http://www.site.com/file.zip’, function (error, response, body) {
console.log(“Download completato!”);
});

console.log(“Mentre aspetto eseguo il resto del codice…”);

Quello appena descritto qui sopra e’ un’esempio di procedura di callback 

Ok ma se non fosse ancora del tutto chiaro, proviamo ancora a spiegare perche’ le callback sono cosi importanti, procediamo con l’esempio di prima ed aggiungiamo una difficolta’; adesso i file da scaricare sono diventati due, dunque nel sistema sincrono il programma procederebbe nel seguente modo:

  • Scarico primo file
  • Attendo che finisca
  • Scarico secondo file
  • Attendo che finisca
  • Mando messaggio

La grande differenza in questo esempio sarebbe che con NodeJS verrebbero lanciati entrambi i download, nello stesso momento, permettendo gia cosi un piu’ veloce download e, nel frattempo il programma e’ in grado di svolgere eventuali altri compiti. Ma questo come dicevo e’ soltanto un esempio, invece di un download multiplo, potrebbero essere delle query ad un DB, o la richiesta di dati a servizi esterni tramite API (Facebook, Twitter).

Pensiamo quindi ad un sistema come Facebook, che riceve X richieste di Like ogni tot secondi e vengono cosi aperti N operatori che devono attendere il loro turno per fare la modifica (del like) consumando comunque energie anche mentre sono fermi in attesa; invece NodeJS nella stessa situazione di richiesta di “reaction” sul sisto di FB (like o altro) si comporterebbe nel seguente modo:

metterebbe tutte le richieste in ordine di arrivo, prenderebbe la prima e, vedendo che si tratta di una sfilza di input le inserirebbe all’interno del sistema e, una volta capito che si tratta di stesse azioni (ad esempio che aggiungono un Like) che devono contattare un DB, NodeJS contatta il DB e invece di attendere per effettuare ogni singola modifica, aggancia alla richiesta una callback, per ogni richiesta di modifica, tutti uno dietro l’altro. Quando il DB finisce la prima modifica scatta la callback e NodeJS restituisce all’utente l’avvenuta modifica della pagina e cosi via, gestendo quindi con un solo operatore le N richieste di modifica del Like invece di crearne uno per ogni richiesta e parcheggiandoli tutti in attesa della loro singola modifica. Quindi con un server (magari anche un container con Docker) e con poche risorse possiamo gestire un’enorme quantita’ di richieste al secondo.

Inoltre NodeJS usa come sistema di pacchetti e librerie l’NPM, ma di questo fantastico sistema di librerie parleremo in un’altro articolo.

Nel prossimo articolo su NodeJS parleremo anche di 5 nuovi framework ottimi per chi si occupa di sviluppare.

#NodeJS

 

A tutta velocita’ con PHP-FPM

PHP-FPM Very Fast

Come sa bene chiunque si occupi di creare e gestire un servizio Web moderno, il primo aspetto che viene ricercato e di cui si chiede la massima affidabilita’, e’ la velocita’ di risposta, cosi da garantire la presenza online delle imprese supportando il lavoro quotidiano delle Web Agency.

Nonostante oggi giorno ci siano nuovi linguaggi di sviluppo e di scripting il PHP rimane comunque ancora uno dei piu’ utilizzati e, grazie alle nuove funzionalita’ del PHP-FPM, questo linguaggio tornera’ sicuramente ad avere un ruolo di rilievo.

Ma, facciamo un piccolissimo passo indietro per rivedere come sono state gestite fino a ieri tutte le richieste php fatte dagli utenti ai vostri siti.

La maggior parte degli amministratori di siti sa che il PHP può essere incorporato nell’ HTML e che funziona con i principali web server. Tuttavia, l’aspetto meno conosciuto è la modalità con cui può essere eseguito il PHP sul web server, e questo può avvenire in diversi modi.

Aggiungiamo nell’equazione anche l’acronimo LAMP che, per chi non lo conoscesse, indica una piattaforma software per lo sviluppo di applicazioni web e sta per :

  • Linux (il sistema operativo)
  • Apache (il server web)
  • MySQL o MariaDB (il database management system)
  • PHP (il linguaggio di programmazione)

Come stavamo dicendo, fino a ieri  la modalità con cui si eseguivano le richieste e i processi di php sulla piattaforma LAMP era il PHP FastCGI.

Si tratta di un protocollo generico utilizzato per l’interfacciamento con un server web. Nello specifico è una variante della precedente Common Gateway Interface (CGI) che ha come obiettivo quello di ridurre il sovraccarico associato all’ interfacciamento tra web server e programmi CGI, consentendo ad un server di gestire più richieste contemporaneamente.

Ma con FastCGI è possibile configurare più versioni di PHP, cosa particolarmente utile quando si hanno vecchi siti web creati, ad esempio, in PHP 5.1 che non sono compatibili con l’ultima versione, inoltre, con FastCGI è possibile supportare diversi utenti ognuno con le proprie istanze di PHP. Questa funzione è particolarmente importante per migliorare la sicurezza in un ambiente condiviso, in cui è possibile avere utenti diversi che gestiscono ciascuno i propri siti web.

Andiamo ancora avanti, quindi grazie al protocollo PHP FastCGI il webserver genera un’ unico processo in fase di inizializzazione che, al termine della fase di start-up, si mette in attesa. Ogni volta che arriva una nuova richiesta in ingresso, il webserver apre una connessione con il processo fast-cgi (in attesa) che a sua volta genera l’output sulla connessione con il client, trasferitagli dal server. Il vantaggio principale di questo protocollo è la creazione dei processi solo in fase di inizializzazione, ottimizzando così il numero dei processi php.

Bene, quindi cerchiamo di capire adesso che cosa cambia con l’introduzione di PHP-FPM ?

PHP-FPM è una modalità più recente (nato nel 2004 come patch di PHP) di utilizzare PHP con un server web, ed è un’alternativa al precedente PHP FastCGI con l’implementazione di alcune funzionalità aggiuntive molto utili, in particolare ai siti che gestiscono quotidianamente sempre più traffico (dai siti vetrina agli e-commerce). Per queste tipologie di siti web è sempre piu’ necessario avere a disposizione strumenti sempre più performanti, proprio come il PHP-FPM.

Fino ad oggi una delle grosse mancanze di FastCGI è stata l’impossibilità di avere un numero di CHILD (processi) PHP che cambi in modo dinamico a seconda delle richieste effettive.

Nel suo insieme, il funzionamento è molto simile al FastCGI e si basa dunque sull’ esecuzione ottimizzata dei processi php che vengono creati solo in fase di inizializzazione e rimangono in attesa di una nuova richiesta. La grossa differenza sta nel fatto che è lo stesso PHP-FPM ad eseguire il processo e non più il web server.

Il “Process Manager” è uno script che gestisce direttamente i processi PHP, nella pratica attende e riceve istruzioni dal server web ed esegue gli script PHP richiesti, permettendo cosi ad un sito web di gestire carichi intensi. Il PHP-FPM mantiene dei “pool” per rispondere alle richieste PHP e i processi che si generano sono direttamente “figli” (CHILD) del Process Manager e possono quindi essere gestiti separatamente dal web server.

Questa modalità garantisce una maggiore robustezza del servizio, poiché tutte le operazioni come i cambi di configurazione o il restart dei processi, impattano i singoli pool FPM e non più l’intero web server.

Ecco alcune delle interessanti caratteristiche tecniche:

  • Demonizzazione dei processi PHP (file PID, file log, setsid(), setuid(), setgid(), chroot();
  • Possibilità di riavviare i processi PHP senza causare alcuna interruzione delle richieste in fase di processamento, si potra’ quindi cambiare qualsiasi parametro nel file di configurazione o addirittura aggiornare PHP senza avere nemmeno 1 secondo di downtime;
  • Possibilità di non processare le richieste provenienti da un determinato IP;
  • Possibilità di avviare i CHILD sotto differenti UID/GID/CHROOT e con differenti impostazioni di PHP (php.ini) il tutto senza bisogno di safe mode;
  • Possibilità di loggare tramite stdout e stderr;
  • In caso di corruzione della memoria RAM condivisa utilizzata da un OPCode Cache, PHP-FPM può effettuare un riavvio di emergenza di tutti i CHILD PHP;
  • Forza l’arresto dell’esecuzione di uno script nel caso in cui set_time_limit() avesse dei problemi.

Secondo un recente articolo pubblicato su CloudWays, effettuare uno switch da mod_php a PHP-FPM permetterebbe, tra i tanti vantaggi attesi, di ridurre del 300% i tempi di caricamento delle Web Application a traffico elevato.

NGROK – reverse proxy server cross-platform

ngrok mostrare un sito in locale

Ngrok Pubblica il tuo sito in localhost

Lo sviluppo di siti e di Webb Application e’, al giorno d’oggi, uno dei core business piu’ importanti per la maggior parte delle aziende in tutto il mondo, motivo per cui sono nati una grande quantita’ di tool per agevolare i web developer durante tutte le operazioni di sviluppo, test e produzione.

Molto spesso capita che non si abbia il tempo o anche il budget per gestire piu’ ambienti di sviluppo, cosi ci si riduce per avere tutto il proprio ambiente [sviluppo / test / pre produzione] soltanto sul proprio pc.

Come fare quindi se c’e’ bisogno di mostrare l’avanzamento del lavoro al cliente senza dover prima creare e/o aggiornare gli altri ambienti di test/pre-produzione??? …. e’ per aiutare in questa pressante fase che e’ nato un tool come ngrok.

Ngrok e’ un reverse proxy server con cui e’ possibile rendere “pubblico” un server locale, anche se e’ collocato dietro un NAT od un Firewall, il tutto tramite secure tunnel. Quindi attraverso Ngrok si potra’ implementare un personal cloud service direttamente dalla propria postazione di lavoro realizzando cosi uno stack LAMP/LEMP

 

INSTALLAZIONE

mkdir ngrok
cd ngrok/
wget -c https://bin.equinox.io/c/4VmDzA7iaHb/ngrok-stable-linux-amd64.zip
unzip ngrok-stable-linux-amd64.zip

Dopo aver installato il pacchetto possiamo fare una prova, se ad esempio usate come web server Apache, potete farlo in questo modo;

sudo nano /var/www/html/index.html

<!DOCTYPE html> <html> <body> <h1>Prova</h1> <p>Test di Ngrock.</p> </body> </html>

Salviamo il file e ora possiamo avviare il tool puntandolo sulla porta su cui abbiamo in ascolto il nostro Web server:

ngrok http 80

Una volta lanciato il comando ci apparira’ qualcosa di simile:

Session Status online Session Expires 7 hours, 53 minutes
Version 2.2.8 Region United States (us)
Web Interface http://127.0.0.1:4040
Forwarding http://44c9afca.ngrok.io -> localhost:80
Forwarding https://44c9afca.ngrok.io -> localhost:80

Una volta avviato possiamo dunque iniziare ad usarlo anche tramite la comoda interfaccia Web:

http://localhost:4040

ngrok localhost

Tornando alla descrizione del Tunnel appena creato, le voci a cui dobbiamo fare caso sono:

  • Web Interface: tramite questo indirizzo potrai accedere ad un’interfaccia web dove puoi monitorare tutte le attività associate all’url che hai appena creato. Questo vuol dire che potrai vedere quanti utenti si stanno collegando ed altre informazioni.
  • Forwarding: questo è il link che dovrai fornire al tuo cliente. Hai entrambe le versioni, sia http che https. Lavorando in locale probabilmente userai quasi sempre l’http.
  • HTTP Requests: In questa sezione vedrai in tempo reale tutte le richieste http che vengono fatte tramite il tuo link. Ti è utile per capire se qualcuno sta guardando il sito in un dato momento.

Quindi dando al proprio cliente il link http://44c9afca.ngrok.io  quest’ultimo avra’ accesso alla root web del localhost

Questo vuol dire che se stai utilizzando MAMP o XAMPP verrà servito il file index.php all’interno della tua cartella /htdocs

Se invece utilizzi WAMP su Windows il tuo tunnel porterà gli utenti alla index.php della cartella www

Per coloro che utilizzano un Virtual Host per gestire i tuoi progetti la procedura e’
leggermente diversa ma pur sempre semplice; nella pratica bastera’ aggiungere un solo
parametro, come nell’esempio seguente:

ngrok http -host-header=miosito.dev 80

dove ovviamente al posto di “miosito.dev” metterete l’indirizzo del vostro in locale. ** WordPress per coloro che invece usano la piattaforma di WordPress si dovranno applicare altri accorgimenti per far in modo che il vostro cliente veda correttamente il sito. Questo perche’ tutti gli url che creati da WordPress sono assoluti ovvero mostrano per esteso l’indirizzo di un determinato documento. Per poter effettuare questo tipo di modifica consiglio di utilizzare un comodo tool come Relative URL , un tool che fa gia parte dei plugin consigliati da WordPress, con il quale sara’ possibile modificare URL da qualcosa come questo (esempio):

http://localhost:8080/wp/2012/09/01/hello-world/

in qualcos’altro come questo:

/wp/2012/09/01/hello-world/

Una volta effettuate tutte le modifiche del caso bisognera’ aggiornare il file wp-config.php
inserendo, prima della riga “/* i parametri dei re indirizzamenti, qualcosa del tipo:

define('WP_SITEURL', 'http://' . $_SERVER['HTTP_HOST']);
define('WP_HOME', 'http://' . $_SERVER['HTTP_HOST']);

PS:Ricordatevi di disinstallare il plugin e rimuovere le righe di codice dal file wp-config.php quando metterete il sito online.

Le configurazioni possibili con Ngrok sono davvero svariate e potete trovare tutto cio che non e’ stato contemplato in questo articolo, direttamente sul sito del progetto NGROK

GO il nuovo linguaggio web di Google

Google-GO

Google-GO new Web language

Che cosa è Go?
Go (chiamato anche GoLang) è un linguaggio di programmazione realizzato da Google. La progettazione è cominciata nel 2007. Tra gli ideatori del linguaggio ci sono anche nomi come Ken Thompson, Rob Pike, Robert Griesemer (i primi due sono stati anche tra i creatori del sistema operativo Unix). Il progetto è stato annunciato pubblicamente nel novembre 2009, e la versione 1.0 è uscita nel marzo 2012.

 

Le caratteristiche di Go
Go è un linguaggio statically-typed, significa che la verifica dei tipi di variabili è effettuata durante la compilazione (cosi come accade per C, Java, Scala e Pascal) e non durante il run-time (come accade per JavaScript, PHP, Python e Ruby).
Go soddisfa le esigenze della programmazione concorrente ed è stato progettato per ottimizzare i tempi di compilazione anche per hardware modesti. La sintassi è vicina al C eccetto per la dichiarazione dei tipi e per la mancanza di parentesi tonde nei costrutti for e if. Ha un sistema di garbage collection che si occupa autonomamente della gestione della memoria. Non include l’intercettazione di eccezioni, l’eredità dei tipi, la programmazione generica, le asserzioni e l’overloading dei metodi.

 

Go, linguaggio ideale per i webservices
Come accennato poco sopra, Go nasce come linguaggio generalista, ma negli ultimi anni di sviluppo si è affermato come linguaggio ideale per i webservices. Il motivo di questo successo si deve principalmente a tre aspetti:

  • facilità di deployment,
  • efficienza nell’uso della memoria,
  • gestione della concorrenza

Facilità di deployment
Rispetto ad altri linguaggi, Go ci permette di effettuare un server deployment estremamente semplice. Sulla macchina di produzione non è dunque necessario installare alcun webserver (Apache o Nginx), alcuna Virtual Machine (come in Java), alcun tipo di wrapper (come l’WSGI per il Python) e neppure nessuna componente del linguaggio Go.
Sara’ sufficiente copiare l’eseguibile Go e farlo girare sul server come un normale servizio.

Il file eseguibile di Go contiene gia tutto al suo interno:

  • il codice, il Go runtime,
  • il webserver,
  • eventuali libraries

Le dimensioni sono cosi’ particolarmente ridotte, in genere intorno ai 10 MB, ed i tempi di compilazione sono tra l’altro immediati, tipicamente meno di 1 secondo, ed è possibile fare cross-compilation da e per qualunque tipo di sistema operativo: Linux, Mac, Windows.

 

Efficienza nell’utilizzo della memoria
In termini di efficienza nell’utilizzo della memoria, Go è comparabile al linguaggio C, eliminando però molta della complessità tipica del C, utilizzando pattern di programmazione più solidi e intuitivi. Il garbage collector in Go è estremamente performante e, dalla versione 1.5 (oggi Maggio 2017 siamo alla versione 1.8.3) ha raggiunto una latenza molto vicina allo zero.

Comparata a quella di Java, l’impronta in memoria di Go è una frazione minuscola. Questo permette alle applicazioni scritte in Go di essere, oltre che semplici da scrivere, anche estremamente performanti, e di richiedere risorse hardware molto ridotte, ottimo ad esempio per ambienti su Docker.

 

Concurrency
Il fiore all’occhiello di Go è necessariamente l’estrema facilità con cui si possono scrivere applicazioni che utilizzano codice concorrente. Infatti, oltre ad essere sintatticamente semplici da scrivere, sono anche estremamente performanti. Nessun’ altro linguaggio di programmazione si avvicina a Go in questo aspetto.

La concorrenza in Go si può implementare in due modi: tramite i canali, che si ispirano alle teorie CSP (Communicating Sequential Processes) di C. Hoare, e tramite le goroutines, funzioni che possono essere eseguite in modo concorrente anche nell’ordine di molte migliaia.

Go inoltre offre uno strumento molto efficace per identificare eventuali data-race, ossia le situazioni in cui due
go-routine accedono alla stessa variabile in modo concorrente e almeno uno dei due accessi è in scrittura.

Altra novità molto interessante: Go è uno dei linguaggi ufficiali per la programmazione su Google App Engine – il servizio PaaS (Platform-as-a-Service) del Cloud di Big G – oltre a Python, PHP e Java. Proprio in questi giorni è stato annunciato che il supporto per Go sulla piattaforma non è più in fase beta ma risulta disponibile tra i servizi GA (Generally Available).

 

Non resta che provare ad adattarlo alle nostre esigenze !.

 

 

OpenStack – Introduzione

OpenStack Cloud Software

OPENSTACK – PARTE PRIMA

Si parla molto di OpenStack e delle sue applicazioni. Ma che cos’è davvero, perché è stato sviluppato e quali sono i suoi vantaggi?

Che cos’è?
OpenStack è un sistema operativo per il cloud computing in grado di controllare componenti di storage, networking e computing. È open source e gratuito, di solito è installato sotto forma di soluzione IaaS. OpenStack fornisce un insieme di strumenti che servono a costruire e gestire piattaforme cloud sia pubbliche sia private. Permette agli utenti di installare macchine virtuali e si può accedere al codice sorgente per modificarlo in qualsiasi modo sia utile per gli scopi specifici del progetto.

Chi lo ha sviluppato?
Nel 2010 Rackspace e la NASA hanno collaborato a un progetto congiunto che è poi diventato OpenStack. Il codice iniziale è stato usato per Nebula, la piattaforma cloud della NASA, poi il progetto si è dato l’obiettivo più ampio di aiutare le aziende a far girare software cloud su hardware standard.

Chi lo usa?
Tra i vendor, alcuni dei nomi più importanti che attualmente supportano e distribuiscono OpenStack sono Canonical, Cisco, EMC, HP, Huawei, IBM, Oracle, Google e Red Hat. Tra gli utenti attuali ci sono Bloomberg, Comcast, PayPal e Wells Fargo. Ci sono incontri internazionali periodici su OpenStack – gli OpenStack Summit – in tutto il mondo, che raccolgono programmatori e utenti della piattaforma.

E’ quindi ormai innegabile l’interesse che tutto il mondo IT ha riservato in questi ultimi anni ad OpenStack.

Qual’è la ragione di tutto questo?

L’ormai tradizionale paradigma client-server, in progetti in cui la scalabilità e le finestre di picchi di carico sono variabili essenziali all’interno dell’equazione della produttività, presenta oggi giorno evidenti limiti di gestione dei carichi e della velocita’ di evoluzione dei progetti. Ecco quindi nascere l’esigenza di uno strumento che fosse flessibile ed allo stesso momento affidabile.

Questo concetto spiega quindi le motivazioni che possono spingere ad adottare una piattaforma cloud, ma perché fra tutte le piattaforme esistenti si parla sempre di OpenStack?

OpenStack è un progetto aperto
La sua natura aperta ha fatto sì che tutti i vendor interessati all’introduzione di specifiche funzionalità o determinati ambiti potessero contribuire in maniera attiva e funzionale al progetto, innescando un circolo virtuoso in cui ogni miglioramento apportato per favorire se stessi va a beneficio della comunità.

La sua natura aperta fa sì che chi adotta OpenStack per il proprio ambiente cloud è di fatto esente dal cosiddetto vendor lock-in, ossia l’essere vincolato ad un rivenditore specifico per le proprie tecnologie. Infatti se lo standard OpenStack è garantito, ogni venditore potrà essere valutato in modo paritetico a tutti gli altri, rendendo così il mercato più competitivo e conveniente per il cliente finale.

I presupposti di un progetto OpenStack

Bisogna subito tenere presente che “non tutti i progetti sono adatti al cloud“, nonostante cio che viene erroneamente interpretato leggendo in giro per il web, infatti questo principio sfugge a molti che guardano verso le nuvole vedono unicamente un posto differente da cui erogare i propri servizi. Esistono dei requisiti da tenere presente per capire se un progetto è adatto al cloud.

Un progetto OpenStack quindi deve essere:

** Non persistente: non deve basarsi sulla persistenza dei dati all’interno delle macchine coinvolte. Questo aspetto non va confuso con l’esigenza di avere uno storage solido e sicuro, si tratta invece di non giudicare le istanze che concorrono al progetto come perenni, ma come componenti utili al loro scopo e liberamente sacrificabili;

** Scalabile: deve supportare applicazioni che nativamente siano in grado di scalare. L’applicazione nasce già dallo sviluppo come pensata per il cloud;

** Dinamico: a fronte di un innalzamento delle richieste ricevute il progetto deve essere in grado in maniera autonoma di gestire le nuove componenti. Gli interventi manuali successivi all’implementazione sulle istanze coinvolte devono essere inesistenti;

** Rapido: deve essere passibile di provisioning, favorendo la velocità di creazione (e distruzione) di nuove istanze;

Se il vostro progetto risponde a questi requisiti messi in evidenza qui sopra, allora potete pensare ad integrare OpenStack ed è giunto quindi il momento di capire in cosa consiste.

Le componenti di OpenStack

La parola stack descrive un insieme di entità che concorrono ad uno scopo comune. OpenStack è composto da numerose elementi che devono comunicare fra loro, lo strato di comunicazione passa attraverso due filoni fondamentali: la memorizzazione delle informazioni e la coda delle azioni da svolgere. Queste due azioni sono coperte ciascuna da un elemento specifico:

MySQL

Il database MySQL è necessario per la memorizzazione delle informazioni di configurazione generali del sistema, per la memorizzazione delle informazioni di autenticazione relative a ciascun componente e per il mantenimento dinamico dello stato del sistema.
Ogni azione eseguita all’interno dell’infrastruttura OpenStack è tracciata all’interno del database. L’importanza di questa componente è evidentemente capitale.

RabbitMQ

RabbitMQ è uno scheduler, un software didicato alla gestione delle code ed all’organizzazione delle sequenze di operazioni. Tutti i nodi facenti parte dell’infrastruttura OpenStack comunicano con lo scheduler, ed anche in questo caso è presto spiegato come questa componente ricopra enorme importanza per il regolare funzionamento dell’ambiente.

Determinato quindi il sistema di circolazione e reperimento delle informazioni si può focalizzare l’attenzione sugli elementi peculiari di OpenStack, riassunti in questo diagramma che si trova sul sito ufficiale del progetto:

OpenStack Diagramma Software

                                                     OpenStack Diagramma Software

Keystone

Keystone è il software che gestisce il sistema di autenticazione di OpenStack. Il principio su cui si fonda è quello classico degli utenti e dei gruppi, ma di fatto si occupa di gestire le tre tipologie di utenti configurabili in OpenStack:

  • Cloud Provider Admins: ossia gli amministratori del sistema OpenStack;
  • Tenants: ossia i profili delle compagnie fruitrici dei servizi;
  • Users: ossia gli utenti delle compagnie fruitrici dei servizi;

Il concetto di “compagnia” si riferisce ad un sotto-ambiente interno alla stessa installazione di OpenStack. Applicato ad un provider esso potrebbe essere rappresentato dai clienti, mentre all’interno di un cloud privato potrebbe essere associato ad un dipartimento interno.

Glance

Glance si occupa del provisioning (ossia di fornire) delle immagini all’interno dell’ambiente. Questa componente fornisce un bacino di istanze gia preconfigurate, disponibili ai fruitori dei servizi, per effettuare il deploy (ossia la messa in produzione) dell’istanza desiderata all’interno del proprio ambiente.
Le immagini sono supportate nei formati KVM qcow, Aws, VMWare purché esista su queste un Master Boot Record.

Nova

Nova è il compute service, un servizio che permette di gestire i sistemi virtuali erogati all’interno dell’ambiente. All’interno della macchina definita controller il servizio nova-api guiderà l’avvio e la terminazione delle istanze comandando la sua controparte nova-compute, attiva su tutte le macchine hypervisor facenti parte della struttura OpenStack.
Le decisioni su dove e come le istanze dovranno essere avviata saranno gestite dal servizio nova-compute-service (basato su libvirt).

Horizon

Horizon è l’interfaccia web dalla quale è possibile controllare agevolmente le istanze in modalità point-and-click oltre che le immagini gestite da Glance. Il software Horizon è basato sul modulo wsgi del webserver Apache.

C’è ancora un’ultimo aspetto da tenere presente, come è deducibile dallo schema, lo storage.
In un setup base le macchine possono essere erogate direttamente dai dischi degli hypervisor, ma in ambienti di larga scala ciò potrebbe non essere auspicabile. In questi casi fare riferimento ad un gestore dello spazio centralizzato permetterebbe di utilizzare gli hypervisor come semplici erogatori, valorizzando la scalabilità generale del progetto, ed ecco dunque venirci in aiuto questo componente per la gestione dei volumi, Cinder.

Cinder

In origine parte del progetto Nova (chiamato nova-volume) e dal 2012 progetto a se stante, Cinder è il servizio che fornisce il block storage per le istanze, uno storage gestito e centralizzato che funziona da dispositivo a blocchi per le virtual machines. Le macchine virtuali risiedono quindi su un device dedicato, definito sulla base di quello che è la modalità con cui l’hypervisor ha accesso allo storage.
Cinder supporta diverse modalità per essere visto dagli hypervisors: è possibile infatti utilizzare dischi locali o sistemi storage esterni, quali NFS, FibreChannel, DRBD o iSCSI.

Swift

A differenza di Cinder, Swift è un servizio di storage online che si occupa di rendere disponibile spazio all’interno dell’ambiente OpenStack mediante la modalità object storage. I dati non vengono registrati direttamente su dispositivi a blocchi, ma preventivamente convertiti in oggetti binari, distribuiti all’interno di più device in modo da garantirne la massima accessibilità oltre che la replica.
Swift è compatibile con il servizio di storage Amazon S3 e funziona con lo stesso principio: fornire uno storage web accessibile e scalabile.

Conclusioni

In questa lunga introduzione sono stati illustrati filosofia, componenti e soprattutto potenzialità di OpenStack, ma sebbene la lettura possa essere apparsa lunga, questa tocca appena la superficie dell’universo relativo a questo grande progetto.
Nel prossimo articolo verrà avviato un piccolo studio di fattibilità vero e proprio con lo scopo di mettere su strada tutti i vari software che lo compongono ed iniziare cosi ad adoperare OpenStack.