‫Wel Hallo?
‫Of moet ik zeggen welkom in de toekomst van softwarebeheer met Docker en containertooling?
‫Deze video gaat specifiek over Docker.
‫Het had in de loop der jaren veel tools, maar deze video gaat over de drie
‫belangrijkste innovaties die de hele software-evolutie van Docker in 2013 begonnen.
‫Dat zijn voornamelijk drie dingen: de Docker-image, het Docker-register en vervolgens de Docker-container.
‫De meesten van ons denken bij Docker aan de container.
‫Maar deze drie innovaties gaan samen als brood en boter, en ze noemen het Add, Docker, build,
‫ship run.
‫Dat zijn de drie stappen om voorheen niet-container-ID-software te nemen, er een docker-image van te maken, het in een register te plaatsen, het naar de plaats
‫te brengen waar je het moet uitvoeren en er uiteindelijk een container van te maken.
‫In feite, de Ciencia voor de Cloud Native Computing Foundation, waar veel van de tools over zullen
‫praten in al mijn video's, die producten en tools en workflows gaan er in de meeste gevallen
‫van uit dat je een containerworkflow gebruikt, een build ship run .
‫Dus laten we deze opsplitsen en precies wat de drie zijn.
‫Ten eerste, het containerbeeld en ik beschouw het graag als een universele app-packer en we hebben in de loop der
‫jaren veel pakketbeheerders gehad.
‫In feite ben ik de tel kwijtgeraakt en heb ik al een tijdje alle pakketbeheerders gezien, maar er
‫is nooit iets geweest dat ik me kan herinneren dat cross-OS cross-platform en applicatietaal-agnostisch was, wat betekent dat het overal zal draaien en
‫het draait op alles, zolang het maar Linux of Windows draait.
‫Laten we nu eens heel snel kijken naar een Docker-bestand, het recept of de set instructies om een
‫container-image te maken, docker-image en container-image zijn dezelfde term voor hetzelfde.
‫De Docker-beeldspecificatie was zelfs zo populair dat het nu een standaard is die bekend staat als de
‫OCI-beeldstandaard.
‫U ziet dus een reeks instructies en elk Docker-bestand heeft een van nodig om mee te beginnen.
‫We kunnen uitgaan van het beeld van iemand anders.
‫We kunnen veel afbeeldingen hebben van, veel van.
‫Dus we zullen later op al die complexiteit ingaan.
‫Maar we beginnen hier met een python en werken naar beneden.
‫In feite beginnen we met deze als lagen.
‫Elk van deze commando's in het Docker-bestand wordt soms een strofe met hoofdletters genoemd, inclusief de from
‫en dan de run en werken hun weg naar beneden omdat het ze van boven naar
‫beneden verwerkt en lagen creëert die als tarballs over servers worden verplaatst.
‫En binnen die lagen bevinden zich bestanden, mappen en bestandspermissies en soms metadata waar we later op in zullen
‫gaan.
‫Wanneer ik begin met het bouwen van deze afbeelding, zal deze die eerste regel starten en de Python-afbeelding van Docker Hub zoeken of waar ik hem
‫ook heb verteld om de afbeelding vandaan te halen.
‫En dat omvat alleen Python, zijn binaire bestanden en zijn bibliotheken.
‫Het bevat geen hoststuurprogramma's of de Linux-kernel of iets anders dan wat Python nodig heeft om te draaien.
‫Als Python open SSL nodig heeft, dan is dat opgenomen in die laag van de afbeelding.
‫Dan kunnen we doorgaan naar de volgende regel van het Docker-bestand.
‫Dat is een PIP-opdracht voor een Python-afhankelijkheidsinstallatieprogramma en het installeert flask.
‫Dus dat zal een nieuwe laag starten die kolf toevoegt, net zoals je zou doen met een normale pip install-opdracht.
‫Wat er in feite op de achtergrond gebeurt, is het uitvoeren van snelle kleine containers voor elk van deze
‫lagen, het uitvoeren van de opdrachten of doen wat je moet doen binnen die lagen, en
‫ze vervolgens opslaan als hun eigen afzonderlijke locatie op de Linux-host die dit bouwt.
‫Dus we stapelen hier lagen op en dan gaan we naar de volgende regel, het kopieercommando, het werk.
‫Er is alleen een wijziging in de metadata.
‫Het verandert alleen locaties in het bestandssysteem, geen probleem.
‫De opdracht copy kopieert onze broncode van de host waarop we bouwen naar zijn eigen laag die op de andere
‫is gestapeld.
‫Deze vormen samen een afbeelding met behulp van de opdracht docker build.
‫Dit is een van die dingen over Docker die zo gebruiksvriendelijk werden, omdat we alleen deze eenvoudige
‫Docker-buildopdracht nodig hadden om een heleboel complexe dingen die in het Docker-bestand gebeuren te verwerken en er één afbeelding van
‫te maken.
‫Dat is alleen onze applicatie en alleen de afhankelijkheden die het nodig heeft en niets anders.
‫Dat is het eerste deel van het bouwschip dat door Docker wordt gebouwd.
‫Laten we het vervolgens hebben over het register.
‫Het Docker-register is voor de distributie van toepassingen.
‫Elk applicatieverpakkingssysteem heeft een manier om die pakketten rond te krijgen en het Docker-register is nu
‫niet anders.
‫Het staat gewoon bekend als de OCI-distributiespecificatie of OCI-registerspecificatie.
‫Het is dus weer een standaard in de hele branche voor het verplaatsen van containerafbeeldingen.
‫En het is overal.
‫Elke wolk heeft er een.
‫Docker-hub is de standaard en waarschijnlijk de meest populaire.
‫GitHub heeft één Bitbucket GitLab.
‫Ze hebben allemaal hun eigen beeldregisters en u kunt er zelf een maken.
‫Er zijn waarschijnlijk minstens een dozijn projecten met gratis, open source en betaalde software waarmee u
‫uw Docker-afbeeldingen erin kunt opslaan.
‫Dus laten we eens kijken hoe dat werkt.
‫Ten eerste hebben we ons beeld dat we zojuist hebben gebouwd, en dat beeld heeft een unieke sha-hash die al die lagen samen
‫identificeert op een manier die we kunnen garanderen dat als we naar de hash op twee verschillende systemen kijken, we
‫er zeker van kunnen zijn dat het exact dezelfde bestanden, exact dezelfde metadata die we zojuist hebben gebouwd.
‫Die beeldlagen gaan samen en verspreiden zich.
‫We kunnen iets als Docker Push gebruiken om die afbeeldingslagen te nemen en ze naar een register te pushen.
‫Je kunt een van de vele registers gebruiken, zoals ik al zei, maar als het daar eenmaal is,
‫kun je naar een andere machine gaan en een Docker-pull doen, die een identieke kopie van die afbeelding naar die machine haalt, net zoals we het
‫hadden gebouwd op de eerste automaat.
‫En dit is een van de kernprincipes van Docker, is dat we in staat zijn om de
‫software die we hebben gemaakt op één machine met al zijn afhankelijkheden te nemen en het op precies dezelfde manier uit te voeren
‫op een ander systeem dat compleet verschillende distributies van Linux kan zijn of Windows.
‫Als je Linux gebruikt en je bouwt een Linux-image die op Linux moet draaien omdat het Linux-binaries draait.
‫Als je het op CentOS had gebouwd en het op een Bonita draaide, zou het exact dezelfde applicatie en afhankelijkheden
‫zijn, ongeacht die distributie.
‫Ten slotte komen we bij de Docker-container zelf.
‫Zodra we al die stappen hebben uitgevoerd om de afbeelding te bouwen, op een locatie te plaatsen, kunnen we
‫deze openen vanaf onze servers en vervolgens downloaden naar onze servers.
‫We kunnen het uitvoeren.
‫Laten we ons voorstellen dat we een server hebben waarop Linux draait.
‫Het kan zijn dat er Windows op draait, maar in dit geval zullen we ons alleen concentreren op Linux.
‫Het zal Docker op de achtergrond laten draaien die bekend staat als de Docker-engine.
‫En de engine op deze ene machine orkestreert of beheert alle verschillende dingen die moeten
‫gebeuren om afbeeldingen te downloaden, controleert of ze precies het ding zijn dat moest worden gedownload en
‫voert ze uiteindelijk uit.
‫Dan krijgen we de afbeelding die we zojuist hebben gedownload met een Docker-peiling en dan gaan we een opdracht uitvoeren.
‫Het is niet echt belangrijk dat je de commando's nog leert, maar het is een Docker run-commando.
‫Dit is het run-gedeelte van build ship run.
‫En in dit geval voeren we die Python-app uit in zijn eigen container.
‫Die container staat bekend als een naamruimte.
‫Dat is die Linux-functie die voorkomt dat de toepassing die in deze container draait, de rest van
‫het besturingssysteem ziet.
‫Het krijgt zijn eigen lege bestandssysteem en het bevat alleen de bestanden die in die afbeelding stonden die we zojuist hebben
‫gebouwd.
‫Het krijgt zijn eigen IP-adres en zijn eigen virtuele nic en zijn eigen proceslijst en ziet er in feite uit
‫als zijn eigen systeem daarbinnen.
‫Als we dan dat Docker-run-commando opnieuw uitvoeren met onze afbeeldingsnaam of afbeeldingshash, dan krijgen we een
‫identieke container naast elkaar.
‫Nu zijn deze twee processen van elkaar geïsoleerd.
‫Dus de Python-app, een container één kan de Python-app en container twee niet zien.
‫En als u een bestand in container verandert in container één, ziet u dat bestand standaard niet.
‫Als we een tweede server met een tweede exemplaar van de Docker-engine zouden toevoegen en hetzelfde zouden doen, zouden we een
‫zeer beschikbare configuratie met onze applicatie kunnen hebben, die vaak wordt uitgevoerd voor redundantie of betere prestaties of wat
‫onze reden ook is om meer te draaien dan een van hen.
‫Ze zullen identiek zijn vanuit het oogpunt van het bestandssysteem, de machtigingen en de metadata.
‫Er is nog veel meer dat we over dit soort dingen kunnen leren, daarom is de cursus die ik heb
‫nu zo lang.
‫Maar dit zijn nog steeds de drie dingen die niet zijn veranderd na Docker.
‫Ik heb ze eerst geconceptualiseerd.
‫Het idee van het bouwen van een schip is een van de kernprincipes van het roer van containers en Kubernetes.
‫Je noemt het project in het cloud-native ecosysteem en het gaat er waarschijnlijk van uit dat je
‫dit typische soort workflow hebt om je apps uit de handen van je ontwikkelaars te krijgen in de testsystemen en
‫uiteindelijk in productieservers.
‫Het zijn dezelfde drie stappen, dus hopelijk begint het een beetje door te dringen dat je begrijpt waarom dit
‫de drie belangrijkste componenten zijn.
‫Zelfs vandaag, vele, vele jaren nadat dit alles is uitgevonden, laten we eens kijken wat de toekomst biedt.