Rilasciata in produzione applicazione Wasteful basata su Flutter
11 Marzo 2022
La metodologia Agile è una metodologia di sviluppo software molto nota contrapposta al modello a cascata, più tradizionale.
Container from zero to hero: 0 - Fondamenti
Breve introduzione all’utilizzo dei container: storia e motivazioni
Crescita del software
Lo sviluppo del software è cambiato notevolmente negli anni, passando da un approccio monolitico più tradizionale ad uno agile più moderno.
L’approccio monolitico è quello in cui un’esigenza viene risolta tramite uno o più grossi software che contengono tutte le funzionalità di cui i suoi utenti hanno bisogno.
Questo approccio tradizionale monolitico soffre di alcuni svantaggi evidenti:
l’aggiunta di nuove funzionalità aumenta la complessità del monolite;
per mantenere la compatibilità del monolite si tende ed evitare l’innovazione;
la scalabilità è difficoltosa;
è poco Agile - lo sviluppo segue tipicamente un approccio a cascata;
ci sono interdipendenze e sistemi strettamente accoppiati.
Approccio a microservizi
L’approccio a microservizi è un’evoluzione delle architetture software, che si è diffusa a partire dall’anno 2011.
Questa architettura prevede la suddivisione del software (il monolite) in una in una suite di piccoli servizi o componenti in cui:
ci sia un servizio per ciascun dominio distinto;
sia possibile riusare e comporre il sistema grazie anche a servizi già presenti.
Questo approccio porta alcuni importanti vantaggi, tra cui due specifici legati ad aspetti dei servizi:
è possibile far scalare orizzontale solo i (micro)servizi che lo richiedono
è possibile ottenere l’alta affidabilità dell’intero sistema replicando i servizi critici (SLA && five nines …)
Il termine "Microservices" (microservizi) è stato utilizzato per la prima volta durante una conferenza sulle architetture software nel 2011.
Monolite vs Microservizi
L’immagine successiva esemplifica la distinzione tra un software monolitico contenente tutti i componenti all’interno ed un’architettura a microservizi dove il software monolitico è stato decomposto in tre elementi.
Software moderno
Nel moderno software a microservizi ci sono alcune peculiarità da considerare:
ci sono articolate e potenzialmente intense comunicazioni tra i vari microservizi
ci sono anche molti software, ciascuno con la propria versione
e con rilasci frequenti tipici di una modalità Agile
è meglio pensare ad una pipeline di continuous integration (CI)
il deploy è molto più complesso rispetto al monolite
Nasce quindi la necessità di innovare anche la modalità di deploy delle applicazioni. Nascono anche software e soluzioni di continuous deploy dove si definiscono pipeline personalizzate di deploy per tutti i componenti (microservizi) della propria architettura.
Microservizi con orchestrazione
Le applicazioni si compongono da molti microservizi, a volte in numero molto elevato. Per esempio alcuni servizi di Netflix sono composto da 700 microservizi… Non tutti hanno questa complessità, ma anche con qualche decina di componente per ogni servizio, aumentano le necessità di ottimizzazione e gestione delle risorse.
In particolare occorrebbe:
l’ottimizzazione dell’uso delle risorse (ram, cpu, …)
su un solo server molti microservizi
un livello di orchestrazione architetturale per
la possibilità di scalare orizzontale
la possibilità di avere l’alta affidabilità
Virtualizzare è la soluzione?
La virtualizzazione può venire incontro ad alcune esigenze delle architetture a microservizi. Virtualizzare l’accesso alle risorse (network, storage, cpu, ram…) può aiutare l’efficienza dell’impiego di quelle risorse.
Manca però uno standard per la suddivisione delle applicazioni e il loro incapsulamento, inoltre nelle VM c’è un (ulteriore) sistema operativo - da gestire.
Cosa servirebbe?
L’approccio dei container risolve gran parte delle limitazioni delle VM, eliminando la necessità di avere un altro sistema operativo (quello delle VM) e migliorando l’efficienza dell’incapsulmanto delle risorse.
Dal passato…
La necessità di isolare e contenere i processi e le risorse di un calcolatore in realtà ha radici che affondano e crescono già nel millennio scorso nel mondo dei mainframe:
… al recente passato
Arrivando agli anni 2000 le tecniche di isolamento e contenimento delle risorse approdano al mondo dei server Linux.
Vengono sviluppate in ambito opensource le basi di quello che sarà il mondo dei container:
- Cgroups (2006) Linux Kernel
nati per limitare l’uso delle risorse di un processo
- Apparmor e SELinux
per limitare e confinare le capacità dei processi
- Kernel Namespaces
pensati per confinare un insieme di processi per una specifica caratteristica (ipc, mount, pid, network, user e uts).
Docker
Nato nel 2013, il Docker è un sistema che standardizza la modalità di utilizzare i sistemi di isolamento e limitazione presenti nel Kernel Linux. È questo il momento in cui si individua questa nuova modalità di utilizzo delle risorse: i container.
Docker compone queste tecnologie già presenti nel mondo Linux, per fornire un sistema omogeneo di container. Inoltre vengono definiti anche:
un formato standard per scambiare le immagini dei container (le docker image)
il repository centralizzato con immagini già pronte
la possibilità di avere altri repository, che nascono nel tempo (per esempio quay.io oppure il proprio repository aziendale e/o privato)
vari tools per la creazione e gestione di container/immagini.
L’attuale ecosistema docker fornisce una serie di tecnologie:
Docker Engine, Docker Hub, Docker Registry
Docker Compose, Docker Machine, Docker Swarm
Docker: vantaggi evidenti
L’approccio ai container tramite Docker fornire alcuni vantaggi evidenti:
Nuovo modo di testare e distribuire le proprie applicazioni
Uniforme modo di avviare e fermare le applicazioni
Potenzialmente nessuna differenza tra ambiente di produzione e sviluppo, staging…
Immagini e container
Le immagini in breve sono dei template read-only da cui vengono avviati i container. Le immagini:
contengono le applicazioni con tutte le loro dipendenze
sono formate da un insieme di layer
Per modificare un’immagine si aggiunge un nuovo layer; in questo modo è possibile ereditare delle immagini base e aggiungervi le personalizzazioni.
Notare che dalla stessa immagine docker possono essere avviati più container.
Docker layered filesystem
L’immagine sulla destra evidenzia il filesystem a layer del docker, in cui si vede come on-top ad un layer predefinito fornito direttamente dal kernel del host ospitante il container docker viene aggiunto:
un layer relativo l’immagine base di Ubuntu
un layer contenente i file necessari al funzionamento di emacs
un layer contenente i file necessari al funzionamento di apache
Beh non è una grande idea avere emacs sulla macchina ospitante apache… anche se questo è uno degli esempi ufficiali docker :-)
OCI
Nel 2015 Docker si è già guadagnato la scena come raising star del mondo dei container.
Nasce l’esigenza condivisa di standard sui container e nel 2015 viene fondata la Open Container Initiative a cui partecipano molti player del mondo del cloud computing e del settore ICT più in generale.
La OCI:
ha permesso la realizzazione di standard per i container
con le specifiche runtime & image
si impegna a sviluppare standard e software di supporto ai container
La OCI è formata da molte aziende, tra cui:
Pubblicato il
Articoli correlati
Business Software Solutions
Link utili
I nostri contatti
Pec: besmartbeopen@pec.it
P.IVA e C.F.: 02137570509