<img height="1" width="1" style="display:none" src="https://www.facebook.com/tr?id=1214412942025937&amp;ev=PageView&amp;noscript=1">

Red Blog

Red Hat OpenShift per un'automazione unica nell'approccio DevOps

Davide Costanza,

devops_linee_parallele.jpg

Dopo avervi parlato dell'importanza della collaborazione e dell'automazione per mettere in atto l'approccio DevOps, scendiamo ancora più nel dettaglio cercando di capire come l'automazione messa in pratica dai due team può fondersi in un'unica cosa.

 

Scopri subito il nostro ebook sui casi di successo con Red Hat!

 

Quand’è che si realizza la fusione delle due forme di automazione?

La fusione si realizza con il salto dal pacchetto applicativo al sistema: ossia il deployment del pacchetto app nel sistema.

deployment_devops.jpg

Se anche questo passo lo descriviamo con codice sorgente, otteniamo un intero processo scritto su codice (everything as code). Descrivendo ogni cosa come codice sorgente, ottieni una migliore capacità di controllo e quindi, grazie alla possibilità di visionare le versioni precedenti, puoi tenere traccia di tutte le modifiche che son state fatte, non solo all’app ma anche all’infrastruttura e al modo in cui hai deployato la tua applicazione nell’infrastruttura.

E qui vado ad introdurre un altro pezzo fondamentale nell'adozione dell’approccio DevOps: i container.

I container

frank-mckenna-252014.jpg

Paragonando il sistema operativo ad un albergo, potremmo definire il container come una camera dell’albergo.

Per spiegarlo in parole semplici, i container sono piccoli sistemi operativi, piccoli computer. Questi hanno molte analogie con le macchine virtuali, ma sono molto più leggere rispetto a quest’ultime. Si potrebbe dire che rappresentano l’evoluzione delle macchine virtuali.

A differenza delle Virtual machine, un container viene tipicamente utilizzato secondo un modello differente: ogni singola applicazione viene messa in un singolo container. In questo modo, ciascuna app va nella propria “cella”.

I benefici dell’utilizzo del container derivano, in particolare, dal fatto che non solo un container può essere spento, ma è possibile anche disinstallarlo senza che questo lasci alcuna traccia nel sistema.

Questi container vengono creati da file che contengono delle istruzioni, ciò significa che nel momento in cui hai di nuovo bisogno di un container, lo puoi sempre ricostruire da zero. Da questo file descrittivo, puoi creare un’immagine; da questa immagine puoi creare tutti i container che vuoi, affini all’immagine.

La natura descrittiva è il loro punto di forza. I file definiscono l’immagine da cui nasceranno i container; già loro stessi quindi hanno una descrizione come codice, quindi sono “automaticamente automatizzati”.

Il salto di qualità che viene effettuato vede gli ops creare i file di descrizione dei container dai quali vengono creati i container. Quindi il Dev scrive il codice sorgente, mentre l’Ops scrive l’immagine da cui vengono istanziati, creati i container. Esistono strumenti che permettono di mettere insieme queste due cose.

Questi due ambiti descrittivi (codice sorgente + codice di descrizione dell’immagine) possono essere fusi all’interno di un unico oggetto, ricavando alla fine quella che è un’immagine che contiene un’applicazione. Quando si crea un container da questa, si fa girare l’applicazione. L’applicazione è moltiplicabile per un numero n di volte, senza possibilità di errore, grazie alla fonte di descrizione che utilizzi.

Il numero di app che vuoi, ovunque tu voglia.

Queste saranno tutte uguali, gireranno ognuna in maniera conforme con le altre. A cosa potrebbe essere utile tutto ciò, vi chiederete? A scalare per esempio. (L’esempio di un eCommerce durante il Black Friday può essere d'aiuto per capire l’importanza del poter scalare nel Cloud senza vincoli. Lo trovate qui.)

In questo modo, i dev e gli ops iniziano davvero a collaborare nel definire una stessa cosa. Gli ops creano l’automazione degli ambienti di esecuzione, i dev creano il software. Ognuno ha il suo compito, collaborano, senza sconfinamenti.

Red Hat Openshift, la piattaforma di collaborazione

devops_together we create.jpg

Grazie all’utilizzo di una piattaforma di collaborazione, il team Dev e il team Ops potranno finalmente collaborare in perfetta sintonia.

Gli Ops creano l’ambiente che non può essere modificato dai Dev e dove quest’ultimi non possono nemmeno installare software, ad esempio. Ciò che possono fare, invece, è accedere al catalogo dei servizi presenti nell’ambiente, inserire nella piattaforma il codice sorgente e scegliere il servizio/immagine che vogliono sviluppare dalle descrizioni ivi inserite dagli Ops.

Gli sviluppatori, una volta che hanno il catalogo pronto messo a disposizione dai sistemisti, possono costruire la loro architettura applicativa in modalità Self Service: sono autonomi nel fare provisioning nel loro server, nello scalare, etc.

In sintesi: gli ops danno la base alla piattaforma, preparano un po’ di risorse; i dev arrivano e, utilizzando le risorse presenti in piattaforma, si creano in autonomia le loro soluzioni applicative... sulla base però di quanto deciso dagli Ops! Quindi i dev hanno a disposizione solo quello che gli ops mettono loro a disposizione.

Infatti, i template vengono creati ed inseriti gli ops, mentre le specifiche del progetto sono in mano ai dev. Di qualsiasi cosa abbia bisogno un dev, nel caso in cui non sia già a catalogo, dovrà chiedere di crearlo agli ops. I dev possono comunque creare dei propri template specifici ai progetti, basati sui template degli ops e che utilizzano le immagini preparate e controllate dagli ops. Lavorano in self service su uno strato sopra a quello preparato dagli ops.

Ma qual è la caratteristica di tutto questo processo? Tutto è descritto sotto forma di codice. Anche l’infrastruttura come codice, per cui diventa riutilizzabile.

Concludendo, cos’è che cambia con l’approccio DevOps?

Se prima i Dev agivano e gli Ops subivano e cercavano di resistere al cambiamento, in quanto erano a conoscenza che questo avrebbe magari comportato tre weekend di lavoro intenso, creando tensione, invece che collaborazione, oggi è possibile collaborare, ognuno svolgendo il proprio ruolo, in sintonia ed eliminando la resistenza al cambiamento, fondamentale per l’innovazione.

Red Hat Open Source Day 2017

OSD2017.jpg

Come Advanced Business Partner Red Hat, saremo all'Open Source Day 2017 organizzato da Red Hat, che si terrà a Milano e Roma rispettivamente il 7 e 9 Novembre.

Durante la conferenza di Milano, terrò un incontro dal titolo "Miglioramento del processo di sviluppo mediante DevOps e OpenShift", mentre il mio collega Luigi De Masi (Middleware and integration specialist di Extra Red) a Roma parlerà di "Monitoraggio delle applicazioni su OpenShift con Prometheus".

Vi invito a partecipare, registrandovi qui. La partecipazione all'evento è gratuita ed è una grande opportunità per chiunque operi nel mondo IT! 

Per approfondire le vostre conoscenze sul mondo Red Hat, prodotti, servizi e casi di successo, vi invito a scaricare il nostro ebook gratuito "Digital Transformation: casi di successo con Red Hat": 

New Call-to-action

Share this post

   

Commenti

Prova Red Cloud Gratis per 30 Giorni

Iscriviti alla newsletter

Condividi questo blog

    

Post correlati