1 00:00:05,810 --> 00:00:10,720 ‫Questa sezione sarà piena di lezioni e compiti su dati persistenti. 2 00:00:11,230 --> 00:00:16,490 ‫In primo luogo, discuteremo i problemi dei dati persistenti e in che modo anche 3 00:00:16,490 --> 00:00:18,280 ‫questo è diventato un problema. 4 00:00:18,290 --> 00:00:23,640 ‫I concetti chiave che devi capire sono l'idea di un'infrastruttura immutabile. 5 00:00:23,810 --> 00:00:28,580 ‫E l'idea di contenitori è naturalmente effimera nel design. 6 00:00:28,880 --> 00:00:36,680 ‫Copriremo quelli nella prima lezione. Poi ci tufferemo nei volumi di dati e come quelli 7 00:00:36,680 --> 00:00:44,270 ‫che risolvono alcuni dei nostri problemi relativi ai dati persistenti. Quindi analizzeremo anche i bind mounts e come 8 00:00:44,360 --> 00:00:50,660 ‫risolviamo diversi problemi con i dati persistenti. preservare i dati del database, sostituendo i contenitori per i database. 9 00:00:50,720 --> 00:00:57,530 ‫Quindi finiremo questa sezione con un paio di compiti su come E poi anche attorno al montaggio effettivo del 10 00:00:57,740 --> 00:01:03,320 ‫codice in un contenitore dall'host mentre lo stai modificando, in modo che 11 00:01:03,320 --> 00:01:11,560 ‫tu possa eseguire quel codice all'interno del contenitore live. I requisiti per questa prima lezione sono solo capire come 12 00:01:11,560 --> 00:01:16,970 ‫eseguire i contenitori e i concetti di contenitore e immagine che abbiamo discusso finora. 13 00:01:17,050 --> 00:01:23,230 ‫Fino ad ora, ti sei preoccupato solo di ciò che è necessario per eseguire un contenitore, non dei dati univoci che potrebbero essere 14 00:01:23,230 --> 00:01:24,920 ‫creati dopo l'esecuzione di un contenitore. 15 00:01:25,840 --> 00:01:29,200 ‫I contenitori sono pensati per essere immutabili ed effimeri. 16 00:01:29,320 --> 00:01:34,220 ‫Quelle sono solo parole d'ordine di fantasia per immutabili e temporanee o usa e getta. 17 00:01:34,480 --> 00:01:40,180 ‫L'idea qui è che possiamo semplicemente buttare via un contenitore e crearne uno nuovo da 18 00:01:40,180 --> 00:01:40,770 ‫un'immagine, giusto? 19 00:01:41,790 --> 00:01:47,820 ‫Quindi non stiamo parlando di una reale limitazione dei contenitori, ma più di un obiettivo di progettazione o 20 00:01:47,820 --> 00:01:49,070 ‫di una buona pratica. 21 00:01:49,080 --> 00:01:54,690 ‫Questa è l'idea di un'infrastruttura immutabile in cui non cambiamo le cose una volta che sono in esecuzione. 22 00:01:54,840 --> 00:02:00,330 ‫Se è necessario che si verifichi una modifica della configurazione, o se è necessario che l'aggiornamento della versione del contenitore 23 00:02:00,330 --> 00:02:02,420 ‫avvenga, è necessario ridistribuire un nuovo contenitore. 24 00:02:02,490 --> 00:02:08,370 ‫Questo ci dà enormi benefici in termini di affidabilità e coerenza e rende le modifiche riproducibili. 25 00:02:08,490 --> 00:02:10,350 ‫Ma c'è un compromesso. 26 00:02:10,350 --> 00:02:16,140 ‫E i dati unici che la tua app produrrà? Quei database, o un archivio di valori chiave o qualsiasi altra cosa 27 00:02:16,140 --> 00:02:18,150 ‫che la tua app sputa in un file? 28 00:02:18,330 --> 00:02:24,810 ‫Idealmente, i contenitori non dovrebbero contenere i dati univoci mescolati con i binari dell'applicazione. Questo è noto come "separazione delle 29 00:02:24,810 --> 00:02:30,340 ‫preoccupazioni" e Docker ci offre in realtà un grande vantaggio qui. 30 00:02:30,450 --> 00:02:36,780 ‫Possiamo aggiornare la nostra applicazione ricreando un nuovo contenitore, con una versione aggiornata della nostra app, e idealmente, i nostri dati 31 00:02:36,990 --> 00:02:42,530 ‫unici sono ancora dove deve essere e sono stati conservati per noi mentre il nostro contenitore è stato riciclato. 32 00:02:42,540 --> 00:02:48,510 ‫Nel caso non l'avessi notato finora, i contenitori che stavamo usando, per impostazione predefinita, erano persistenti. 33 00:02:48,510 --> 00:02:53,880 ‫Eventuali modifiche in loro sono state effettivamente mantenute attraverso riavvii e riavvii finché non abbiamo rimosso il contenitore. 34 00:02:54,240 --> 00:02:57,160 ‫Solo perché abbiamo fermato il container o riavviato l'host, non 35 00:02:57,300 --> 00:03:00,030 ‫significa che le modifiche al file del contenitore andranno via. 36 00:03:00,210 --> 00:03:05,910 ‫È solo quando rimuoviamo il contenitore che il livello UFS scompare, ma vogliamo essere in grado 37 00:03:05,910 --> 00:03:07,160 ‫di farlo a volontà. 38 00:03:07,170 --> 00:03:13,320 ‫Questo problema di dati univoci è noto nel settore come "dati persistenti" e fino a quando i 39 00:03:13,320 --> 00:03:19,230 ‫container non hanno realmente un nome per questo. Perché, beh, la maggior parte delle cose che abbiamo costruito erano 40 00:03:19,230 --> 00:03:24,090 ‫persistenti, come sai quei vecchi server che eseguivano quella vecchia app per cinque o dieci anni o più. 41 00:03:24,270 --> 00:03:26,850 ‫Tutto era persistente per impostazione predefinita. 42 00:03:26,850 --> 00:03:32,400 ‫Ora nel nuovo mondo dei contenitori e del ridimensionamento automatico delle applicazioni, i dati persistenti creano 43 00:03:32,400 --> 00:03:33,280 ‫un problema unico. 44 00:03:33,420 --> 00:03:36,640 ‫Docker ha due soluzioni a questo problema, note 45 00:03:36,720 --> 00:03:42,450 ‫come "volumi di dati" e "bind mounts". "I volumi Docker sono un'opzione di configurazione per 46 00:03:42,450 --> 00:03:46,620 ‫un contenitore che crea una posizione speciale al di fuori del 47 00:03:46,620 --> 00:03:50,130 ‫file system union del contenitore per memorizzare dati univoci. 48 00:03:50,210 --> 00:03:55,470 ‫Questo lo mantiene attraverso le rimozioni dei container e ci consente di collegarlo a qualsiasi contenitore che vogliamo. 49 00:03:55,940 --> 00:03:58,210 ‫E il contenitore lo vede come un percorso di file locale. 50 00:03:58,440 --> 00:04:05,670 ‫Poi ci sono bind mounts, che semplicemente condividono o montano una directory host o un file in un contenitore. 51 00:04:05,970 --> 00:04:10,470 ‫Di nuovo, assomiglierà al contenitore di un percorso file locale o di una directory. 52 00:04:10,470 --> 00:04:12,590 ‫In realtà non saprà che proviene dall'host.