1 00:00:05,810 --> 00:00:10,720 ‫Deze sectie zal vol staan met lezingen en opdrachten rond persistente data. 2 00:00:11,230 --> 00:00:16,490 ‫Eerst gaan we de problemen van persistente gegevens bespreken en hoe dat in de eerste 3 00:00:16,490 --> 00:00:18,280 ‫plaats zelfs een probleem werd. 4 00:00:18,290 --> 00:00:23,640 ‫Sleutelbegrippen daar die u moet begrijpen, zijn het idee van onveranderlijke infrastructuur. 5 00:00:23,810 --> 00:00:28,580 ‫En het idee rond containers is van nature vluchtig in ontwerp. 6 00:00:28,880 --> 00:00:36,680 ‫Die behandelen we in de eerste lezing. Daarna duiken we in datavolumes en hoe die een 7 00:00:36,680 --> 00:00:44,270 ‫aantal van onze problemen rond persistente data oplossen. Vervolgens gaan we in op bind-mounts en hoe dat 8 00:00:44,360 --> 00:00:50,660 ‫verschillende problemen met persistente gegevens oplost. Dan eindigen we deze sectie met een aantal opdrachten over 9 00:00:50,720 --> 00:00:57,530 ‫het bewaren van databasegegevens en het vervangen van containers voor databases. En dan ook rond het daadwerkelijk monteren van 10 00:00:57,740 --> 00:01:03,320 ‫code in een container vanaf de host terwijl u deze aan het bewerken bent, 11 00:01:03,320 --> 00:01:11,560 ‫zodat u die code live in de container kunt uitvoeren. Vereisten voor deze eerste lezing zijn alleen inzicht in het 12 00:01:11,560 --> 00:01:16,970 ‫uitvoeren van containers en de container- en afbeeldingsconcepten die we tot nu toe hebben besproken. 13 00:01:17,050 --> 00:01:23,230 ‫Tot nu toe maakte u zich alleen zorgen over wat er nodig is om een container te laten draaien, niet over de unieke gegevens die kunnen 14 00:01:23,230 --> 00:01:24,920 ‫worden gemaakt zodra een container wordt uitgevoerd. 15 00:01:25,840 --> 00:01:29,200 ‫Containers zijn bedoeld om onveranderlijk en vluchtig te zijn. 16 00:01:29,320 --> 00:01:34,220 ‫Dat zijn gewoon mooie modewoorden voor onveranderlijk en tijdelijk, of wegwerpbaar. 17 00:01:34,480 --> 00:01:40,180 ‫Het idee hier is dat we gewoon een container kunnen weggooien en een nieuwe kunnen maken van een afbeelding, 18 00:01:40,180 --> 00:01:40,770 ‫toch? 19 00:01:41,790 --> 00:01:47,820 ‫Dan hebben we het niet over een daadwerkelijke beperking van containers, maar meer over een ontwerpdoel, of 20 00:01:47,820 --> 00:01:49,070 ‫een best practice. 21 00:01:49,080 --> 00:01:54,690 ‫Dit is het idee van een onveranderlijke infrastructuur waar we dingen niet veranderen als ze eenmaal draaien. 22 00:01:54,840 --> 00:02:00,330 ‫Als er een configuratiewijziging moet plaatsvinden, of misschien moet de containerversie-upgrade plaatsvinden, dan implementeren 23 00:02:00,330 --> 00:02:02,420 ‫we een geheel nieuwe container. 24 00:02:02,490 --> 00:02:08,370 ‫Dit geeft ons enorme voordelen in betrouwbaarheid en consistentie, en het reproduceerbaar maken van wijzigingen. 25 00:02:08,490 --> 00:02:10,350 ‫Maar er is een afweging. 26 00:02:10,350 --> 00:02:16,140 ‫Hoe zit het met de unieke gegevens die uw app zal produceren? Die databases, of een sleutelwaarde, of iets anders dat 27 00:02:16,140 --> 00:02:18,150 ‫uw app in een bestand uitspuugt? 28 00:02:18,330 --> 00:02:24,810 ‫In het ideale geval mogen de containers niet uw unieke gegevens bevatten die zijn vermengd met de binaire bestanden van de toepassing. Dit staat bekend als "scheiding 29 00:02:24,810 --> 00:02:30,340 ‫van zorgen" en Docker geeft ons hier eigenlijk een groot voordeel. 30 00:02:30,450 --> 00:02:36,780 ‫We kunnen onze applicatie bijwerken door een nieuwe container opnieuw te maken, met een bijgewerkte versie van onze app, en idealiter zijn onze 31 00:02:36,990 --> 00:02:42,530 ‫unieke gegevens nog steeds waar ze moeten zijn en werden ze voor ons bewaard terwijl onze container werd gerecycled. 32 00:02:42,540 --> 00:02:48,510 ‫Voor het geval je het tot nu toe nog niet gemerkt hebt, de containers die we hebben gebruikt, waren standaard persistent. 33 00:02:48,510 --> 00:02:53,880 ‫Alle wijzigingen daarin werden bewaard tijdens herstarts en herstarts totdat we de container verwijderden. 34 00:02:54,240 --> 00:02:57,160 ‫Alleen omdat we de container hebben gestopt of de host opnieuw hebben 35 00:02:57,300 --> 00:03:00,030 ‫opgestart, betekent niet dat de bestandswijzigingen van de container verdwijnen. 36 00:03:00,210 --> 00:03:05,910 ‫Pas wanneer we de container verwijderen, verdwijnt de UFS-laag, maar we willen dat naar 37 00:03:05,910 --> 00:03:07,160 ‫believen kunnen doen. 38 00:03:07,170 --> 00:03:13,320 ‫Dit probleem van unieke data staat in de branche bekend als 'persistent data' en tot containers hadden 39 00:03:13,320 --> 00:03:19,230 ‫we daar niet echt een naam voor. Omdat, nou ja, de meeste dingen die we hebben gebouwd, waren 40 00:03:19,230 --> 00:03:24,090 ‫persistent, zoals je die oude servers kent waarop die oude app al vijf of tien jaar of langer draait. 41 00:03:24,270 --> 00:03:26,850 ‫Alles was standaard persistent. 42 00:03:26,850 --> 00:03:32,400 ‫In de nieuwe wereld van het automatisch schalen van containers en applicaties vormen persistente gegevens een 43 00:03:32,400 --> 00:03:33,280 ‫uniek probleem. 44 00:03:33,420 --> 00:03:36,640 ‫Docker heeft twee oplossingen voor dit probleem, 45 00:03:36,720 --> 00:03:42,450 ‫bekend als "datavolumes" en "bind mounts". " Docker-volumes zijn een configuratieoptie voor 46 00:03:42,450 --> 00:03:46,620 ‫een container die een speciale locatie creëert buiten het uniebestandssysteem 47 00:03:46,620 --> 00:03:50,130 ‫van die container om unieke gegevens op te slaan. 48 00:03:50,210 --> 00:03:55,470 ‫Hierdoor blijft het behouden bij het verwijderen van containers en kunnen we het aan elke gewenste container bevestigen. 49 00:03:55,940 --> 00:03:58,210 ‫En de container ziet het gewoon als een lokaal bestandspad. 50 00:03:58,440 --> 00:04:05,670 ‫Dan zijn er bind-mounts, wat simpelweg betekent dat we een hostdirectory of bestand in een container delen of mounten. 51 00:04:05,970 --> 00:04:10,470 ‫Nogmaals, het ziet er gewoon uit als een lokaal bestandspad of een mappad naar de container. 52 00:04:10,470 --> 00:04:12,590 ‫Het zal niet echt weten dat het van de host komt.