{"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 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 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 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 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 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 Molte aziende iniziano ad investire in questa tecnologia: Solaris container (Oracle), Open VZ<\/p>\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 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 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 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 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 Come abbiamo gi\u00e0 visto, l\u2019immagine di un container non \u00e8 altro che un pacchetto software autocontenuto con codice sorgente, librerie e relative dipendenze.<\/p>\n\n\n\n Una volta create, queste immagini sono standard, statiche, non cambiano pi\u00f9 (proprio come il contenuto dei container che vengono spediti da una parte all\u2019altra del mondo). Non \u00e8 scopo di questo articolo scendere nel dettaglio dell\u2019immagine di Docker, possiamo per\u00f2 dire che il container, una volta che viene eseguito, potr\u00e0 scrivere su un layer <\/span>writable<\/span><\/i> che \u00e8 separato dal layer in cui \u00e8 salvata l\u2019immagine del nostro container. Di per se, infatti, i dati di un container sono effimeri.<\/span><\/p>\n\n\n\n Ma come possiamo creare l\u2019immagine di un container con Docker? Semplice, scrivendo una \u201cricetta\u201d, chiamata <\/span>Dockerfile<\/span><\/i>: un file testuale che consiste in istruzioni ben precise su come pacchettizzare il nostro software standalone. Gli sviluppatori, guardando il Dockerfile, possono concludere a colpo d\u2019occhio quale sar\u00e0 il contenuto finale dell\u2019immagine e averne pieno controllo.<\/span><\/p>\n\n\n\n Di seguito \u00e8 riportato un esempio di Dockerfile che usa Ubuntu 18 come immagine di partenza (FROM), copia il contenuto della directory in cui si trova il Dockerfile nella cartella <\/span>app <\/span><\/i>(COPY), esegue un comando durante la creazione dell\u2019immagine (RUN) e definisce il comando che dovr\u00e0 essere eseguito allo startup del container (CMD)<\/span><\/p>\n\n\n\n Semplice, vero?<\/p>\n\n\n\n Ma le funzionalit\u00e0 di Docker non finiscono qui. Una volta creata l\u2019immagine, infatti, gli sviluppatori o altri membri del team possono scambiarla tra di loro ed eseguirla sul proprio computer, on-premise, o sul cloud senza dover installare altro oltre all\u2019engine di Docker, usando una comoda, e di facile utilizzo, Command Line Interface (CLI). Il container runtime di Docker non fa altro che leggere il contenuto dell\u2019immagine ed eseguirlo. Grazie ai Linux namespaces, ogni container verr\u00e0 eseguito in un ambiente separato dagli altri.<\/p>\n\n\n\n Avete visto i vantaggi di Docker? Potete capire il perch\u00e8 della sua popolarit\u00e0?<\/p>\n\n\n\n Docker non ha stravolto il concetto di container (portabilit\u00e0, migliori prestazioni rispetto a tradizionali VM, possibilit\u00e0 di modularizzare applicazioni monoliti, offrire maggiore scalabilit\u00e0), ma \u00e8 stata la prima azienda ad offrire gli strumenti giusti per il delivery del software, velocizzando il processo. Non a caso, questi sono anche gli anni della rivoluzione DevOps (agilit\u00e0, flessibilit\u00e0, scalabilit\u00e0 nel delivery di un software)<\/p>\n\n\n\n Dalle prime release di Docker, una grande quantit\u00e0 di persone inizi\u00f2 a utilizzare i container come unit\u00e0 standard per il delivery del proprio software. Anche le aziende iniziarono ad utilizzare Docker, e il suo team non riusc\u00ec sempre a rispondere a tutte le esigenze tecniche e di business che il mercato richiedeva. In risposta a questo, dalla community sono nati diversi runtime, con diverse implementazioni e capabilities, unitamente a nuovi tool per creare e lanciare container.\n<\/p>\n\n\n\n Per essere sicuri che diversi container runtime potessero lanciare immagini prodotti da diversi tool, Docker e altri membri della community fondarono nel 2015 la Open Container Initiative (OCI) per definire uno standard attorno al mondo dei container.<\/p>\n\n\n\n Le immagini originali d Docker sono quindi diventate l\u2019OCI image specifications.<\/p>\n\n\n\n Fornita un\u2019immagine conforme allo standard OCI, qualsiasi container runtime che supporti l\u2019OCI runtime pu\u00f2 leggere il contenuto di un\u2019immagine ed eseguirlo in un ambiente isolato.<\/p>\n\n\n\n Docker non ha donato solo lo standard di creazioni dell\u2019immagine, ma anche il suo container runtime, runc, e il demone containerd, creando cos\u00ec un ecosistema completamente modulare, come riportato di seguito:<\/p>\n\n\n\n OCI \u00e8 quindi un gruppo di tech companies che mantiene una specifica per l\u2019immagine dei container e su come essi debbano essere eseguiti. Nasce dalla volont\u00e0 di poter scegliere tra diversi runtime che sono conformi alle stesse specifiche, avendo implementazioni a basso livello diverse<\/p>\n\n\n\n Fino ad ora abbiamo parlato di container strettamente legati al mondo Linux. Ma in tutto questo, Windows dove si posiziona? Proviamo a rispondere.<\/p>\n\n\n\n Su windows, hai sostanzialmente due modi per eseguire i container:<\/p>\n\n\n\n Nel mondo Linux, Docker \u00e8 quasi completamente open source e supporta tutte le distro Linux. Per poter utilizzare i container anche su questo sistema operativo, Docker e Windows lavorano a stretto contratto per portare e mantere i container su questo sistema operativo.<\/p>\n\n\n\n Ma una domanda sorge spontanea: esistono alternative allo standard OCI? Certamente! Vediamo alcuni esempi:<\/p>\n\n\n\n Tra le alternative non conformi allo standard OCI, esistono quindi soluzioni diverse ai container, parliamo soprattutto di micro VM. Stiamo facendo un salto nel passato quindi? Assolutamente no! Generalizzando, possiamo dire che le micro VM sono delle VM leggerissime, con una propria versione ridotta del kernel, che offrono livelli di isolamento e sicurezza dei processi maggiori rispetto ai container. Si spiega perch\u00e9, ad esempio, AWS abbia scelto questa modalit\u00e0 per offrire maggiore sicurezza ai proprio clienti che scelgono potenza computazionale di tipo serverless (Lambda e Fargate).<\/p>\n\n\n\n I container vengono ormai utilizzati ampiamente come strumento di delivery del software, ma \u00e8 possibile farlo anche sul cloud? Certamente!<\/p>\n\n\n\n AWS offre servizi come ECS (Elastic Container Service), gi\u00e0 discusso in molti articoli sul nostro blog, e EKS (Elastic Kubernetes Service) come orchestratori di container. Nulla vieta, inoltre, di poter orchestratore in autonomia i proprio container su macchine EC2, magari in autoscaling, ma dove sarebbe il vantaggio?<\/p>\n\n\n\n Personalmente, in architetture basate su container, vedo questi ultimi come l\u2019unit\u00e0 infrastrutturale base da gestire, dimenticando quindi la manutenzione dei server sottostanti. Se ci pensiamo bene, \u00e8 proprio la filosofia che sta dietro ai container, ovvero avere degli elementi software autocontenuti, indipendenti dall\u2019host su cui girano (in termini di hardware e OS). Per questo motivo, quando uso ECS lo scelgo in modalit\u00e0 Fargate: costruiamo, gestiamo e manteniamo container, non server!<\/p>\n\n\n\n In questo articolo abbiamo ripercorso la storia dei container, da quando sono nati fino alle loro applicazioni odierne. Abbiamo trattato i vantaggi e le differenze principali rispetto ad una classica architettura basata su macchine virtuali. <\/p>\n\n\n\n Siete interessati ad approfondire l\u2019argomento? Fatecelo sapere nei commenti!<\/p>\n\n\n\n PS: Sapevate che dall\u2019ultimo AWS re:Invent \u00e8 possibile eseguire i propri container su Lambda?<\/p>\n","protected":false},"excerpt":{"rendered":" Se lavori nel settore dell\u2019Information Technology, indipendentemente dalla tua posizione lavorativa, avrai sicuramente sentito parlare di container software. Magari ci […]<\/p>\n","protected":false},"author":14,"featured_media":3416,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[241],"tags":[375,373],"yoast_head":"\nCos\u2019\u00e8 un container?<\/h2>\n\n\n\n
<\/figure><\/div>\n\n\n\n
La storia dei container<\/h2>\n\n\n\n
1979: Unix V7<\/strong><\/h4>\n\n\n\n
2001: Linux VServer<\/strong><\/h4>\n\n\n\n
2002: Namespaces<\/strong><\/h4>\n\n\n\n
2001-2007:<\/strong><\/h4>\n\n\n\n
2007: Cgroups<\/strong><\/h4>\n\n\n\n
2008: LXC<\/strong><\/h4>\n\n\n\n
2013: Docker<\/strong><\/h4>\n\n\n\n
2013 – Today<\/strong><\/h4>\n\n\n\n
Docker e la popolarit\u00e0 dei container<\/h2>\n\n\n\n
<\/figure><\/div>\n\n\n\n
Da Docker allo standard OCI (Open Container Initiative)<\/h2>\n\n\n\n
<\/figure><\/div>\n\n\n\n
E Windows OS?<\/h2>\n\n\n\n
Container Non-OCI e alternative<\/h2>\n\n\n\n
Container e Cloud Computing<\/h2>\n\n\n\n
Per concludere<\/h2>\n\n\n\n