‫Oké, in deze lezing gaan we het hebben over beeldlagen.
‫Dit is dus een fundamenteel concept van hoe Docker werkt. Het gebruikt iets dat het union-bestandssysteem wordt
‫genoemd om een reeks wijzigingen in het bestandssysteem als een echt bestandssysteem te presenteren.
‫We gaan de geschiedenis induiken en commando's inspecteren en kijken hoe we ze kunnen gebruiken om
‫te begrijpen waar een afbeelding eigenlijk van gemaakt is. We gaan iets leren over het copy-on-write-concept
‫van hoe een container wordt uitgevoerd als een extra laag bovenop een afbeelding.
‫Wat bedoel ik met beeldlagen?
‫Het is eigenlijk volledig transparant voor je wanneer je Docker gebruikt, maar wanneer je begint te graven in
‫bepaalde commando's, zoals het geschiedeniscommando, de inspect en commit, begin je het gevoel te krijgen
‫dat een afbeelding niet een grote klodder data is die komt en gaat in één grote brok.
‫Rechts?
‫Als je merkt wanneer we Docker-trekkingen hebben gedaan, zie je soms woorden die aangeven dat er iets
‫is dat je al hebt, zoals dat je een deel ervan al in de cache hebt
‫opgeslagen, en dat komt allemaal neer op het feit dat afbeeldingen zijn ontworpen met het concept van het union-bestandssysteem om lagen over
‫de wijzigingen aan te brengen.
‫Als we even konden kijken naar wat we in Docker hebben... in Docker-afbeeldingen eigenlijk...
‫Een tijdje geleden waren we met Nginx aan het spelen met de tags. Rechts? We herinneren ons dat
‫de Nginx-afbeeldings-ID hetzelfde is en dat we verschillende tags hadden voor dezelfde afbeeldingsnaam.
‫Dus laten we een snelle docker-geschiedenis doen op nginx laatste.
‫Waar kijk ik hier naar?
‫Dit is geen lijst met dingen die daadwerkelijk in de container zijn gebeurd omdat het om een afbeelding gaat.
‫Dit is eigenlijk een geschiedenis van de beeldlagen.
‫Elke afbeelding begint vanaf het begin met een lege laag die kras wordt genoemd.
‫Dan is elke reeks wijzigingen die daarna op het bestandssysteem, in de afbeelding, plaatsvindt een andere laag.
‫Je hebt misschien één laag, je hebt misschien tientallen lagen en sommige lagen veranderen misschien niet in termen
‫van de bestandsgrootte.
‫Je zult hier opmerken dat we hier eigenlijk een wijziging hebben die gewoon een metadatawijziging was over welke
‫opdracht we daadwerkelijk gaan uitvoeren. We zullen dat in een klein beetje behandelen als we het
‫Docker-bestand doornemen.
‫Maar voor nu kun je zien dat deze een enorme hoeveelheid bestanden heeft toegevoegd van 123 MB.
‫Toen hebben we hier een wijziging aangebracht en een wijziging hier en ik
‫weet toevallig vanwege Dockerfiles dat dit eigenlijk gewoon Dockerfile-metadata-informatie is.
‫Als je omhoog gaat, hebben we wat meer gegevenswijzigingen.
‫Je zult zien dat dit eigenlijk heel anders is in een andere afbeelding.
‫Dus als we naar de docker-geschiedenis mysql gaan, heeft het een compleet andere set afbeeldingslagen.
‫Laat me dit een beetje voor je tekenen en misschien helpt dit.
‫Wanneer we een afbeelding starten, toen we
‫een nieuwe afbeelding maakten, beginnen we met één laag. Elke laag krijgt zijn eigen unieke SHA die het systeem helpt te identificeren of die
‫laag inderdaad hetzelfde is als een andere laag.
‫Laten we zeggen dat aan het begin van een van de uwe Ubuntu helemaal onderaan staat.
‫Dat is de eerste laag in je afbeelding.
‫Dan maak je een Dockerfile, die wat meer bestanden toevoegt en dat is weer een laag
‫bovenop die afbeelding. Misschien gebruiken we daarvoor Apt.
‫Vervolgens breng je in je Dockerfile een wijziging in de omgevingsvariabele aan. Dat samen is jouw imago.
‫OKE?
‫Je hebt misschien een andere afbeelding die begint met debian:jessie en dan kun je op die afbeelding
‫ook Apt gebruiken om wat
‫dingen te installeren, laten we zeggen MySQL. Je zou wat bestanden kunnen kopiëren, je zou een poort kunnen openen.
‫Dus elk van deze wijzigingen die je gewoonlijk aanbrengt in het Docker-bestand, maar je kunt ze ook
‫maken met het commit docker-commando dat we zo meteen zullen bekijken.
‫Dit is ook een andere afbeelding en die zijn allemaal bij elkaar gebundeld.
‫Wat gebeurt er als ik een andere afbeelding heb die ook dezelfde versie van jessie gebruikt?
‫Welnu, die afbeelding kan zijn eigen wijzigingen hebben bovenop dezelfde
‫laag die ik in mijn cache heb. Dit is waar het fundamentele concept van de cache van
‫afbeeldingslagen ons een hele hoop tijd en ruimte bespaart. Omdat we geen lagen hoeven te downloaden die we al
‫hebben, en onthoud dat het een unieke SHA gebruikt voor elke laag, dus het is gegarandeerd de
‫exacte laag die het nodig heeft. Het weet ze te matchen tussen Docker Hub en onze lokale cache. Als we
‫onze afbeeldingen wijzigen, creëren ze meer lagen.
‫Als we besluiten dat we dezelfde afbeelding als basisafbeelding willen hebben voor meer lagen, dan slaat het altijd maar
‫één kopie van elke laag op.
‫In dit systeem is een van de grootste voordelen dat we dezelfde afbeeldingsgegevens nooit meer dan één
‫keer op ons bestandssysteem opslaan.
‫Het betekent ook dat wanneer we uploaden en downloaden, we niet dezelfde
‫lagen hoeven
‫te uploaden en downloaden die we al aan de andere kant hebben. Als je je eigen afbeelding zou hebben en het
‫was de gewoonte dat je die zelf maakte, en je voegde daar, laten we zeggen, een Apache-server aan toe als een andere
‫laag in je Dockerfile, en dan zou je poort 80 openen. Toen, helemaal aan het einde, zei je dat het de broncode moest kopiëren, maar je
‫had uiteindelijk twee verschillende Docker-bestanden voor twee verschillende websites, en elke regel in de
‫Docker-bestanden was hetzelfde, behalve dat laatste stukje waar je Website kopieerde A in de afbeelding en dan Website B,
‫je zou eindigen met twee afbeeldingen. Dat laten we zo zien. Dit vormt één afbeelding en
‫dit vormt één afbeelding, maar de enige bestanden die daadwerkelijk worden opgeslagen, zijn deze, deze,
‫deze laag en dan deze kleine laag en dan deze kleine laag.
‫We slaan de hele stapel afbeeldingslagen dus nooit meer dan één keer op als het echt dezelfde lagen zijn.
‫Hoe werkt dit met containers?
‫Als je je afbeelding hebt, laten we zeggen dat we onze Apache-afbeelding hebben, en we besluiten er een
‫container van te maken, het enige dat Docker doet is een nieuwe lees-/schrijflaag voor die
‫container bovenop die Apache-afbeelding maken. Als we het bestandssysteem en deze dingen doornemen, zien
‫alle containers en de afbeeldingen er allemaal uit als een gewoon bestandssysteem, maar onder het opslagstuurprogramma dat door Docker
‫wordt gebruikt, is het eigenlijk gelaagd, zoals een stapel pannenkoeken, al deze
‫veranderingen op boven op elkaar.
‫Dus als ik twee containers tegelijkertijd van dezelfde Apache-image zou draaien, zouden container 1 en container 2 alleen worden
‫weergegeven, in termen van de bestandsruimte, ze zouden alleen het verschil zijn tussen wat
‫er is gebeurd op die actieve container en wat gebeurt in de basisafbeelding, die alleen-lezen is.
‫Wanneer u Containers uitvoert en bestanden wijzigt die door de afbeelding kwamen, laten
‫we zeggen dat ik container 3 startte, en ik ging naar binnen en veranderde een bestand dat in deze afbeelding in de
‫actieve container stond...
‫dit staat bekend als copy-on-write.
‫Wat dat doet, is dat het bestandssysteem dat bestand uit de afbeelding haalt en het naar deze differentiërende...
‫hier boven... en sla een kopie van dat bestand op in de containerlaag.
‫Dus nu is de container eigenlijk alleen maar het lopende proces en
‫die bestanden die anders zijn dan ze waren in de Apache-afbeelding.
‫Als we teruggaan naar onze lijst met afbeeldingen en we kijken opnieuw naar deze commando's, en we
‫kijken naar de onderste en zien hoe de datums verschillen? We kunnen zien dat deze afbeelding in Docker Hub is gewijzigd
‫en in de loop van de tijd is bijgewerkt, dat deze wijzigingen in
‫de onderste laag in vier weken niet zijn gewijzigd en dat de laatste wijzigingen in de afgelopen twee weken
‫hebben plaatsgevonden.
‫Oh trouwens, maak je geen zorgen over het ontbrekende deel.
‫Dat is eigenlijk gewoon een verkeerde benaming in de Docker-interface.
‫Het betekent niet dat er iets mis is of dat het verkeerd is geconfigureerd. Wat het betekent is dat deze
‫mysql-afbeelding hier deze afbeeldings-ID is.
‫De andere lagen in de afbeelding zijn zelf geen afbeeldingen.
‫Het zijn gewoon lagen in deze afbeelding,
‫en dus zouden ze daar niet noodzakelijk hun eigen afbeeldings-ID krijgen.
‫Persoonlijk vind ik het een beetje misleidend in de interface om dat te zeggen, maar zo schreven ze het.
‫Dus nu we een idee hebben van het geschiedeniscommando om ons te laten
‫zien waar een afbeelding van gemaakt zou kunnen zijn, laten we het inspect commando gebruiken.
‫Dit geeft ons alle details over de afbeelding.
‫Dit zijn eigenlijk de metadata. Weet je nog dat we het erover hadden
‫dat een afbeelding uit twee delen bestaat, de binaire bestanden
‫en zijn afhankelijkheden, en dan de metadata over die afbeelding? Nou, inspect geeft je de metadata terug.
‫Naast alleen de basisinformatie, zoals de afbeeldings-ID en de bijbehorende tags, krijg je allerlei details over hoe deze afbeelding
‫verwacht te worden uitgevoerd.
‫Het heeft eigenlijk de mogelijkheid om deze twee poorten in de afbeelding zichtbaar te maken, zodat je weet wanneer je het
‫wilt starten, welke poorten je moet openen in je Docker-host als je wilt dat het verbindingen accepteert.
‫Je kunt echt zien dat omgevingsvariabelen zijn doorgegeven, inclusief de versie van
‫Nginx die wordt uitgevoerd en het pad. U kunt de opdracht daadwerkelijk zien die wordt uitgevoerd wanneer u de
‫afbeelding standaard opstart.
‫Nogmaals, veel van deze dingen kunnen worden gewijzigd zoals we eerder deden met de opdracht docker
‫container run.
‫Maar deze tonen ons alle standaardinstellingen en wat andere interessante informatie zoals de auteur, en
‫hier onderaan, dat het een architectuur is van AMD64, wat zo ongeveer is waar alle normale pc's en
‫Macs tegenwoordig op draaien.
‫We hebben niet echt veel 32-bits machines in de buurt, dus dit is slechts een
‫standaard 64-bits Intel-architectuur en is ontworpen om op het Linux-besturingssysteem te draaien.
‫Oké, even een korte review.
‫We hebben dus veel geleerd over afbeeldingen en hoe ze zijn gemaakt, en we
‫ontdekken dat ze eigenlijk niet zo ingewikkeld zijn. Eigenlijk zijn het slechts een reeks wijzigingen in het bestandssysteem en metadata over die wijzigingen.
‫Je hebt geleerd dat elke laag zijn eigen unieke identiteit heeft als SHA.
‫Ze worden maar één keer op elk systeem opgeslagen, dus op elke Docker-daemon wordt elke laag maar één keer
‫weergegeven in het bestandssysteem.
‫Dat levert ons veel ruimtebesparing op, evenals overdrachtstijd bij het heen en weer verzenden van afbeeldingen
‫tussen registers, zoals Docker Hub. En, echt, wanneer u een container
‫start, is het slechts een enkele laag met wijzigingen bovenop een bestaande afbeelding.
‫Dus het is eigenlijk meestal heel klein. We leerden over de geschiedenis en inspecteren commando's en hoe ze
‫ons kunnen leren wat er in een afbeelding gebeurt en hoe het is gemaakt.