1
00:00:00,650 --> 00:00:07,960
‫Bene, in questa conferenza parleremo dei livelli dell'immagine.

2
00:00:07,960 --> 00:00:14,590
‫Quindi questo è un concetto fondamentale di come funziona Docker. Usa qualcosa chiamato il file system union

3
00:00:15,280 --> 00:00:21,550
‫per presentare una serie di modifiche al file system come un vero file system.

4
00:00:21,550 --> 00:00:26,950
‫Entreremo nella storia e controlleremo i comandi e vedremo come possiamo usarli per

5
00:00:26,980 --> 00:00:33,070
‫capire di cosa è fatta realmente un'immagine. Impareremo un po 'sulla copia sul concetto di

6
00:00:33,430 --> 00:00:38,140
‫scrittura di come un contenitore viene eseguito come un livello aggiuntivo sopra un'immagine.

7
00:00:40,970 --> 00:00:43,020
‫Cosa intendo per livelli di immagine?

8
00:00:43,100 --> 00:00:49,580
‫un'immagine non è un grosso blob di dati che viene e va in un enorme pezzo.

9
00:00:49,580 --> 00:00:55,430
‫In realtà è completamente trasparente per te quando usi Docker, ma quando inizi a

10
00:00:55,460 --> 00:01:01,500
‫scavare in determinati comandi, come il comando history, inspect e commit, inizi a capire che

11
00:01:01,580 --> 00:01:02,290
‫Destra?

12
00:01:02,330 --> 00:01:07,970
‫Se noti che effettivamente abbiamo fatto Docker, alcune volte potresti vedere le parole che indicano

13
00:01:07,970 --> 00:01:13,580
‫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

14
00:01:13,580 --> 00:01:20,930
‫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.

15
00:01:20,930 --> 00:01:22,890
‫di fare strati sui cambiamenti. Quindi, facciamo una rapida cronologia del docker su nginx più recente.

16
00:01:22,950 --> 00:01:31,300
‫Se potessimo rapidamente vedere cosa abbiamo in Docker. immagini Docker. Cosa sto guardando qui?

17
00:01:32,370 --> 00:01:38,400
‫Questo non è un elenco di cose realmente accadute nel contenitore perché si tratta di un'immagine.

18
00:01:38,410 --> 00:01:43,980
‫Questa è in realtà una cronologia dei livelli dell'immagine.

19
00:01:44,100 --> 00:01:49,150
‫Ogni immagine inizia fin dall'inizio con un livello vuoto noto come zero.

20
00:01:49,420 --> 00:01:53,670
‫Quindi ogni serie di modifiche che si verifica dopo quella sul file system, nell'immagine, è un altro livello.

21
00:01:53,820 --> 00:02:01,320
‫Potresti avere un livello, potresti avere dozzine di livelli e alcuni livelli forse non

22
00:02:01,470 --> 00:02:05,170
‫cambieranno in termini di dimensioni del file.

23
00:02:05,460 --> 00:02:12,310
‫Qui noterete che in realtà qui abbiamo un cambiamento che

24
00:02:12,660 --> 00:02:20,340
‫era semplicemente una modifica dei metadati su quale comando avremmo effettivamente eseguito. 'quando andremo sul Dockerfile.

25
00:02:20,670 --> 00:02:27,390
‫Ne parleremo un po

26
00:02:27,390 --> 00:02:28,700
‫Ma, per ora, puoi vedere che questo ha aggiunto un'enorme quantità di file di 123 MB.

27
00:02:28,710 --> 00:02:35,130
‫Poi abbiamo apportato una modifica qui e un cambiamento qui e mi capita di sapere a causa di Dockerfiles che queste sono

28
00:02:35,130 --> 00:02:39,360
‫in realtà solo informazioni sui metadati Dockerfile.

29
00:02:39,390 --> 00:02:39,920
‫Mentre salirai, avremo altre modifiche ai dati.

30
00:02:40,170 --> 00:02:46,690
‫Vedrai che questo è in realtà abbastanza diverso in un'altra immagine.

