Archivi tag: virtualizzazione

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

Docker i Container ed i Microservices

Docker ed i Microservices

Docker ed i Microservices

Su questo portale abbiamo gia piu’ volte scritto e descritto la tecnologia che sta dietro al progetto Docker, sicuramente una delle nuove scoperte informatiche degli ultimi anni, a livello dell’uscita della Virtualizzazione; ma nonostante tutto, non sempre e’ facile capire in poche righe concetti nuovi non sempre semplici da comprendere, quindi eccovi un nuovo articolo, che fara’ parte di una piccola serie di episodi, in cui cercheremo di fare ulteriormente luce su cos’e’ e come funziona questo fantastico progetto.

Dagli script PHP ai microservice
Alla fine degli anni ’90 i siti erano per lo più ancora statici, con qualche script CGI , o altre soluzioni oggi considerate poco eleganti. Poi arrivarono ASP JAVA e PHP. Da li in avanti un progetto Web era prettamente fondato, ad esempio, su file PHP, CSS e immagini; in queste soluzioni tecnologiche era sufficiente copiare tutti questi file su uno spazio hosting e al più modificare qualche file di configurazione, per ricreare un nuovo ambiente web e ricominciare su di un nuovo sito.

Venti anni dopo gli scenari sono drasticamente diversi, le architetture SOA hanno preso piede, si è iniziato a parlare di microservice e tutto è diventato più complesso. Un’applicazione web, soprattutto in ambito enterprise, non è più la directory di cui parlavamo prima, ma un’ insieme di componenti autonomi, ognuno col suo ciclo di vita indipendente, rilasciati su macchine diverse e a ritmi sempre crescenti.

Una complessità così grande non può piu’ essere amministrata con il vecchio copia e incolla, diventa cosi’ necessario uno strumento affidabile che consenta di manipolare o spostare intere applicazioni limitando errori umani, checklist lunghissime da controllare e tutti i passaggi snervanti e carichi di rischi necessari per il deployment.

I container
Cosi’ come nell’industria dei trasporti nacque l’esigenza di una soluzione unica intercambiabile, vennero cosi creati i container: contenitori multiuso, realizzati in formati standard che possono essere passati con facilità da un camion a una nave, poi magari su un treno merci e così via.

Anche nel campo informatico abbiamo bisogno di qualcosa che “contenga” la nostra applicazione, che ci consenta di manovrarla con facilità senza sapere nulla, o quasi, riguardo il suo contenuto. In pratica, abbiamo bisogno anche noi del nostro container!

Docker
L’intuizione del team di Docker è stata quella di prendere il concetto di container e costruirvi attorno un’ ecosistema che ne semplificasse l’impiego. Di questo ecosistema fanno parte una serie di tool: Docker engine, Docker Toolbox, Swarm, Kitematic e tant’ altro ancora per rendere i container qualcosa di accessibile anche a chiunque, sfruttando anche il fatto che la community di sviluppatori che utilizza Docker è davvero molto vasta. Ad esempio, Docker Hub è un repository di container pubblici pronti per l’uso, mentre il codice sorgente del Docker engine è liberamente disponibile su GitHub e vanta quasi 1500 contributor.

Container VS Virtual Machine
Apparentemente i container e le virtual machine sembrano due concetti molto simili ma, sebbene queste due soluzioni abbiano delle caratteristiche in comune, si tratta di tecnologie profondamente diverse tra loro, così come diverso è anche il modo in cui dobbiamo iniziare a pensare all’architettura delle nostre applicazioni. Possiamo creare un container con la nostra applicazione monolitica all’interno, ma così non sfrutteremmo a pieno la forza dei container e quindi di Docker.

Una possibile architettura software adatta per un’infrastruttura a container è la classica architettura a microservizi. L’idea, in pratica, è quella di scomporre l’applicazione in tante piccole componenti ognuna col suo compito specifico ma capaci di scambiarsi messaggi e di cooperare tra loro, cio’ che e’ alla base dei sistemi SOA. Il deploy di tali componenti avverrà poi effettuato singolarmente, come tanti container.

