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.

    La metodologia Agile è una metodologia di sviluppo software molto nota
    contrapposta al modello a cascata, più tradizionale.

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.

monolith vs microservices

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.

container evolution

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:

  • c’era già un bisogno importante di isolare e contenere

    • per evitare interazioni non gradite

      • sia tra applicazioni diverse

      • ma anche tra insiemi di applicazioni diverse (tipiche dei sistemi condivisi)

  • c’erano già molte tecniche per ottenerlo

…​ 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

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

    • https://hub.docker.com

    • 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

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 :-)

Corso Docker

Vuoi ulteriori informazioni su docker, segui il nostro corso 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:

OCI Members

Pubblicato il
    Be Smart Be Open

    Business Software Solutions

    Latest articles

    Released in production our flutter based app 'Wasteful'

    11 March 2022

    Contact us

    Email: besmart@besmartbeopen.it
    Pec: besmartbeopen@pec.it
    P.IVA e C.F.: 02137570509
    Top
    Noi ed alcuni partner utilizziamo cookie o tecnologie simili come specificato nella cookie policy Per maggiori informazioni consulta la nostra Cookie Policy Cookie Policy