31
00:02:46,830 --> 00:02:51,330
‫Quindi, se andiamo alla storia della finestra mobile mysql, ha un set di livelli di immagine completamente diverso.

32
00:02:51,330 --> 00:02:54,830
‫Lascia che ti disegna un po 'per te e forse questo ti aiuterà.

33
00:02:54,990 --> 00:03:01,090
‫Quando iniziamo un'immagine, quando stavamo creando una nuova immagine,

34
00:03:01,990 --> 00:03:04,680
‫iniziamo con un livello. Ogni livello riceve il proprio

35
00:03:04,680 --> 00:03:14,650
‫SHA univoco che aiuta il sistema a identificare se quel livello è effettivamente uguale a un altro livello.

36
00:03:16,140 --> 00:03:20,070
‫Diciamo solo che all'inizio di uno dei tuoi, potresti avere Ubuntu in fondo.

37
00:03:20,400 --> 00:03:24,440
‫Questo è il primo livello nella tua immagine.

38
00:03:24,570 --> 00:03:33,030
‫Quindi crei un Dockerfile, che aggiunge altri file e questo

39
00:03:33,480 --> 00:03:36,110
‫è un altro livello sopra quell'immagine. Forse usiamo Apt per questo.

40
00:03:36,390 --> 00:03:42,630
‫Poi nel tuo Dockerfile, apporti una modifica alle variabili di ambiente. Quella insieme è la tua immagine.

41
00:03:43,970 --> 00:03:46,920
‫ok?

42
00:03:46,920 --> 00:03:53,460
‫Potresti avere un'immagine diversa che inizia da debian: jessie e poi

43
00:03:53,490 --> 00:03:56,550
‫su quell'immagine

44
00:03:58,020 --> 00:04:10,290
‫potresti usare anche Apt per installare alcune cose, diciamo MySQL. Potresti copiare alcuni file, potresti aprire una porta.

45
00:04:12,390 --> 00:04:13,390
‫Quindi ognuna

46
00:04:13,570 --> 00:04:24,630
‫di queste modifiche apportate di solito nel Dockerfile, ma è possibile eseguire anche con il comando docker di commit che verificheremo tra un minuto.

47
00:04:24,630 --> 00:04:28,340
‫Questa è anche un'altra immagine e questi sono tutti raggruppati insieme.

48
00:04:28,340 --> 00:04:36,700
‫Cosa succede se ho un'altra immagine che usa anche la stessa versione di jessie?

49
00:04:37,100 --> 00:04:42,110
‫Bene, quell'immagine può avere le sue modifiche sopra allo

50
00:04:42,110 --> 00:04:45,680
‫stesso livello che ho nella mia cache. È qui che il concetto fondamentale della cache dei

51
00:04:45,680 --> 00:04:50,500
‫livelli di immagine ci fa risparmiare un sacco di tempo e spazio. Perché non abbiamo bisogno di scaricare i layer che abbiamo già,

52
00:04:52,300 --> 00:04:57,900
‫e ricorda che usa uno SHA univoco per ogni layer, quindi è garantito

53
00:04:57,910 --> 00:05:01,720
‫che sia lo strato esatto di cui ha bisogno. Sa abbinarli tra Docker Hub e la nostra cache locale. Quando apportiamo modifiche alle nostre

54
00:05:03,020 --> 00:05:09,530
‫immagini, creano più livelli.

55
00:05:09,950 --> 00:05:16,430
‫Se decidiamo di volere che la stessa immagine

56
00:05:16,430 --> 00:05:22,040
‫sia l'immagine di base per più livelli, memorizza sempre una sola copia di ogni livello.

57
00:05:22,040 --> 00:05:29,060
‫In questo sistema, in realtà, uno dei maggiori vantaggi

58
00:05:29,600 --> 00:05:34,500
‫è il fatto che non archiviamo più dati della stessa immagine più di una volta sul nostro file system.

59
00:05:34,700 --> 00:05:42,890
‫Significa anche che durante il caricamento e il download non è

60
00:05:42,890 --> 00:05:45,990
‫necessario caricare e scaricare

61
00:05:46,160 --> 00:05:52,100
‫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