Uno scenario come quello ipotizzato è assolutamente poco pratico con una macchina virtuale, in quanto ogni nuova macchina virtuale istanziata richiederebbe un bel dispendio di energia per la macchina host. I container, al contrario, sono molto leggeri, poiché effettuano una virtualizzazione completamente diversa da quella praticata dalle macchine virtuali.
Nelle macchine virtuali, lo strumento detto hypervisor si preoccupa di riservare (staticamente o dinamicamente) un certo quantitativo di risorse dal sistema operativo host da dedicare poi ad uno o più sistemi operativi, detti guest o ospiti, inoltre ogni sistema operativo guest sarà completamente isolato dal sistema operativo host. Questo meccanismo è molto dispendioso in termini di risorse, per cui l’idea di associare un micro-servizio ad una macchina virtuale è del tutto irrealizzabile.

I container, d’altro canto, apportano un contributo completamente diverso alla questione, l’isolamento è molto più blando e tutti i container in esecuzione condividono lo stesso kernel del sistema operativo sottostante, host. Scompare completamente l’overhead dell’hypervisor, e un singolo host può arrivare a ospitare centinaia di container.

Docker VS VirtualMachine

Docker VS VirtualMachine

Nel prossimo articolo rivedremo come installare Docker tramite i Docker-ToolBox, e come interagire con i container.
Alla prossima

Breve corso di Vagrant – Puntata 1

Vagrant Stack-LAMP

Vagrant Stack-LAMP

Dopo aver gia scritto in precedenti articoli di Vagrant ho sentito l’esigenza di metter, come si suol dire, nero su bianco un piccolo corso/progetto da portare avanti su queste pagine in cui verra’ spiegato non solo l’uso piu’ avanzato di Vagrant ma anche alcuni concetti fondamentali inerenti la creazione di un servizio WEB moderno, introducendo i concetti di “scalabilita’” e di “high availability“.

Iniziamo con un breve elenco dei comandi di vagrant usati più comunemente :
vagrant init [nome-box] [url-box] = inizializza la directory corrente come ambiente per Vagrant e crea il file di configurazione Vagrantfile
vagrant up = crea, configura e avvia la macchina virtuale definita in Vagrantfile . Se la macchina virtuale già esiste, la fa solo partire
vagrant halt <nome macchina> = ferma una macchina virtuale
vagrant destroy = elimina la macchina virtuale
vagrant ssh <nome macchina> = si collega alla macchina virtuale via ssh

Nel seguente esempio verra’ creata una directory che conterra’ il progetto di Vagrant, poi, inizializzemo il progetto, configureremo una macchina virtuale, la lanceremo e infine ci collegheròemo. I seguenti comandi creeranno una macchina virtuale con Ubuntu 14.04 (64bit). Notate che la prima volta che eseguirete questa serie di comandi, verrà scaricata dalla rete un’immagine del sistema operativo Ubuntu. Per farlo ci potranno volere svariati minuti, a seconda anche del tipo di connessione ADSL di cui disponete. Le volte successive, il processo sara’ molto più rapido, perché l’immagine usata per creare la macchina virtuale sarà già stata memorizzata nel vostro sistema.

PARTIAMO
Questi sono i primi comandi che useremo: vagrant init ubuntu/trusty64  &  vagrant up

<> vagrant init ubuntu/trusty64
A `Vagrantfile` has been placed in this directory. You are now
ready to `vagrant up` your first virtual environment! Please read
the comments in the Vagrantfile as well as documentation on
`vagrantup.com` for more information on using Vagrant.

<> vagrant up
Bringing machine ‘default’ up with ‘virtualbox’ provider…
==> default: Box ‘ubuntu/trusty64’ could not be found. Attempting to find and install…
default: Box Provider: virtualbox
default: Box Version: >= 0
==> default: Loading metadata for box ‘ubuntu/trusty64’
default: URL: https://atlas.hashicorp.com/ubuntu/trusty64
==> default: Adding box ‘ubuntu/trusty64’ (v20151214.0.0) for provider: virtualbox
default: Downloading: https://atlas.hashicorp.com/ubuntu/boxes/trusty64/versions/20151214.0.0/providers/virtualbox.box
default: Progress: 6% (Rate: 115k/s, Estimated time remaining: 0:43:23)))
==> default: Preparing network interfaces based on configuration…
default: Adapter 1: nat
==> default: Forwarding ports…
default: 22 => 2222 (adapter 1)
==> default: Booting VM…
==> default: Waiting for machine to boot. This may take a few minutes…
default: SSH address: 127.0.0.1:2222
default: SSH username: vagrant
default: SSH auth method: private key
…………..etc etc !!

