‫Bene, in questa conferenza parleremo dei livelli dell'immagine.
‫Quindi questo è un concetto fondamentale di come funziona Docker. Usa qualcosa chiamato il file system union
‫per presentare una serie di modifiche al file system come un vero file system.
‫Entreremo nella storia e controlleremo i comandi e vedremo come possiamo usarli per
‫capire di cosa è fatta realmente un'immagine. Impareremo un po 'sulla copia sul concetto di
‫scrittura di come un contenitore viene eseguito come un livello aggiuntivo sopra un'immagine.
‫Cosa intendo per livelli di immagine?
‫un'immagine non è un grosso blob di dati che viene e va in un enorme pezzo.
‫In realtà è completamente trasparente per te quando usi Docker, ma quando inizi a
‫scavare in determinati comandi, come il comando history, inspect e commit, inizi a capire che
‫Destra?
‫Se noti che effettivamente abbiamo fatto Docker, alcune volte potresti vedere le parole che indicano
‫che c'è qualcosa che hai già, come se ne avessi già memorizzato una parte, e Qualche tempo fa, stavamo Destra? Ricordiamo che l'ID immagine Nginx è lo
‫che tutto si riduce al fatto che le immagini sono progettate usando il concetto del file system di unione in realtà nelle giocando con i tag con Nginx. stesso e abbiamo tag diversi per lo stesso nome dell'immagine.
‫di fare strati sui cambiamenti. Quindi, facciamo una rapida cronologia del docker su nginx più recente.
‫Se potessimo rapidamente vedere cosa abbiamo in Docker. immagini Docker. Cosa sto guardando qui?
‫Questo non è un elenco di cose realmente accadute nel contenitore perché si tratta di un'immagine.
‫Questa è in realtà una cronologia dei livelli dell'immagine.
‫Ogni immagine inizia fin dall'inizio con un livello vuoto noto come zero.
‫Quindi ogni serie di modifiche che si verifica dopo quella sul file system, nell'immagine, è un altro livello.
‫Potresti avere un livello, potresti avere dozzine di livelli e alcuni livelli forse non
‫cambieranno in termini di dimensioni del file.
‫Qui noterete che in realtà qui abbiamo un cambiamento che
‫era semplicemente una modifica dei metadati su quale comando avremmo effettivamente eseguito. 'quando andremo sul Dockerfile.
‫Ne parleremo un po
‫Ma, per ora, puoi vedere che questo ha aggiunto un'enorme quantità di file di 123 MB.
‫Poi abbiamo apportato una modifica qui e un cambiamento qui e mi capita di sapere a causa di Dockerfiles che queste sono
‫in realtà solo informazioni sui metadati Dockerfile.
‫Mentre salirai, avremo altre modifiche ai dati.
‫Vedrai che questo è in realtà abbastanza diverso in un'altra immagine.
‫Quindi, se andiamo alla storia della finestra mobile mysql, ha un set di livelli di immagine completamente diverso.
‫Lascia che ti disegna un po 'per te e forse questo ti aiuterà.
‫Quando iniziamo un'immagine, quando stavamo creando una nuova immagine,
‫iniziamo con un livello. Ogni livello riceve il proprio
‫SHA univoco che aiuta il sistema a identificare se quel livello è effettivamente uguale a un altro livello.
‫Diciamo solo che all'inizio di uno dei tuoi, potresti avere Ubuntu in fondo.
‫Questo è il primo livello nella tua immagine.
‫Quindi crei un Dockerfile, che aggiunge altri file e questo
‫è un altro livello sopra quell'immagine. Forse usiamo Apt per questo.
‫Poi nel tuo Dockerfile, apporti una modifica alle variabili di ambiente. Quella insieme è la tua immagine.
‫ok?
‫Potresti avere un'immagine diversa che inizia da debian: jessie e poi
‫su quell'immagine
‫potresti usare anche Apt per installare alcune cose, diciamo MySQL. Potresti copiare alcuni file, potresti aprire una porta.
‫Quindi ognuna
‫di queste modifiche apportate di solito nel Dockerfile, ma è possibile eseguire anche con il comando docker di commit che verificheremo tra un minuto.
‫Questa è anche un'altra immagine e questi sono tutti raggruppati insieme.
‫Cosa succede se ho un'altra immagine che usa anche la stessa versione di jessie?
‫Bene, quell'immagine può avere le sue modifiche sopra allo
‫stesso livello che ho nella mia cache. È qui che il concetto fondamentale della cache dei
‫livelli di immagine ci fa risparmiare un sacco di tempo e spazio. Perché non abbiamo bisogno di scaricare i layer che abbiamo già,
‫e ricorda che usa uno SHA univoco per ogni layer, quindi è garantito
‫che sia lo strato esatto di cui ha bisogno. Sa abbinarli tra Docker Hub e la nostra cache locale. Quando apportiamo modifiche alle nostre
‫immagini, creano più livelli.
‫Se decidiamo di volere che la stessa immagine
‫sia l'immagine di base per più livelli, memorizza sempre una sola copia di ogni livello.
‫In questo sistema, in realtà, uno dei maggiori vantaggi
‫è il fatto che non archiviamo più dati della stessa immagine più di una volta sul nostro file system.
‫Significa anche che durante il caricamento e il download non è
‫necessario caricare e scaricare
‫gli stessi livelli che abbiamo già dall'altra parte. Se dovessi avere la tua immagine ed è stato personalizzato che hai creato tu stesso, e poi hai
‫aggiunto, diciamo, un server Apache in cima
‫a quello come un altro livello nel tuo Dockerfile, e poi avresti aperto la porta 80. copiato il sito web A nell'immagine e poi nel sito Web B, si finirebbe
‫con due immagini.
‫Poi, alla fine, l'hai effettivamente detto di copiare nel codice sorgente, ma in
‫realtà hai finito con due Dockerfiles diversi per due diversi siti web, e ogni riga dei Dockerfiles era la stessa tranne che per l'ultimo bit in cui hai Lo dimostreremo tra un minuto. Questo crea un'immagine e questo crea un'immagine, ma gli unici file effettivamente memorizzati sono
‫questo, questo, questo strato e poi questo
‫piccolo strato e poi questo piccolo strato.
‫Quindi non memorizzeremo mai l'intera pila di livelli di immagine più di una volta se sono davvero gli stessi livelli.
‫Come funziona con i contenitori?
‫di eseguirne un contenitore, tutto ciò che fa Docker è che crea un
‫nuovo livello di lettura / scrittura per quel contenitore sopra quell'immagine Apache.
‫Se hai la tua immagine, diciamo che abbiamo la nostra immagine Apache, e decidiamo Quando stiamo esaminando il file system e queste cose, tutti i contenitori e le immagini
‫sembrano tutti come
‫un normale file system, ma sotto il driver di archiviazione che viene utilizzato da Docker si
‫sta effettivamente stratificando, come una pila di pancake, tutte queste modifiche su uno sopra l'altro.
‫Quindi se eseguissi due contenitori contemporaneamente con la stessa immagine Apache,
‫il contenitore 1 e il contenitore 2 mostrerebbero solo, in termini di spazio file, solo la differenza tra ciò che è accaduto su quel
‫contenitore live e ciò che è sta accadendo nell'immagine di base, che è di sola lettura. nel livello contenitore.
‫nel contenitore in esecuzione. da quelli nell'immagine Apache.
‫Quando esegui Container e stai modificando i file che stanno arrivando nell'immagine, diciamo che ho avviato il contenitore 3 questo è noto qui e memorizzare una copia di quel file Così ora il contenitore è in realtà solo il processo in esecuzione e quei file che sono diversi
‫e in realtà sono entrato e ho modificato un file contenuto in questa immagine come copy-on-write. Quello che fa è che il file system estrae quel file dall'immagine e lo copia in questa differenza. su. Se torniamo alla nostra lista di immagini e guardiamo di nuovo
‫questi comandi, guardiamo quello in basso e vediamo come le date sono diverse? Possiamo effettivamente vedere come questa immagine è stata modificata in Docker Hub ed è stata
‫aggiornata nel tempo, che queste modifiche non sono state modificate
‫al livello più basso in quattro settimane e quindi le ultime modifiche si sono verificate nelle ultime
‫due settimane.
‫Oh a proposito, non preoccuparti della parte mancante.
‫In realtà è solo un termine improprio all'interno dell'interfaccia di Docker.
‫Ciò non significa che qualcosa non va o è configurato male. Ciò che significa è che,
‫davvero, questa immagine mysql proprio qui è questo ID immagine. Sono solo dei livelli all'interno di questa immagine,
‫Gli altri livelli nell'immagine non sono effettivamente immagini. quindi non otterrebbero necessariamente il proprio ID immagine.
‫Personalmente, penso che sia un po 'fuorviante nell'interfaccia dirlo, ma è così che l'hanno scritto.
‫Quindi, ora che abbiamo avuto un'idea del comando della cronologia
‫per mostrarci di che immagine potrebbe essere fatta, usiamo il comando inspect.
‫Ciò che fa è questo ci dà tutti i dettagli dell'immagine.
‫Questo è fondamentalmente i metadati. metadati relativi a quell'immagine?
‫Ricordi quando abbiamo parlato del fatto che un'immagine è composta da due
‫parti, i binari e le sue dipendenze, e quindi i Bene, inspect ti restituisce i metadati.
‫Oltre alle informazioni di base, come l'ID dell'immagine e i suoi tag, ottieni tutti
‫i tipi di dettagli su come questa immagine si aspetta di essere eseguita.
‫In realtà ha la possibilità di esporre queste due porte all'interno dell'immagine in modo da sapere quando si desidera avviarla, quali porte è
‫necessario aprire all'interno dell'host Docker se si desidera che accetti le connessioni.
‫Si può effettivamente vedere che le variabili d'ambiente sono state passate,
‫inclusa la versione di Nginx che è in esecuzione e il percorso. eseguito all'avvio dell'immagine per impostazione predefinita.
‫È possibile visualizzare il comando che verrà
‫Ancora una volta, molte di queste cose possono effettivamente essere cambiate come abbiamo fatto
‫in precedenza con il comando di esecuzione del contenitore finestra mobile.
‫Ma questi ci mostrano tutti i valori predefiniti e alcune altre informazioni
‫interessanti come l'autore, e qui in basso, che è un'architettura di AMD64, che
‫è praticamente ciò che tutti i normali PC e Mac funzionano al giorno d'oggi.
‫In realtà non abbiamo troppe macchine a 32 bit, quindi questa è solo un'architettura Intel a 64 bit standard ed è progettata
‫per funzionare sul sistema operativo Linux.
‫Ok, una rapida recensione.
‫Quindi abbiamo imparato molto sulle immagini e su come sono fatte e
‫scopriamo che in realtà non sono così complesse. In realtà, si tratta solo di una serie di modifiche al file system e metadati relativi a tali modifiche.
‫Hai imparato che ogni livello ha la sua identità unica come SHA.
‫Vengono memorizzati solo una
‫volta su ciascun sistema, quindi su ogni daemon Docker, ogni livello viene rappresentato solo una volta nel file system.
‫Ciò ci consente
‫di risparmiare molto spazio e di trasferire i tempi di invio delle immagini tra registri come Docker Hub. un singolo livello di modifiche sopra un'immagine esistente.
‫E, in realtà, quando si avvia un contenitore, è solo
‫Quindi in realtà è in genere molto piccolo. Abbiamo appreso la storia e ispezionato
‫i comandi e come possono insegnarci cosa succede all'interno di un'immagine e come è stata realizzata.
‫