Le esigenze e le modalità di sviluppo, test e rilascio del software sono molto cambiate in questi ultimi anni. La progressiva standardizzazione di metodologie di DevOps ha creato una sempre più forte interdipendenza tra il mondo dello sviluppo e quello dell’amministrazione IT. In questo scenario ha trovato terreno fertile lo sviluppo di alcuni dei moderni paradigmi di cloud computing come Infrastructure-as-a-Service (IaaS), Platform-as-a-Service (Paas) e Software-as-a-Service (SaaS).
La differenza tra IaaS, PaaS e Saas è relativa al controllo sull’infrastruttura sottostante al software. L’immagine seguente può aiutare meglio a comprendere i livello di astrazione di questi tre modelli.
In un environment IaaS si avrà il controllo sul sistema operativo, sulla piattaforma applicativa (application server, runtime, ecc) e sull’applicazione stessa. Questo significa ovviamente che lo sviluppatore o il sysadmin avrà anche l’onere di installare, configurare e manutenere non solo il sistema ma anche librerie e runtime necessari all’applicazione. OpenStack è un tipico Infrastructure-as-a-Service.
In un environment SaaS abbiamo solo le applicazioni pubblicate e l’utente non ha possibilità di agire sulla configurazione del software. Un esempio calzante di SaaS sono le Google Apps.
In un environment PaaS il sistema e i runtime su cui gira l’applicazione sono forniti e sarà onere dell’utente sviluppare, distribuire e manutenere l’applicazione.Un PaaS fornisce servizi web server, application server, framework, database, messaging, business process management e funzionalità di integrazione. OpenShift Enteprise rientra esattamente in questa definizione.
OpenShift Enterprise deriva, come tutti i prodotti Red Hat, dall’upstream gestito dalla community denominato OpenShift Origin. Il progetto Origin alimenta sia OpenShift Enterprise che OpenShift Online, piattaforma di public cloud fornita direttamente da Red Hat ai clienti che non hanno a disposizione un datacenter o che semplicemente non vogliono avere l’onere della gestione dell’infrastruttura.
La versione attuale di Openshift Enterprise (che per brevità denimeremo sin da ora OSE), è la 3.1. Dalla versione 3.0 molte sono state le novità introdotte, partendo da una importante rivisitazione dell’architettura rispetto alla versione 2. La principale novità è l’introduzione di Docker (date un’occhiata a questo post presente sul blog) e Kubernetes per la gestione e orchestrazione dei container. Questa soluzione combinata di Docker+Kubernetes è comune anche in Red Hat Atomic Host e Atomic Enterprise Platform.
Una nota su OpenShift Online: quest’ultimo utilizza ancora la tecnologia della versione 2, dove al posto delle docker image vi sono i cartridges ed i gears al post dei containers. Qui una breve disamina delle differenze tra le due versioni.
Andiamo ora ad analizzare un pò più nel dettaglio lo schema arhitetturale di OSE3.
Le principali caratteristiche di OpenShift Enterprise 3 sono:
- Piattaforma self-serivice: Gli sviluppatori possono creare le applicazioni a partire dai template forniti (e customizzabili) e dal codice sorgente gestito da un SCM come Git.
- Supporto per più linguaggi e runtime: OSE supporta Java, Node.js, PHP, Python, Perl, Ruby. Inoltre supporta diversi database come Mysql, Postegres, MongoDB con storage persistente e non. Supporta inoltre i prodotti JBoss Middleware come JBoss EAP, Active MQ e Fuse.
- Automazione: Gestione del ciclo di vita delle applicazioni e supporto per build e deploy automatici tramite web hooks.
- Web Interface: OSE3 dispone di una semplice e intuitiva WEB GUI per compiere molte delle operazioni standard di creazione di nuove applicazioni a partire da sorgenti e template. Come sempre, la CLI offre una gamma di funzionalità molto più ampia e consona al lavoro di un amministratore IT.
- Collaborazione: è possibile condividere progetti con altri utenti assegnando o modificando ruoli. Inoltre è possibile esportare i propri template e renderli disponibili alla community.
- Scalabilità: uno degli aspetti più importanti del cloud computing è il passaggio dalla scalabilità verticale quella orizzontale. OSE3 pemette di scalare in tempo reale, in base alle richieste e al carico di traffico di un’applicazione.
- Portabilità: i container continuano ad essere definiti tramite container image di Docker e quindi hanno il grande vantaggio di poter essere ridistribuiti su altre piattaforme come ad esempio Atomic Host o Atomic Enterprise.
E’ possibile installare OSE3 su bare metal, hypervisor (proprietari e non) e su IaaS cloud provider, pubblici o privati. Infine OSE3 è un’applicazione Open Source di livello Enterprise con il conseguente vantaggio di avere a disposizione il supporto Red Hat durante tutte le fasi di implementazione e gestione.
Nel seguente schema si può osservare un tipico caso di architettura di OSE3.
Come accennatto sopra, la principale innovazione di questa versione è l’utilizzo di Docker e Kubernetes per l’orchestrazione dei container che vengono aggregati in unità dette Pod. Per chi non fosse pratico di Kubernetes un Pod è un gruppo di una o più applicazioni (ovvero uno o più container) che girano in un environment condiviso. Questo approccio permette di aggregare e orchestrare (anche e soprattutto dal punto di vista del networking) i container eseguiti da Docker.
I Pod vengono esposti verso i nodi tramite dei Servizi. I Servizi a loro volta espongono porte e IP all’esterno tramite la definizione di Rotte.
Come si può vedere nello schema i Pod in OSE3 girano all’interno di host fisici o virtuali detti Nodi. I nodi sono istanze di Red Hat Enterprise Linux o Atomic Enterprise. Il coordinamento dei nodi è effettuato da uno o più Master, che sono a loro volta nodi nel cluster OSE e che coordinano funzionalità di Orchestration, Storage (Persistent Volumes), Scheduler, Replication, Autenticazione, REST API entry point.
Il Master esegue il servizio Kubernetes Master e il servizio Etcd, utilizzato per salvare le configurazioni dei Pod.
I Nodi eseguono i container, e i demoni kubelet e kube-proxy. I nodi in OSE3 corrispondono ai minions di Kubernetes.
Le docker images utilizzate da OpenShift Enterprise 3 sono, di default, quelle disponibili sul registry Red Hat. E’ inoltre possibile utilizzare anche le immagini disponibli sul Docker Hub.
In OSE3 non c’è un vero e proprio concetto di applicazione. Definire una nuova applicazione in OSE3 significa creare un Progetto, e all’interno di questo andare a generare una serie di risorse quali Pod, configurazioni di Build e Deploy, Servizi, Rotte e, opzionalmente, Persistent Volumes. Tutte queste risorse possono essere create e gestite singolarmente o all’interno di processi automatizzati complessi eseguiti tramite CLI, Web Interface o REST API. Le risorse sono definite all’interno di file JSON o YAML. E’ inoltre possibile esportare risorse esitenti nello stesso formato.
Quando una nuova risorsa viene creata verranno avviati uno o più pod in uno dei nodi disponibili. Le definizioni della risorsa includeranno informazioni come ad esempio l’immagine da utilizzare, quali porte esporre, ecc.
Uno degli aspetti più interessanti in OpenShift Enterprise 3 è la possibilità di lavorare a basso livello, direttamente sui container, oppure di sfruttare le funzionalità offerte dal tool Source-to-Image (più brevemente s2i). Questo è un framework che permette di fare build di container partendo direttamente dal sorgente in un repository SCM, individuando automaticamente il linguaggio utilizzato (tramite una serie di controlli sui file nel repository). Durante la fase di creazione del pod viene compilato il sorgente presa dall’SCM sulla build image relativa al linguaggio individuato e successivamente il pod risultante viene deployato e scalato in base al numero di repliche definite. Inoltre s2i può buildare l’applicazione utilizzando tool specifici (Maven per applicazioni Java ad esempio). Anche se già di per se s2i offre un ciclo di Continuous Integration e Continuous Deployment, può integrare anche tool esterni di CI/CD come ad esempio Jenkins.
Non solo OSE può far partire una nuova build a seguito di una modifica del sorgente dall’SCM: anche se un template o la build image vengono modificati verrà automaticamente schedulata una build di una nuova versione.
Infine, aspetto profondamente utile, è possibile gestire le strategie di deploy delle nuove versioni, optando per dei rolling update, per un completo redeploy o per una strategia custom definita dall’utente.
Immaginiamo questa funzionalità applicata ad esempio a JBoss EAP 6, che non ha al suo interno un meccanismo di automazione dei rolling update, feature che ora si può sfruttare attraverso l’integrazione in OpenShift.
Chiudiamo qui questa prima panoramica generale su OpenShift Enterprise 3 con una piccola considerazione personale: si tratta di una delle piattaforme che più mi hanno affascinato negli ultimi tempi che di certo merita parecchio studio e approfondimento.
Non esitate a tale proposito a leggere la documentazione di Origin molto ben manutenuta dalla communty e quella ufficiale RedHat a questo link.
Se avete voglia di fare un po’ di hacking, potete dare un’occhiata ai sorgenti di Origin su GitHub. OpenShift Origin è scritto in Go, ottimo linguaggio open source nato in casa Google.
Nel prossimo post sul blog vedremo come fare un’installazione base e il deploy di un pod all’interno di un progetto, quindi stay tuned!