> vagrant ssh
Welcome to Ubuntu 14.04.3 LTS (GNU/Linux 3.13.0-73-generic x86_64)

* Documentation: https://help.ubuntu.com/

System information disabled due to load higher than 1.0

Get cloud support with Ubuntu Advantage Cloud Guest:
http://www.ubuntu.com/business/services/cloud

vagrant@vagrant-ubuntu-trusty-64:~$ ifconfig
eth0 Link encap:Ethernet HWaddr 08:00:27:6b:55:0f
inet addr:10.0.2.15 Bcast:10.0.2.255 Mask:255.255.255.0
inet6 addr: fe80::a00:27ff:fe6b:550f/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:544 errors:0 dropped:0 overruns:0 frame:0
TX packets:392 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:69053 (69.0 KB) TX bytes:53324 (53.3 KB)

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)

vagrant@vagrant-ubuntu-trusty-64:~$ exit

Dato che il nostro obiettivo è arrivare ad avere uno Stack LAMP, sappiamo che dovremo tenere conto di dover ancora installare e configurare gli altri software necessari ossia,  Apache, MySQL e PHP. Ci sono però anche altri componenti meno ovvi di cui va tenuto conto. Iniziamo studiando lo stack LAMP su di un modello di web application 2.0. Vediamo quindi di spiegare alcuni concetti fondamentali per questo tipo di architetture che vanno decisi prima d’iniziare a creare fisicamente le macchine/server che ci servono.

Scalabilità VS Disponibilità

Scalabilità verticale
Si può scalare un sistema senza aumentarne la disponibilità o il tempo di uptime. Esemplifichiamo, diciamo che vogliate gestire più utenti, più traffico e più carico per l’applicazione web, se si tratta di un server fisico, potreste spegnerlo, installare più memoria e potenziare la CPU, ad esempio. Potreste anche copiare tutti i dati da un solo piccolo server ad un server più grande che abbia più memoria, una CPU più potente e dischi più veloci. Se invece state usando un server virtuale, potreste fermarlo, allocare maggiori risorse e riavviarlo. Se il server è posizionato nel cloud, potrete cambiare il tipo di istanza ad uno che abbia più risorse. Questo si chiama scalare verticalmente. Non c’è niente di male in questo tipo di scalabilità, soprattutto se avete applicazioni in cui il tempo di fermo e’ accettabile.

Scalabilità orizzontale
Un’ altro modo per scalare è di aggiungere altri server, che a volte vengono indicati con il termine di nodi. Questo si chiama scalabilità orizzontale. Per scalare orizzontalmente, si deve fare prima un po’ di lavoro in anticipo, e progettare bene la transizione. Per andare ad esempio da un server web a due, dovrete trovare un modo per instradare il traffico al nodo aggiuntivo, e preferibilmente suddividere il carico tra i due server. Se vi servono più risorse, aggiungete un terzo server,  un quarto, un quinto e cosi’ via. Quando invece avete un solo server, e questo va giù, il servizio si interrompe, ma se avete più di un server che fanno gestiscono la stessa funzione, e uno di loro ha un malfunzionamento, lo scenario peggiore è che il servizio è degradato e non altrettanto prestante come di solito. Lo scenario migliore avviene quando un singolo malfunzionamento non viene nemmeno notato.

Il meglio di entrambi i mondi
In molti casi ha senso scalare il server web in modo orizzontale, e il server di database in modo verticale. Vedremo piu’ avanti, nei prossimi articoli, come prendere il meglio di entrambi i mondi, eliminando, o almeno riducendo moltissimo, il tempo di fermo per il servizio.

Nel secondo capitolo inizieremo la configurazione del file Vagrant per la preparazione delle 5 macchine necessarie al nostro progetto.

Stay Tuned !

CoreOS nuova rivoluzione nel Cloud

CoreOS new Cloud System

CoreOS new Cloud System

Poco tempo fa ho pubblicato un breve articolo introduttivo riguardante CoreOS ed il suo uso nei DataCenter, ma in pratica cos’ha di così interessante CoreOS ? Lo sviluppatore di CoreOS, Alex Polvi, è partito da ChromeOS, il sistema operativo sviluppato da Google intorno al browser Chrome, per ottenerne molto di più.

