{"id":3407,"date":"2021-08-06T13:59:00","date_gmt":"2021-08-06T11:59:00","guid":{"rendered":"https:\/\/blog.besharp.it\/?p=3407"},"modified":"2021-08-06T09:43:32","modified_gmt":"2021-08-06T07:43:32","slug":"docker-e-i-container-cosa-sono-perche-esistono-e-quando-e-utile-usarli","status":"publish","type":"post","link":"https:\/\/blog.besharp.it\/it\/docker-e-i-container-cosa-sono-perche-esistono-e-quando-e-utile-usarli\/","title":{"rendered":"Docker e i container: cosa sono, perch\u00e9 esistono e quando \u00e8 utile usarli"},"content":{"rendered":"\n

Se lavori nel settore dell\u2019Information Technology, indipendentemente dalla tua posizione lavorativa, avrai sicuramente sentito parlare di <\/span>container software. <\/span><\/i>Magari ci lavori tutti giorni, magari ci hai lavorato qualche volta, o magari li hai solamente sentiti nominare.<\/span><\/p>\n\n\n\n

Si sente parlare di questa tecnologia da non pi\u00f9 di 10 anni, ma il concetto di container \u00e8 ben pi\u00f9 datato.<\/p>\n\n\n\n

Lo scopo di questo articolo \u00e8 di ripercorrere la storia dei container, capire da dove nascono fino ad arrivare ai giorni nostri. Discuteremo dello standard principalmente utilizzato (Open Container Initiative) e faremo chiarezza tra le diverse componenti tecnologiche (immagine, container, runtime). Infine, vedremo possibili alternative e alcune applicazioni nel mondo AWS.<\/p>\n\n\n\n

Cos\u2019\u00e8 un container?<\/h2>\n\n\n\n

Non \u00e8 facile dare una risposta semplice a questa domanda, iniziamo con quanto riportato nella homepage di <\/span>Docker<\/span><\/a>:<\/span><\/p>\n\n\n\n

Un container software \u00e8 un’unit\u00e0 software che racchiude codice e tutte le sue dipendenze, affinch\u00e8 l\u2019applicazione possa essere eseguita nella stessa maniera in ambienti computazionali diversi.<\/p><\/blockquote>\n\n\n\n

Proviamo ad analizzare meglio la risposta. Quando un\u2019applicazione viene pacchettizzata in un container, pu\u00f2, appunto, essere eseguita su diverse macchine con la certezza che verr\u00e0 eseguita alla stessa maniera. Da questo punto di vista, pu\u00f2 sembrare molto simile ad una Virtual Machine.<\/p>\n\n\n\n

Ma il container \u00e8 molto pi\u00f9 che questo.<\/p>\n\n\n\n

Iniziamo dall\u2019etimologia della parola <\/span>container<\/span><\/i>. Tutti noi conosciamo i container utilizzati su navi, treni e camion per il trasporto di merci. Immaginiamo quindi i <\/span>container software <\/span><\/i>come una sorta di involucro per la nostra applicazione, con una propria grandezza, uno standard, e dei meccanismi di locking verso il mondo esterno. Qualsiasi container, grazie alla sua forma, pu\u00f2 essere spostato da una parte all\u2019altra senza grossi problemi, indipendentemente dal suo contenuto.<\/span><\/p>\n\n\n\n

Ma qual \u00e8 il contenuto dei container software? E\u2019 un\u2019insieme di dipendenze, librerie, unitamente al codice applicativo, salvato sotto forma di immagine (<\/span>container image<\/span><\/i>) che pu\u00f2 essere eseguito su qualsiasi macchina supporti l\u2019esecuzione dei container.<\/span> Ne consegue che lo stesso software, contenuto in un container, si comporter\u00e0 alla stessa maniera sia che venga eseguito sulla macchina dello sviluppatore, sul server on premise o sulla virtual machine in cloud.<\/span><\/p>\n\n\n\n

In generale, qualsiasi applicazione necessita anche delle sue dipendenze, che possono variare da macchina a macchina (a causa della diversa architettura hardware, diverso sistema operativo). Per avere coerenza, il codice dovrebbe essere preparato insieme alle sue dipendenze.<\/p>\n\n\n\n

Nell\u2019industria del software si sono infatti utilizzate per anni le Virtual Machines (VM). La Virtual machine non \u00e8 altro che un\u2019emulazione di un computer, compreso di sistema operativo, su cui \u00e8 possibile installare tutte le tue dipendenze necessarie, rendendola indipendente dalla macchina host (codice, dipendenze e sistema operativo). Diventa per\u00f2 difficile utilizzare le VM come strumento di delivery del software, in quanto dovresti utilizzarne l\u2019intera immagine, compreso il sistema operativo. Immagino sia capitato a tutti di dover creare una virtual machine sul proprio computer, e di riscontrarne la lentezza (provare per credere!)<\/p>\n\n\n\n

Un altro problema riguardo le VM, \u00e8 che rimaniamo legati ad un virtual hardware (attraverso hypervisor). Uno sviluppatore non dovrebbe preoccuparsi dello storage, del networking o del tipo di processore (o almeno, non a basso livello). Tornando quindi alla metafora iniziale, il container dovrebbe essere indipendente da chi lo trasporta (nave, treno, truck ecc).<\/p>\n\n\n\n

L\u2019abbiamo gi\u00e0 detto, ma un altro problema delle virtual machine sono appunto le performance, oltre a richiedere molte risorse hardware, soffrono generalmente di tempi di boot elevati. Una virtual machine, per quanto virtuale, rimane comunque una macchina completa, non \u00e8 adatta di per s\u00e9 al delivery di un software.<\/p>\n\n\n\n

Riassumendo, possiamo quindi dire che per rilasciare del software affidabile e ripetibile su diversi computer, necessitano di un box ermetico in cui mettere il nostro codice. Questo box dovrebbe essere agnostico dal sistema su cui gira, in modo che lo sviluppatore possa concentrarsi sullo sviluppo del software e delle sue strette dipendenze, senza includere i dettagli della macchina. Inoltre, deve essere pi\u00f9 performante di una virtual machine.<\/p>\n\n\n\n

\"container<\/figure><\/div>\n\n\n\n

La storia dei container<\/h2>\n\n\n\n

Ripercorriamo brevemente la storia dei container, tra funzionalit\u00e0 del Linux kernel, primi progetti open source e prime aziende che hanno visto la potenzialit\u00e0 di questa tecnologia, fino alla loro ampia diffusione grazie a Docker.<\/p>\n\n\n\n

1979: Unix V7<\/strong><\/h4>\n\n\n\n

In quest\u2019anno viene rilasciata una feature del Linux kernel, <\/span>chroot<\/span><\/i>, che permette di cambiare la root directory di un processo. Questo risultato \u00e8 solo l\u2019inizio verso l\u2019isolamento dei processi, meccanismo necessario nei container odierni.<\/span><\/p>\n\n\n\n

2001: Linux VServer<\/strong><\/h4>\n\n\n\n

Nasce quello che viene definito <\/span>meccanismo jail, <\/span><\/i>una sorta di virtualizzazione a livello di sistema operativo. Linux VServer \u00e8 tra i primi software di questo tipo che permette di isolare a partizionare risorse su una macchina<\/span><\/p>\n\n\n\n

2002: Namespaces<\/strong><\/h4>\n\n\n\n

Il kernel Linux rilascia una nuova funzionalit\u00e0: i <\/span>namespaces. <\/span><\/i>I namespaces permettono di partizionare risorse hardware tra un set processi, limitando la loro visibilit\u00e0 sul resto del sistema.<\/span><\/p>\n\n\n\n

2001-2007:<\/strong><\/h4>\n\n\n\n

Molte aziende iniziano ad investire in questa tecnologia: Solaris container (Oracle), Open VZ<\/p>\n\n\n\n

2007: Cgroups<\/strong><\/h4>\n\n\n\n

Altra funzionalit\u00e0 del kernel Linux. Infatti, <\/span>il <\/span>cgroup<\/span><\/i> (abbreviazione di control groups), \u00e8 una funzionalit\u00e0 del kernel Linux che limita le risorse (CPU, memoria, disk I\/O, network ecc.) dei processi.<\/span><\/p>\n\n\n\n

2008: LXC<\/strong><\/h4>\n\n\n\n

LXC (Linux Containers) fu il primo esempio di container engine moderno. Sfrutta infatti feature del kernel Linux utilizzate dai pi\u00f9 recenti container engine (cgroups, namespaces)<\/p>\n\n\n\n

2013: Docker<\/strong><\/h4>\n\n\n\n

Partendo da LXC, nel 2013 nasce Docker come software open source per eseguire container. Da allora, il mondo dei container \u00e8 destinato a cambiare.<\/p>\n\n\n\n

Nel corso del tempo ha implementato il proprio container manager utilizzando librerie proprie (libcontainer).<\/p>\n\n\n\n

2013 – Today<\/strong><\/h4>\n\n\n\n

Dal 2013, le tecnologie si sono consolidate, sono stati creati standard (OCI), orchestratori di container (Kubernetes, Docker Swarm) e diverse alternative (micro Virtual Machines)<\/p>\n\n\n\n

Docker e la popolarit\u00e0 dei container<\/h2>\n\n\n\n

Molto spesso i termini <\/span>Docker<\/span><\/i> e <\/span>container <\/span><\/i>vengono confusi, ma come mai? Semplicemente perch\u00e8 \u00e8 grazie a Docker che i container sono diventati cos\u00ec popolari.<\/span><\/p>\n\n\n\n

Docker \u00e8 un insieme di prodotti PaaS (Platform as as Service) che permettono lo sviluppo e il delivery di software in container.<\/p>\n\n\n\n

dotCloud, l\u2019attuale Docker Inc, rilasci\u00f2 Docker per agevolare lo sviluppo software creando degli \u201cstandard box\u201d. Partendo proprio dalle funzionalit\u00e0 del kernel Linux viste precedentemente Docker volle agevolare l\u2019utilizzo di queste funzionalit\u00e0 a basso livello, fornendo interfacce dal facile utilizzo.\n<\/p>\n\n\n\n

Docker rese open-source tre aspetti chiave che facilitarono l\u2019utilizzo dei container, favorendone quindi un ampio utilizzo:<\/p>\n\n\n\n