‫Docker-register. We hebben eerder besproken hoe het een register kan zijn dat u
‫privé op uw netwerk opslaat.
‫Het maakt eigenlijk deel uit van de Docker/distributie GitHub-repo.
‫Als je op zoek bent gegaan naar Register, zodat je het weet, er is een oude versie van
‫Register in GitHub die legacy is. Dat zal het duidelijk zeggen. Het huidige V2-register dat we allemaal
‫gebruiken, is herschreven in Go en is te vinden in de distributiecoderepository, maar je zult het waarschijnlijk niet gebruiken vanaf
‫GitHub, je zult het waarschijnlijk gebruiken vanuit Docker Hub. Docker heeft een vooraf gebouwde officiële image voor het
‫register, dus het is net zo eenvoudig als het pull-register van Docker. Ik zou zeggen dat het zo'n beetje het defacto backend-register
‫is voor het privé opslaan van uw containers.
‫Het is vrij kaal.
‫Er is geen web-GUI.
‫Het is zeker niet zoals een Docker Hub of een andere service van derden. Out-of-the-box ondersteunt het wel certificaten
‫en basisverificatie, maar ze zijn niet standaard ingeschakeld en de verificatie is
‫eigenlijk alles of niets.
‫Het is geen RBAC of op rollen gebaseerd toegangsbeheer.
‫Het is meer een Apache htaccess waar, als je een gebruikersnaam en wachtwoord hebt waar je doorheen komt,
‫je lees-/schrijftoegang hebt tot alles.
‫Het is waarschijnlijk alleen nuttig in kleine teams zonder een soort tool er bovenop om het zakelijker
‫en schaalbaarder te maken.
‫Maar in de kern is het eigenlijk gewoon een web-API en een opslagsysteem om al deze grote afbeeldingen te verwerken waarmee we
‫te maken krijgen.
‫Het leuke is dat het eigenlijk wordt geleverd met veel ingebouwde opslagstuurprogramma's waarmee je de backend-opslag
‫ervan op S3 of Azure of Alibaba of Google Cloud kunt plaatsen. Het heeft zelfs een OpenStack Swift-stuurprogramma, maar
‫we gaan gewoon de lokale gebruiken die standaard is.
‫Kortom, dat betekent gewoon dat u het lokale bestandssysteem in de afbeelding of op uw host gebruikt met behulp van volumes.
‫Heel snel, voordat we het register gaan installeren, wil ik je aandacht vestigen op een paar van
‫de bronlinks in deze sectie die je moet bekijken.
‫De eerste is een basisconfiguratie met TLS, zodat u de onveilige registeroptie niet hoeft in te schakelen,
‫want TLS is natuurlijk een goede zaak.
‫De tweede is een referentieartikel van Docker rond een garbagecollection.
‫Het ding over een register is dat wanneer je het in de echte wereld begint te gebruiken, het echt veel
‫gegevens begint in te nemen en, vooral als je afbeeldingen keer op keer pusht, kan het echt schijfruimte
‫in beslag nemen.
‫Je moet dus een beetje aandacht besteden aan je beslissing over je opslagstuurprogramma en
‫ook aan
‫dit artikel over afvalinzameling dat zal proberen oude dingen op te ruimen en je opslag onder controle te houden.
‫Ten slotte is een echt coole optie de registerspiegel.
‫Als u voor productie implementeert en een van uw zorgen is dat u
‫voor veel van uw basisimages niet afhankelijk wilt zijn van de Hub, dan kunt u als functie in Register een proxymodus
‫inschakelen en vervolgens u vertelt uw Docker-daemons om de proxy te gebruiken en wat het zal doen, is dat het alle Hub-afbeeldingen
‫in dat register in de cache opslaat. Dat is best goed als je ervoor wilt zorgen dat
‫je je bandbreedte kunt optimaliseren voor het geval je misschien tientallen of honderden servers
‫hebt, je zeker niet de Ubuntu-afbeelding op elke afzonderlijke machine van de Hub wilt downloaden .
‫Rechts?
‫Je zou deze proxy dus veel dichter bij je metaal kunnen hebben, en dan zou het ook een failover bieden voor
‫het geval de Hub problemen zou hebben.
‫U kunt uw kopieën van de afbeeldingen nog steeds lokaal verkrijgen.