Dunque, partendo da questo presupposto si potrebbe affermare che CoreOS e’ in definitava una distribuzione Linux pensata per gli ambienti server, ma a differenza dei prodotti Linux-based già riservati al settore server ed enterprise, CoreOS prevede solo il kernel di Linux ed il systemd, ossia il gestore dei processi per avviare i servizi essenziali all’inizializzazione del sistema.

In pratica questo sistema operativo è pensato per i clienti che devono avviare e gestire cluster di centinaia di server e si inserisce quindi come un server Linux per le distribuzioni ad alto volume di dati e di traffico (IaaS, PaaS, SaaS). In maniera molto semplicistica, potremmo dire che CoreOS impacchetta Internet in una singola postazione, permettendo di ospitare infrastrutture simili a quelle di Amazon e Google sul proprio computer, grazie alla potenza di questo sistema operativo altamente scalabile che portera’ non poco risparmio alle startup del mondo cloud computing.
CoreOS offre quindi l’infrastruttura necessaria a ospitare i componenti di qualsiasi applicazione Web e non è dotato di null’altro, se non dei bit sufficienti per eseguire i contenitori. A tale riguardo, come gestore dei contenitori, CoreOS utilizza Docker e, come già spiegato in precedenza, la scelta dei contenitori, a differenza della virtualizzazione, permette di gestire meglio le performance della macchina e di distribuire la medesima configurazione su differenti hardware.

CoreOS, inoltre, si rifà a ChromeOS per quanto riguarda la questione degli aggiornamenti, infatti il sistema operativo supporta gli aggiornamenti automatici in background e non crea problemi d’inconsistenza dati, in quanto funziona su due partizioni disco, attivate alternativamente uno alla volta, in questo caso la partizione inattiva potra’ essere aggiornata offline effettuado uno swap dei dischi seguito da un riavvio, in modo da poter procedere con gli aggiornamenti. Il riavvio potra’ richiedere da mezzo secondo a un secondo netto.

Infine, CoreOS utilizza una partizione di sola lettura per il filesystem e include il componente etcd come servizio distribuito di configurazione.

Nel prossimo articolo vedremo come funziona nella pratica, nel frattempo vi invito a dare un’occhiata al video qui riportato dal titolo parlante : “PlayStation: Developing Apps on CoreOS”

 

CoreOS ed uso nei Datacenter

CoreOS Docker Cluster

CoreOS Docker Cluster

Ormai l’ho capito, dai tanti esempi di storie di successo in campo informatico che, le migliori invenzioni si realizzano nei garage. Così come i due famosi Steve furono capaci di creare da zero il primo Mac, così i creatori di Google concepirono il loro motore di ricerca proprio in un garage o giu’ di li. La storia che si sente inizia sempre cosi :
“Qualche anno fa, in un garage della Silicon Valley…” etc… ; ma cosa ci sarà mai in questi garage americani ?!?


Nasce così CoreOS

CoreOS è praticamente una leggerissima distribuzione Linux solo con kernel e systemd. Questa distribuzione, che effettua il boot in un paio di secondi, è pensata per chi deve realizzare e gestire cluster di centinaia, addirittura migliaia, di nodi. Praticamente permette di realizzare, con hardware di proprietà, un’infrastruttura IT come quella di Amazon o Google. Oltre ad essere già disponibile sui sistemi cloud di Amazon, di Rackspace e di Google ultimamente anche Microsoft ne ha annunciato la disponibilità su Windows Azure.

Il prodotto è davvero interessanteinfatti, in poco tempo ha avuto migliaia di raccomandazioni su GitHub ed una cifra compresa tra uno e cinque milioni di dollari da gruppi di investimento privati.

CoreOS, il cui codice è interamente disponibile su GitHub, è fortemente basato su “docker“, etcd e systemd oltre ad avere un sistema di aggiornamento del sistema operativo sottostante molto innovativo chiamato FastPatch:

FastPatch aggiorna l’intero sistema operativo in un’unica soluzione, non i singoli pacchetti, su uno schema di partizioni attivo/passivo e siccome le applicazioni e le configurazioni risiedono in ambienti completamente separati e indipendenti, non si corre il rischio di lasciare alcuni nodi del cluster in uno stato di inconsistenza.

Quindi se la vostra esigenza è quella di creare un cluster, CoreOS rappresenta davvero un’ottima scelta.

Nel prossimo articolo vedremo come creare un cluster CoreOS con Vagrant .

 

#CoreOSsistemaclusteravanzato