Beste Europese alternatieven voor Docker Hub

Waarom mensen Docker Hub verlaten

Docker Hub is zelden een keuze die iemand bewust heeft gemaakt. Daar staat de basisimage, dus daar gaat elke build naartoe, en dat blijft zo totdat een pipeline begint te falen met een melding over een rate limit.

Dat is de gebruikelijke aanleiding. Anonieme pulls zijn begrensd tot 100 per zes uur, geteld per IPv4-adres of IPv6-/64-subnet, en een gratis Docker Personal-account krijgt 200 per zes uur.

Een build farm achter één NAT-gateway is voor de teller één adres, dus een tiental ontwikkelaars en een drukke CI-wachtrij delen één teller. Betaalde abonnementen worden omschreven als onbeperkt, onder voorbehoud van redelijk gebruik, en de documentatie waarschuwt dat te veel transfer, pullfrequentie of opslag kan leiden tot throttling of extra kosten: dus onbeperkt, maar zonder getal.

De vraag naar de rechtsmacht ligt eronder en is hier ongewoon duidelijk. Docker, Inc. opereert vanuit Palo Alto, de privacyverklaring stelt dat Docker en zijn diensten voornamelijk in de Verenigde Staten zijn gevestigd en worden aangeboden, en doorgiften buiten de EER verlopen via het EU-U.S. Data Privacy Framework en standaardcontractbepalingen. Er is geen Europese regio van Docker Hub om te kiezen, dus anders dan bij een forge is dit geen kwestie van configuratie.

• De teller telt je adres, niet je team Rate limits op anonieme pulls gelden per IPv4-adres of IPv6-/64-subnet, precies de verkeerde eenheid voor moderne infrastructuur. Elke runner in een Kubernetes-cluster achter één uitgaand adres put uit dezelfde 100 pulls per zes uur, en een multi-architectuur-image telt één keer per architectuur die je ophaalt. Inloggen helpt, betalen helpt meer, maar geen van beide verandert het feit dat de betrouwbaarheid van je build afhangt van de teller van iemand anders.
• Docker spreekt zichzelf zelfs tegen over het gratis abonnement De documentatie zegt dat een gratis Docker Personal-account 200 pulls per zes uur krijgt; de prijstabel voor hetzelfde abonnement zegt 100 pulls per uur. Beide pagina's zijn actueel en beide komen van Docker. Als je een build-pipeline dimensioneert, is het verschil tussen die twee getallen het verschil tussen een groene en een rode pipeline, en de oplossing is niet het gunstigste getal kiezen, maar stoppen met afhankelijk zijn van dat getal.
• Er is geen Europese Docker Hub om in te schakelen Verschillende Amerikaanse leveranciers beantwoorden de soevereiniteitsvraag met een regiokeuze. Docker niet: de privacyverklaring plaatst de diensten in de Verenigde Staten en leunt voor doorgiften op het Data Privacy Framework en standaardcontractbepalingen, en er is geen dataresidentie-add-on te kopen. Voor een gereguleerde koper vereenvoudigt dat de keuze, want de enige manier om images in Europa te houden, is ze elders onderbrengen.
• “Onbeperkt, redelijk gebruik” is een beleid, geen quotum Betaalde abonnementen schaffen de pulltelling af en vervangen die door een oordeel. De gebruiksdocumentatie behoudt het recht om de snelheid te beperken of kosten in rekening te brengen voor overmatige datatransfer, pullfrequentie of opslag, zonder te publiceren waar overmatig begint. Dat is verdedigbaar voor een gratis dienst die door betalende gebruikers wordt gefinancierd, maar het is een zwak fundament voor een releaseproces dat je contractueel om twee uur 's nachts moet kunnen draaien.

Wat je moet vervangen, niet alleen evenaren

Docker Hub doet drie dingen en die laten zich netjes van elkaar scheiden. Daardoor is deze migratie meestal makkelijker dan een forge-migratie, en wordt ze vaker slecht uitgevoerd.

Het eerste is het privéregister: je eigen images, door CI gepusht en door je servers gepulld. Dat verhuist in een middag naar elk van de onderstaande opties, omdat de registry-API een standaard is en het enige echte werk uit inloggegevens bestaat. Het tweede is publieke distributie: de images die je voor anderen publiceert, waarbij de waarde van Docker Hub het publiek is en het feit dat docker pull zonder configuratie werkt.

Het derde is het deel dat teams vergeten. Elk Dockerfile dat begint met een kale imagenaam, haalt na de migratie nog steeds van Docker Hub, dus je build hangt ervan af, wat je ook met je eigen images hebt gedaan. De oplossing is een pull-through cache of een spiegel van de upstream-images die je echt gebruikt, opgeslagen in het register dat je nu zelf beheert. Doe dat eerst, en de rate limit doet er binnen dezelfde week niet meer toe.

De alternatieven vergeleken

Hoe elk alternatief zich verhoudt tot Docker Hub

Wat er echt stukgaat als je overstapt

Het inventariseren is het werk. Imagenamen verstoppen zich in Dockerfiles, Compose-bestanden, Helm-waarden, Kubernetes-manifesten, Terraform, CI-configuratie en hier en daar een shellscript, en elk daarvan moet worden gevonden voordat de oude inloggegevens worden ingetrokken. Zoek eerst op de hostnaam van het register, en zoek daarna opnieuw op kale imagenamen, want die verwijzen nog steeds naar Docker Hub.

