Il Cloud Computing è una buzz word utilizzata per intendere diverse tecnologie virtualizzate a diversi livelli. Ubuntu ha Eucalyptus/OpenStack, Redhat/Fedora ha Openshift, poi ci sono servizi di hosting come Amazon EC2 ed Heroku.. ma procediamo con ordine.

Introduzione ai tipi di "Cloud"

Si intendono diverse tipologie di sofware o piattaforme remote, con granularità differente che forniscono dei servizi, le 3 grandi famiglie sono:

• IaaS (Infrastructure as a Service) - Si ha la possibilità di controllare una macchina virtuale remota, monitorare l'uso delle proprie risorse harware come RAM, CPU. Tradotto in "linguaggio hosting": VPS (Virtual Private Server).
• PaaS (Platform as a Service) - La piattaforma remota ci espone delle librerie e software che possiamo utilizzare nelle nostre webapp, ma anche installarle sul nostro pc per sviluppare in locale. Tradotto in "linguaggio hosting": Hosting Shared (condiviso) come DreamHost, Altervista,.. ma in realtà non si ha accesso al filesystem, tutta la configurazione avviene solamente nella cartella del progetto oppure tramite interfaccia web del fornitore (es. Heroku)
• SaaS (Software as a Service) - Significa utilizzare un'applicazione web via browser, Wordpress.com, Facebook, sono alcuni esempi. La differenza è che se ti stufi delle limitazioni primo servizio puoi esportarti i dati e installarti e gestirti la tua copia di Wordpress su un hosting, mentre con Facebook non puoi facilmente copiarti tutti i dati e metterli in una copia di Facebook locale.

Finalmente OpenShift

OpenShift è un servizio PaaS di RedHat basato su Fedora e altri tool liberi, ma anche un Private Cloud installabile e Open Source (OpenShift Origin LiveCD). Probabilmente se amministrate già un Hosting o VPS con qualche sito vi sfuggiranno i vantaggi di questa rivoluzione, quindi prima di addentrarmi nei dettagli tecnici vi dico subito quasi sono i vantaggi del PaaS (se conoscete già Heroku saltate questa parte).

• Deploy e amministrazione. Quando pubblicate un sito su un hosting per poter visualizzare la copia remota dovete più o meno: fargli puntare un DNS, fare un utente di sistema per quel sito, modificare i file di configurazione di Apache, installare le stesse dipendenze che usavate in locale, sistemare il database, i permessi, aggiungere al cron.. Questo ed altro nel PaaS è impostato a livello di progetto/applicazione ed eseguito in automatico dal server remoto. Basta un "git push". alcuni automatismi era possibile ottenerli con git, ma la differenza sostanziale è che un utente non amministratore può fare tutto il previsto senza accedere fisicamente al server remoto (come utente di sistema). 
• Applicazioni web isolate. Ogni applicazione web in deploy vive isolata dal resto del sistema. L'infrastruttura server dietro le quinte si proccupa di ricreare le configurazioni necessiarie, monitorare i processi, i consumi di memoria e il bilanciamento.

Cos'é OpenShift Origin e rhc

Si tratta di una versione di Fedora molto simile al servizio OpenShift offerto da RedHat, ma che è possibile installarsi nei propri server. La parte client si chiama rhc, vi genera una chiave ssh e permette di controllare vari aspetti della propria istanza di webapp, mentre la parte server è una collezione di svariati tool e configurazioni più o meno noti.

La documentazione sul sito Redhat è ben fatta, quindi se volete subito testare OpenShift o OpenShift Origin (LiveCD) qui trovate le istruzioni per il client rhc a seconda del vostro sistema operativo.

La parte più curiosa e che si discosta dal normale workflow con git è la presenza della cartella .openshift nel progetto.
Qui dentro ci sono gli hook necessari per impostare funzionalità sul server specifiche per il progetto: cron, azioni da fare dopo il deploy,..

Alla fine del "git push" il server di OpenShift farà il deploy della vostra applicazione che sarà del tipo http://myapp-domain.example.com (se usate il LiveCD) o http://myapp-domain.rhcloud.com (se usate il servizio rhcloud).

Esempio
bash-4.2$ git push
Counting objects: 7, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (4/4), done.
Writing objects: 100% (4/4), 436 bytes, done.
Total 4 (delta 2), reused 0 (delta 0)
remote: Stopping application...
remote: Waiting for stop to finish
remote: Done
remote: ~/git/myapp.git ~/git/myapp.git
remote: ~/git/myapp.git
remote: Running .openshift/action_hooks/pre_build
remote: Running .openshift/action_hooks/build
remote: Running .openshift/action_hooks/deploy
remote: Starting application...
remote: Done
remote: Running .openshift/action_hooks/post_deploy
To ssh://8ffe1d9327e04ca99c7016891fe1ef1b@myapp-mydomain.example.com/~/git/myapp.git/
   745fcd7..0f03273  master -> master

bash-4.2$ rhc app status -a myapp 
Password: 

RESULT:
Total Accesses: 35
Total kBytes: 273
Uptime: 603
ReqPerSec: .0580431
BytesPerSec: 463.602
BytesPerReq: 7987.2
BusyWorkers: 1
IdleWorkers: 1
Scoreboard: W_...

Il db SQLite viene aperto in sola lettura, se l'app prova a scrivere SELinux ci informa
con un simpatico popup che comunque non risolve 

# grep ruby /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp

Cosa c'é dietro le quinte

La parte che caratterizza in particolare OpenShift Origin rispetto una Fedora GNU/Linux è chiamata Crankcase e consiste in una serie di tool open source opportunamente configurati.
Questi tool sono disponibili come librerie utilizzate nella PaaS e sono chiamati "cartridge" (una sorta di wrapper ai tool veri e propri) che le vostre istanze di applicazioni possono utilizzare.

cron-1.4
diy-0.1
haproxy-1.4
jbossas-7
jenkins-1.4
jenkins-client-1.4
mongodb-2.0
mysql-5.1
nodejs-0.6
perl-5.10
php-5.3 3
phpmyadmin-3.4
postgresql-8.4
python-2.6
ruby-1.8

In realtà l'architettura dietro non è banale, perchè è complicato fare le cose semplici :P Se volete approndire, qui c'é l'architettura di OpenShift (Quella di Heroku si presuppone solo). Se volete scoprire come viene organizzata la vostra app in deploy andate in /var/lib/openshift/

Conclusioni

Mi sembra che OpenShift sia stato accolto in modo abbastanza freddo dalla community GNU/Linux italiana e anche da quella ruby eppure per le prove che ho fatto mi ritengo molto entusiasta di questo progetto. Si tratta della prima distribuzione di un certo rilievo che adotta il linguaggio ruby (se escludiamo Mac OS X :P) e la cosa è abbastanza insolita visto che Redhat da sempre ha spinto Java e Python.

Certo ci sono ancora delle ombre, del tipo che a volte la live non attiva la rete (basta dhclient eth0), lo stack è basato su ruby 1.8.7 (il supporto a ruby 1.9.2 non è ufficiale), a volte SELinux fa i capricci (es. con SQLite, visto che il processo vuole accedere al filesystem), ma complessivamente si tratta di un ottimo progetto che semplifica di molto il deploy e da delle linee guida omogenee (e senza nessun lock-in) per utilizzare in libertà e ripetibilità i nostri software open source anche in produzione.

E voi che ne pensate di OpenShift e del Cloud Open Source? O continuerete a gestire a manina le configurazioni dei siti del vostro VPS?