62
00:05:52,340 --> 00:05:54,500
‫aggiunto, diciamo, un server Apache in cima

63
00:05:54,500 --> 00:05:59,840
‫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

64
00:05:59,840 --> 00:06:01,130
‫con due immagini.

65
00:06:01,130 --> 00:06:11,210
‫Poi, alla fine, l'hai effettivamente detto di copiare nel codice sorgente, ma in

66
00:06:11,660 --> 00:06:22,800
‫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

67
00:06:22,800 --> 00:06:34,830
‫questo, questo, questo strato e poi questo

68
00:06:34,830 --> 00:06:40,730
‫piccolo strato e poi questo piccolo strato.

69
00:06:40,730 --> 00:06:48,280
‫Quindi non memorizzeremo mai l'intera pila di livelli di immagine più di una volta se sono davvero gli stessi livelli.

70
00:06:48,280 --> 00:06:57,090
‫Come funziona con i contenitori?

71
00:06:57,120 --> 00:07:04,940
‫di eseguirne un contenitore, tutto ciò che fa Docker è che crea un

72
00:07:05,130 --> 00:07:12,040
‫nuovo livello di lettura / scrittura per quel contenitore sopra quell'immagine Apache.

73
00:07:12,360 --> 00:07:20,950
‫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

74
00:07:20,990 --> 00:07:22,490
‫sembrano tutti come

75
00:07:23,450 --> 00:07:32,680
‫un normale file system, ma sotto il driver di archiviazione che viene utilizzato da Docker si

76
00:07:32,680 --> 00:07:40,890
‫sta effettivamente stratificando, come una pila di pancake, tutte queste modifiche su uno sopra l'altro.

77
00:07:41,860 --> 00:07:48,190
‫Quindi se eseguissi due contenitori contemporaneamente con la stessa immagine Apache,

78
00:07:48,190 --> 00:07:54,940
‫il contenitore 1 e il contenitore 2 mostrerebbero solo, in termini di spazio file, solo la differenza tra ciò che è accaduto su quel

79
00:07:54,940 --> 00:07:59,380
‫contenitore live e ciò che è sta accadendo nell'immagine di base, che è di sola lettura. nel livello contenitore.

80
00:07:59,380 --> 00:08:01,440
‫nel contenitore in esecuzione. da quelli nell'immagine Apache.

81
00:08:01,450 --> 00:08:10,530
‫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

82
00:08:10,950 --> 00:08:17,910
‫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

83
00:08:17,910 --> 00:08:25,700
‫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

84
00:08:25,980 --> 00:08:31,020
‫aggiornata nel tempo, che queste modifiche non sono state modificate

85
00:08:31,020 --> 00:08:39,690
‫al livello più basso in quattro settimane e quindi le ultime modifiche si sono verificate nelle ultime

86
00:08:39,690 --> 00:08:41,010
‫due settimane.

87
00:08:41,010 --> 00:08:44,900
‫Oh a proposito, non preoccuparti della parte mancante.

88
00:08:45,050 --> 00:08:52,280
‫In realtà è solo un termine improprio all'interno dell'interfaccia di Docker.

89
00:08:53,060 --> 00:08:59,130
‫Ciò non significa che qualcosa non va o è configurato male. Ciò che significa è che,

90
00:08:59,150 --> 00:09:04,960
‫davvero, questa immagine mysql proprio qui è questo ID immagine. Sono solo dei livelli all'interno di questa immagine,

91
00:09:05,090 --> 00:09:10,720
‫Gli altri livelli nell'immagine non sono effettivamente immagini. quindi non otterrebbero necessariamente il proprio ID immagine.

92
00:09:11,110 --> 00:09:17,920
‫Personalmente, penso che sia un po 'fuorviante nell'interfaccia dirlo, ma è così che l'hanno scritto.

93
00:09:18,160 --> 00:09:26,340
‫Quindi, ora che abbiamo avuto un'idea del comando della cronologia

94
00:09:26,400 --> 00:09:31,370
‫per mostrarci di che immagine potrebbe essere fatta, usiamo il comando inspect.

95
00:09:31,380 --> 00:09:38,140
‫Ciò che fa è questo ci dà tutti i dettagli dell'immagine.