Digests en tags zullen je één keer bijten. Alles wat met een digest is vastgezet, moet na het kopiëren opnieuw worden vastgezet, want de digest volgt de inhoud en de tooling die hem controleert, trekt zich niets van je migratie aan. Kopieer met een tool die multi-architectuur-manifesten behoudt, in plaats van op één machine te pullen en te pushen, anders ontdekken je ARM-gebruikers het eerder dan jij.

En houd het oude account langer in leven dan nodig voelt. Een registermigratie wordt ontdekt door wat er per kwartaal draait: een oefening voor disaster recovery, het airgapped installatieprogramma van een klant, een geplande herbouw van een basisimage. Laat de Docker Hub-repositories staan, alleen-lezen, tot één volledige cyclus daarvan voorbij is.

Zal het verplaatsen van onze images de storingen door rate limits echt stoppen?

Alleen gedeeltelijk, en hier lopen de meeste migraties vast. Je eigen images elders pushen haalt je images uit de teller van Docker Hub, maar elke FROM-regel die een upstream-image noemt, haalt nog steeds van Docker Hub, en dat zijn de pulls die een CI-omgeving het vaakst doet.

De volledige oplossing heeft twee helften: je eigen register voor je artefacten, en een cache of spiegel voor de upstream-images waar je van afhangt. Harbor, wat OVHcloud als beheerde dienst draait, heeft proxy-caching van externe registers standaard ingebouwd. Met een gewoon register is het equivalent een geplande taak die de handvol basisimages die je echt gebruikt kopieert naar je eigen namespace, plus een regel dat Dockerfiles naar die kopieën verwijzen.

Teams die alleen de eerste helft doen, melden dat de pipeline nog steeds faalt, alleen minder vaak, en concluderen dat de verhuizing zinloos was. Het was een halve verhuizing.

Is een register binnen ons git-platform genoeg?

Voor de meeste teams wel, en het is de goedkoopste optie om in te voeren, omdat er niets nieuws is om te kopen of waartegen je je moet authenticeren. GitLab levert een containerregister op elk niveau, op GitLab.com, op zelf beheerde installaties en op Dedicated, dat zowel Docker V2 als OCI spreekt, en de CI-job heeft al een token waarmee hij ernaartoe kan pushen.

Het argument ertegen is concentratie. Je broncode, je pipelines en je artefacten delen dan één platform, één storing en één compromittering, en een register dat voor een forge is gedimensioneerd, is niet gedimensioneerd voor een monorepo die dagelijks honderden image-tags produceert.

De splitsing waar de meeste organisaties op uitkomen, is onopvallend en verstandig: images uit CI gaan naar het forge-register, productie haalt van een apart register in dezelfde regio als het cluster, en de pipeline houdt de twee synchroon.

Maakt het uit in welk Europees land het register staat?

Minder dan in welke regio je cluster staat, en dat verrast mensen die met een soevereiniteitsvraag komen. Een register dat tweehonderd milliseconden en één uitgaande kostenpost verwijderd is van de machines die ervan pullen, is een traag, duur register, ongeacht de vlag erop.

Scaleway houdt elk datacenter binnen de EU, Parijs, Amsterdam en Warschau. Dat maakt het het eenvoudige antwoord wanneer de workload er al draait, omdat de pull de regio nooit verlaat. OVHcloud heeft meer dan dertig datacenters en beschikt over SecNumCloud van het Franse agentschap ANSSI, de kwalificatie die voorkomt in aanbestedingen van de publieke sector waar de AVG alleen niet voldoende is.

Kies degene waarin je compute al staat. Controleer daarna de voorwaarden voor uitgaand verkeer, want daar wordt een register stilletjes duur.

Wat gebeurt er met de images die we voor anderen publiceren?

Ze verliezen hun vanzelfsprekende plek. Een image op Docker Hub wordt op naam gehaald zonder configuratie, en dat gemak is de hele reden om daar te publiceren; elk alternatief vereist dat gebruikers eerst een registerhostnaam intypen.

Voor een gratis softwareproject is publiceren naast de broncode een redelijk antwoord: het pakketregister van Codeberg accepteert containerimages, dus de release en de code die hem heeft voortgebracht staan op één plek onder één licentie. Voor een commerciële leverancier die naar klanten distribueert, houd je de aanwezigheid op Docker Hub voor de distributie en verplaats je de interne pipeline elders. Dat zijn verschillende problemen, en alleen het ene is van jou om op te lossen.

Kondig hoe dan ook de nieuwe locatie aan in de repository en laat de oude tags staan. Niets irriteert downstreamgebruikers meer dan een image die updates stopt te krijgen zonder te zeggen waar hij naartoe is.

Welke kies je

Als het probleem falende builds en een onvoorspelbare teller is, is OVHcloud de eerste optie om naar te kijken, omdat Harbor de upstream-images die je pipelines ophalen kan cachen, en het verkeer valt binnen het abonnement in plaats van op de factuur.

Als je workload al op Europese infrastructuur draait, zet het register in dezelfde regio als de compute: Scaleway houdt alles in Parijs, Amsterdam of Warschau, en een lokale pull is zowel het goedkope als het snelle antwoord.

Als de images puur het resultaat zijn van je pipeline en het bedrijf nooit verlaten, is het register van GitLab het minste werk van alles hier. Alleen een zelf beheerde of Dedicated-instantie verandert de rechtsmacht, wat de gehoste versie niet doet.

Als het project open source is, host Codeberg de image gratis naast de code, onder regels waarover de leden hebben gestemd. En welke je ook kiest, spiegel de upstream-basisimages waar je van afhangt, anders heb je je artefacten verplaatst en de afhankelijkheid behouden die je builds liet mislukken.