‫Vereisten voor deze lezing zijn dat je begrijpt wat een afbeelding is en dat
‫je een beetje met containers hebt gewerkt.
‫In deze lezing maken we een korte rondleiding door Docker Hub
‫en leren we enkele basisfuncties kennen. Daarna bespreken we het verschil tussen een officiële afbeelding en misschien andere, even
‫goede afbeeldingen, en hoe je het verschil kunt zien tussen een goede afbeelding en een slechte afbeelding.
‫Dan zal ik een beetje laten zien hoe je afbeeldingen downloadt en hoe je de verschillende tags kunt zien
‫die ze zullen gebruiken en het verschil tussen een Alpine-afbeelding en andere afbeeldingsopties.
‫U had zich moeten aanmelden bij hub. havenarbeider. com. Wanneer u zich aanmeldt, is
‫uw standaard startpagina uw dashboard, dat u al uw repositories laat zien, openbaar en privé.
‫Je zult er nog geen hebben, maar je kunt zien dat ik er hier een paar heb.
‫Ze zijn allemaal openbaar.
‫Ik heb er een privé. Laten we voor nu naar de top gaan en nginx zoeken. Wat we terugkrijgen zijn de zoekresultaten van Docker Hub en
‫je zult zien dat het er veel zijn. Ik kon scrollen voor pagina's en pagina's.
‫Een van de uitdagingen is dat er 15.000 afbeeldingen van Nginx zijn.
‫Dat is veel.
‫Dus ik gebruik er eigenlijk maar een of twee.
‫De officiële
‫hier, die je bovenaan ziet, heeft meer dan 10 miljoen pulls.
‫Er zijn verschillende kenmerken om erachter te komen wat de juiste afbeelding is.
‫Net als ik ga je de afbeeldingen voor je workflow gebruiken die gerelateerd zijn aan wat je doet, en
‫je gaat wennen aan specifieke. Je gaat van specifieke houden.
‫Meestal beginnen we altijd met de ambtenaar.
‫De ambtenaar zal de enige zijn met het woord 'ambtenaar' er echt onder.
‫Het zal ook de enige zijn waarvan de naam geen schuine streep naar voren bevat.
‫Wanneer jij en ik afbeeldingen maken op Docker Hub, moeten we ze maken met onze accountnaam
‫ervoor.
‫Dus als je naar al deze andere kijkt, zijn dit accountnamen slash image repository-namen.
‫Het kan eigenlijk een organisatie-slash nginx zijn of iets dergelijks.
‫Maar de enigen die alleen de naam van de repo mogen hebben, worden als officieel beschouwd. Officiële afbeeldingen zijn afbeeldingen
‫die Docker, Inc. heeft eigenlijk een team van mensen die voor hen
‫zorgen, ervoor zorgen dat ze kwaliteitsdocumentatie hebben, dat ze goed zijn getest en dat ze goed zijn
‫samengesteld met Dockerfiles die de regels voor best practices naleven. Ze werken meestal met het officiële team van die software die
‫het daadwerkelijk maakt om ervoor te zorgen dat het alle dingen doet die het zou moeten doen.
‫Dus ik ga op deze klikken.
‫Laten we een paar dingen over officiële repositories bekijken.
‫Zoals ik al eerder zei, je zult in het begin vaak ambtenaren gebruiken en uiteindelijk zul je misschien merken dat je het
‫een beetje wilt veranderen of er een paar dingen aan wilt toevoegen en je zult je eigen afbeeldingen maken.
‫Officiële afbeeldingen zijn een geweldige manier om te beginnen.
‫Een van de beste dingen van officiële afbeeldingen is hun documentatie.
‫Ze zijn altijd heel goed in het
‫documenteren van hoe ze ze kunnen laten werken, welke opties er zijn, welke omgevingsvariabelen, wat de standaardpoort is, enzovoort.
‫Dus back-up bovenaan, je zult deze versies opmerken. Versies zijn een veelvoorkomend kenmerk van officiële repositories.
‫Je hoeft niet in elke afbeelding versies te hebben, maar officiële versies wel.
‫Omdat de meeste open-sourcesoftware er altijd minstens een paar officiële versies in het wild zijn
‫die officieel worden onderhouden en ondersteund.
‫Dat is wat we hier hebben. We hebben de hoofdlijn 1. 11 voor Nginx en dan hebben we wat wordt beschouwd als
‫de stabiele tak van Nginx, namelijk 1. 10. We kunnen de kleine
‫naam hier zien, zegt stabiele jessie Dockerfile.
‫Oke.
‫Dus laten we dit opsplitsen.
‫1. 11. 9, hoofdlijn, 1, 1. 11 en laatste.
‫Dat zijn allemaal tags.
‫Als we het over afbeeldingen hebben, hebben afbeeldingen niet per se een naam. Afbeeldingen zijn getagd. Een versie van een afbeelding kan in
‫feite meer dan één tag hebben.
‫We gaan hier wat later op in wanneer we onze eigen afbeeldingen gaan maken
‫en we kunnen spelen met tagging.
‫Maar voor nu, als ik die specifieke afbeelding echt wilde downloaden, en je herinnert je eerder dat we het eigenlijk
‫al hebben gedownload,
‫dus als ik een docker-afbeelding ls doe, zie je de drie afbeeldingen waarmee we tot nu toe hebben gewerkt mijn automaat.
‫Je ziet de tag met de tekst 'laatste'. Nu is de nieuwste een speciale tag.
‫Het garandeert niet noodzakelijkerwijs dat het altijd de laatste commit in de repository is.
‫Wat het meestal betekent, is dat u de nieuwste versie van dit product krijgt. In de officiële repositories is het zeer goed gedefinieerd en consistent,
‫dus als
‫het je nu niet echt uitmaakt welke versie je precies wilde, je gewoon de meest
‫actuele wilde, dan zou je gewoon kunnen zeggen docker pull nginx. Het zou de
‫nieuwste downloaden. Je zult merken dat het al wist dat ik het had, het controleerde
‫de SHA om er zeker van te zijn dat het overeenkwam met die van Docker Hub
‫en zei: "Hé, ik heb deze afbeelding al, hij is up-to-date. " Wat als ik docker-afbeeldingsversie 1 wilde downloaden. 11. 9?
‫Het gaat kijken wat het moet doen om die afbeelding te downloaden en het
‫blijkt dat het niets hoeft te doen omdat het exact dezelfde versie is.
‫Dat is wat deze regel hier betekent.
‫Ik kan verwijzen naar deze 'main, nieuwste' versie hier door een van deze tags.
‫De reden is dat ik gewoon bij de nieuwste versie van 1 wilde blijven. 0, wat dat ook mag zijn voor Nginx, ik
‫zou gewoon een 1 kunnen specificeren. Als ik specifieker wilde zijn bij het downloaden
‫van afbeeldingen en ik wilde de nieuwste versie van 1. 11, dan kan ik gewoon 1 typen. 11 zoals deze en laat
‫de . 9 en het zou die downloaden.
‫Maar in mijn geval heb ik eigenlijk de meest specifieke van alle 1 gespecificeerd. 11. 9 die de puntvrijgave laat zien
‫en dat was gewoon om ervoor te zorgen dat ik de exacte versie kreeg die ik wilde.
‫Dus in uw software is een best practice wanneer u naar productie gaat en u daadwerkelijk software test
‫die u voor anderen gaat
‫gebruiken, u altijd de exacte versie wilt specificeren.
‫Het komt zelden voor dat u echt wilt dat uw software automatisch wordt bijgewerkt.
‫Meestal wil je dat proces besturen met een andere DevOps-tool.
‫Maar als je iets lokaal aan het ontwikkelen of testen bent, is het met officiële afbeeldingen super eenvoudig om gewoon de naam in te
‫typen en er gewoon van uit te gaan dat je het nieuwste krijgt.
‫Dus je zult merken dat er hier andere zijn.
‫Er is 1. 11. 9-alpine en deze hebben allemaal zeer vergelijkbare namen als de eerste, maar
‫ze hebben allemaal het woord alpine in zich.
‫We gaan later in op basisafbeeldingen en distributies, maar voorlopig is Alpine eigenlijk een distributie van Linux
‫die heel erg klein is.
‫Het is eigenlijk minder dan 5 MB groot geloof ik. Deze versie betekent in feite dat het afkomstig is van
‫een basisimage van Alpine, waardoor het erg klein en licht blijft, terwijl de standaardversie of de nieuwste image eigenlijk afkomstig is
‫van jessie, wat een Debian-distributie is. Het is een beetje groter in omvang, waarschijnlijk
‫iets meer dan 100 MB.
‫Sterker nog, we kunnen hierheen gaan en kijken.
‫Dus nginx 182 MB hier.
‫Als ik die exacte versie van de Alpine wil downloaden, kan ik zeggen 1. 11. 9-apline en doe dan docker
‫image ls en je zult zien dat de alpine versie eigenlijk maar
‫54MB is en de laatste versie 182MB.
‫Je zult ook merken dat de drie versies die ik heb
‫gedownload allemaal dezelfde afbeeldings-ID hebben, omdat de afbeeldings-ID is gebaseerd op de cryptografische SHA van elke afbeelding in Docker Hub.
‫Dit zijn dus niet echt drie verschillende exemplaren van 128 MB afbeeldingen.
‫Het is eigenlijk een beetje bedrieglijk.
‫Het zijn eigenlijk maar drie tags met exact dezelfde afbeeldings-ID en het is in totaal maar 182 MB
‫en dit zijn slechts twee andere regels die dezelfde afbeeldings-ID tonen met verschillende bijbehorende tags.
‫Maar genoeg over tags en versies voor nu.
‫Laten we
‫nog een paar dingen bekijken in Docker Hub. Als ik terugga naar nginx in de zoekbalk en opnieuw naar nginx zoek, zul
‫je weer zien dat er veel andere opties zijn en deze kunnen door iedereen worden gemaakt.
‫Je kunt je eigen aangepaste Nginx-versie maken en omdat het open source-software is en gratis
‫te distribueren, kun je het hier weer plaatsen en aan het publiek aanbieden.
‫Dit lijkt erg op het model van GitHub, waar je open source-software kunt opslaan en je
‫de software van andere mensen kunt forken en ook kunt aanbieden.
‫Hetzelfde geldt hier.
‫U kunt de afbeeldingen van andere mensen gebruiken en downloaden, ze uw eigen maken en opnieuw uploaden.
‫Dus als ik ooit wil overwegen om geen officiële repository te gebruiken, zoek ik
‫meestal naar een aantal sterren en een aantal peilingen, omdat een populaire repository voor mij vertrouwen wekt.
‫Ik raad u altijd aan de software te downloaden en te inspecteren voordat u deze gebruikt. Kijk in hun Dockerfile en hopelijk
‫hebben ze een open source repository waar je precies kunt kijken hoe ze die
‫afbeelding hebben gemaakt.
‫Een goede indicatie is wanneer je dingen ziet die vijf miljoen trekken en 945 sterren hebben; er is duidelijk iets interessants
‫aan dit pakket en waarom zoveel mensen ervoor kiezen in plaats van de officiële
‫afbeelding te gebruiken.
‫Je kunt hier binnenkomen en hun repository bekijken.
‫Je kunt aan de rechterkant zien dat hij is gekoppeld aan zijn GitHub-repository waar de daadwerkelijke
‫open source-software is die deze afbeelding bouwt, zodat je hem kunt gaan inspecteren; en download mogelijk
‫de daadwerkelijke broncode buiten een afbeelding.
‫Maar hij heeft duidelijk iets gedaan met deze Nginx-afbeelding die hem beter maakt
‫dan de officiële standaard.
‫Nog een paar dingen. In de bovenste balk zie je Verkennen. Verkennen geeft je
‫gewoon een samenvatting van alle officiële afbeeldingen en je kunt er doorheen bladeren
‫en geloof me, er is veel. In de bronnen voor deze
‫sectie vindt u zelfs een link naar de daadwerkelijke lijst met officiële afbeeldingen en onder 'bibliotheek',
‫dit is waar alle officiële afbeeldingen en hun Docker-bestanden leven.
‫Je ziet dat er veel is. Kort samengevat: in deze lezing hebben we het gehad over Docker Hub
‫en hoe het lijkt op het zijn van de geschikte pakketbeheerder voor containers,
‫en vervolgens hoe je officiële afbeeldingen kunt herkennen en hoe je ze kunt gebruiken.
‫Toen heb ik je geholpen om erachter te komen hoe je een goed publiek imago kunt onderscheiden van misschien een minder goed imago.
‫Dan een paar tips over basisimages en hoe Alpine-images doorgaans kleiner zijn dan hun Debian-tegenhangers.
‫We gaan deze vaardigheden dus gebruiken in de rest van dit gedeelte.