96
00:09:38,140 --> 00:09:39,180
‫Questo è fondamentalmente i metadati. metadati relativi a quell'immagine?

97
00:09:40,290 --> 00:09:43,570
‫Ricordi quando abbiamo parlato del fatto che un'immagine è composta da due

98
00:09:43,700 --> 00:09:46,580
‫parti, i binari e le sue dipendenze, e quindi i Bene, inspect ti restituisce i metadati.

99
00:09:46,580 --> 00:09:53,080
‫Oltre alle informazioni di base, come l'ID dell'immagine e i suoi tag, ottieni tutti

100
00:09:53,150 --> 00:09:55,980
‫i tipi di dettagli su come questa immagine si aspetta di essere eseguita.

101
00:09:56,030 --> 00:10:00,460
‫In realtà ha la possibilità di esporre queste due porte all'interno dell'immagine in modo da sapere quando si desidera avviarla, quali porte è

102
00:10:00,950 --> 00:10:03,350
‫necessario aprire all'interno dell'host Docker se si desidera che accetti le connessioni.

103
00:10:03,440 --> 00:10:07,030
‫Si può effettivamente vedere che le variabili d'ambiente sono state passate,

104
00:10:07,040 --> 00:10:11,090
‫inclusa la versione di Nginx che è in esecuzione e il percorso. eseguito all'avvio dell'immagine per impostazione predefinita.

105
00:10:12,310 --> 00:10:17,740
‫È possibile visualizzare il comando che verrà

106
00:10:17,740 --> 00:10:23,200
‫Ancora una volta, molte di queste cose possono effettivamente essere cambiate come abbiamo fatto

107
00:10:23,530 --> 00:10:27,970
‫in precedenza con il comando di esecuzione del contenitore finestra mobile.

108
00:10:27,970 --> 00:10:32,280
‫Ma questi ci mostrano tutti i valori predefiniti e alcune altre informazioni

109
00:10:32,290 --> 00:10:34,740
‫interessanti come l'autore, e qui in basso, che è un'architettura di AMD64, che

110
00:10:34,840 --> 00:10:39,820
‫è praticamente ciò che tutti i normali PC e Mac funzionano al giorno d'oggi.

111
00:10:39,970 --> 00:10:48,850
‫In realtà non abbiamo troppe macchine a 32 bit, quindi questa è solo un'architettura Intel a 64 bit standard ed è progettata

112
00:10:48,940 --> 00:10:51,130
‫per funzionare sul sistema operativo Linux.

113
00:10:51,130 --> 00:10:58,330
‫Ok, una rapida recensione.

114
00:10:58,330 --> 00:11:04,790
‫Quindi abbiamo imparato molto sulle immagini e su come sono fatte e

115
00:11:04,810 --> 00:11:09,550
‫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.

116
00:11:09,550 --> 00:11:15,790
‫Hai imparato che ogni livello ha la sua identità unica come SHA.

117
00:11:15,790 --> 00:11:16,790
‫Vengono memorizzati solo una

118
00:11:16,870 --> 00:11:21,420
‫volta su ciascun sistema, quindi su ogni daemon Docker, ogni livello viene rappresentato solo una volta nel file system.

119
00:11:21,430 --> 00:11:22,330
‫Ciò ci consente

120
00:11:22,480 --> 00:11:28,600
‫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.

121
00:11:28,720 --> 00:11:36,280
‫E, in realtà, quando si avvia un contenitore, è solo

122
00:11:36,340 --> 00:11:38,500
‫Quindi in realtà è in genere molto piccolo. Abbiamo appreso la storia e ispezionato

123
00:11:38,530 --> 00:11:44,770
‫i comandi e come possono insegnarci cosa succede all'interno di un'immagine e come è stata realizzata.

124
00:11:44,830 --> 00:11:49,990
‫

125
00:11:50,010 --> 00:11:51,710
‫

126
00:11:51,870 --> 00:12:01,410
‫

127
00:12:02,450 --> 00:12:06,940
‫

128
00:12:07,080 --> 00:12:40,480
‫