Container Images laden: Docker Hub Rate Limits im Griff behalten
Den Download von Container Images bei Docker Hub beschränken die Pull Rate Limits. Diese sollten verschärft werden – es gibt aber geeignete Abhilfe.
(Bild: erstellt mit Dall-E durch iX)
- Nicholas Dille
Das Unternehmen Docker hatte kürzlich angekündigt, die Rate Limits für das Herunterladen (Pull) von Container Images von Docker Hub zu verschärfen. Diese Änderung sollte für bestimmte Kundenkonten sowie nicht authentifizierte Benutzer gelten und zum 01.04.2025 aktiv werden. Docker rechtfertigte die Maßnahme damit, den Betrieb von Docker Hub rentabel gestalten zu müssen.
Das Anliegen des Unternehmens, kostendeckend arbeiten zu müssen, ist nachvollziehbar. Andererseits haben Ankündigungen dieser Art weltweite Auswirkungen. Durch die weite Verbreitung von Docker Hub sind unzählige Entwicklerinnen und Entwickler auf der ganzen Welt von den Pull Rate Limits auf der Plattform betroffen. Daher ist es eine gute Nachricht, dass die angekündigte Verschärfung der Rate Limits im letzten Moment zurückgenommen wurde und die alten Konditionen weiterhin gelten. Trotzdem lohnt es sich, die verfügbaren Optionen zu prüfen, um auf zukünftige Veränderungen an dem Rate Limit vorbereitet zu sein, und vielleicht auch generell sparsamer mit den Downloads von Container Images umzugehen.
Videos by heise
Unnötige Downloads von Container Images vermeiden
Es gibt verschiedene Optionen, um diese Beschränkungen zu umgehen. Der Use Case und die Umgebung bestimmen, wie aufwendig eine geeignete Lösung ausfällt. Grundsätzlich sollten folgende Situationen betrachtet werden, um die passende Vorgehensweise auszuwählen: Abhängig von der Arbeitsweise und den Aufgaben können Developer auf ihrem Arbeitsgerät von den Pull Rate Limits betroffen sein. Starten sie Build-Prozesse lokal, addieren sich die Container Image Pulls schnell auf, sodass die Arbeit durch die Pull Rate Limits beeinträchtigt wird. Sobald Änderungen durch zentrale CI/CD-Pipelines überprüft werden, fallen in der Kerninfrastruktur Container Image Pulls an, die durch das Erreichen der Limits zu nervigen Abbrüchen führen. Darüber hinaus greifen allerdings auch zentrale Infrastruktur wie Kubernetes-Cluster oder einzelne Docker-Hosts auf Docker Hub zu und können von den Pull Limits betroffen sein.
In der Folge kann es dazu kommen, dass Entwicklerinnen und Entwickler ausgebremst werden und dass zentrale Dienste nicht deployt und aktualisiert werden können. Besonders schmerzhaft sind die Auswirkungen, wenn kein Budget für höhere Rate Limits vorhanden ist – wie es häufig bei Open-Source-Projekten der Fall ist.
Was Entwicklerinnen und Entwickler tun können
In der Regel verwenden Developer kein Docker-Konto und laden Container Images daher anonym herunter, ohne sich als Benutzer zu authentifizieren. Dabei wird das Rate Limit auf der Basis der IPv4-Adresse berechnet. In Unternehmen ist das Rate Limit schnell erreicht, weil der Internetzugang von vielen Entwicklerinnen und Entwicklern gleichzeitig verwendet wird und daher eine einzelne IPv4-Adresse als Quelle zum Einsatz kommt. Für Privatpersonen ist es der einfachste Weg, ein kostenloses Konto anzulegen. Dadurch erhöht sich die Anzahl der zulässigen Container Image Pulls auf 100 pro Stunde und die Arbeit mit Container Images sollte meist ohne Unterbrechungen möglich sein.
Unternehmen jeder Größe können die Pull Limits durch kostenpflichtige Abo-Pläne aufheben. Allerdings verursacht die Pflege von Docker-Konten pro Mitarbeiter Aufwand im Lizenzmanagement, in der IT und auch bei den Entwicklern. Jeder betroffene Mitarbeiter muss ein persönliches Konto anlegen, das anschließend einem Team- oder Business-Plan hinzugefügt werden muss. Lediglich im Business-Plan lässt sich diese Pflege durch den Einsatz von Single Sign-on vermeiden.
Beim Einsatz von Docker Desktop könnten bereits die notwendigen Pläne vorhanden sein. Da Docker Desktop keine Lizenzkontrolle durchführt, ist ein Docker-Konto aufseiten des Entwicklers nicht zwingend erforderlich. Es ist aber gegebenenfalls notwendig, die Konten am Arbeitsplatz der Entwickler einzurichten.
CI/CD-Jobs und zentrale Infrastruktur
Sind CI/CD-Jobs oder zentrale Infrastruktur wie Kubernetes-Cluster von den Pull Limits fĂĽr Container Images betroffen, stehen die folgenden Optionen zur VerfĂĽgung, um Abhilfe zu schaffen. In jedem Fall sind Anpassungen an der Infrastruktur notwendig.
Grundsätzlich erfordern Änderungen an der zentralen Infrastruktur Zeit und müssen innerhalb der Organisation kommuniziert werden. Die Änderungen sind zu planen, zu testen und geordnet auszurollen. Gleichzeitig ist die Kommunikation mit den betroffenen Benutzergruppen unerlässlich, damit die neuen Möglichkeiten bekannt sind und sich notwendige Anpassungen rechtzeitig durchführen lassen.
Option 1: Nutzung öffentlicher Spiegel von Docker Hub
Es gibt einige wenige Anbieter, die einen öffentlichen Spiegel (Mirror) von Docker Hub betreiben und kostenlos zur Verfügung stellen, darunter etwa Amazon Elastic Container Registry (ECR) Public inklusive Suche oder Google Container Registry (GCR).
Obwohl das zunächst nach einer einfachen Abhilfe klingt, bleibt das Risiko hoch, dass zu einem späteren Zeitpunkt ebenfalls Rate Limits eingeführt oder die Fair-Use-Richtlinien überschritten werden.
Option 2: Spiegeln einzelner Images
Betreibt ein Unternehmen bereits eine private Container Registry, lassen sich die benötigten, offiziellen Container Images darin spiegeln. In diesem Fall ist besondere Sorgfalt notwendig, um neue Image Tags sowie die Aktualisierungen bestehender Image Tags zu erkennen und Kopien in der privaten Container Registry anzulegen. Ein hilfreiches Werkzeug dafür ist regctl image copy, das den umständlichen Download und Upload mit docker save und docker load vermeidet.
Der Nachteil an diesem Vorgehen liegt darin, dass die gespiegelten Container Images regelmäßig auf Aktualisierungen geprüft werden müssen. Das setzt die Pflege einer Liste der gespiegelten Container Images voraus. Neue Anforderungen der Entwickler und Entwicklerinnen benötigen einen manuellen Eingriff. Außerdem werden regelmäßig Anfragen an Docker Hub gesendet, um die Aktualität zu prüfen. Diese Anfragen zählen zwar nicht zu durch Rate Limits begrenzten Pulls, sie lassen sich aber dennoch vermeiden, wie die dem Spiegeln von Container Images deutlich überlegene dritte Option zeigt:
Option 3: Privater Pull Through-Proxy
Die komfortabelste Lösung stellt der Pull-Through Proxy dar. Dieser wird als sogenannter Registry Mirror im Docker Daemon konfiguriert und bei jedem Zugriff anstelle von Docker Hub kontaktiert. Dadurch erfolgt die Nutzung für die Entwickler völlig transparent. Jedes heruntergeladene Container Image wird zwischengespeichert und lässt sich an viele Benutzer im Unternehmen ausliefern, ohne dass jedes Mal ein weiterer Download von Docker Hub erfolgen muss. Der Proxy sollte ein Access Token eines kostenpflichtigen Kontos verwenden, um die Pull Rate Limits aufzuheben.
Der Pull-Through Proxy kann sowohl für CI/CD-Jobs und zentrale Infrastruktur als auch auf den Arbeitsgeräten der Developer zum Einsatz kommen.
Einige Beispiele sind der GitLab Dependency Proxy oder Jfrog Remote Docker Repositories. Abhängig vom eingesetzten Tool lässt sich das Verhalten anpassen. So lässt sich etwa die Vorhaltezeit anpassen oder wie lange nach einer Aktualisierung darauf verzichtet werden soll, erneut mit Docker Hub Kontakt aufzunehmen.
Sonderfall: Open-Source-Projekte
Die Image Pull Rate Limits stellen eine besondere Herausforderung für Open-Source-Projekte dar. Oft steht kein Sponsor zur Verfügung, um für Hosting-Kosten aufzukommen. Es existieren zwar mehrere Alternativen zu Docker Hub, allerdings wird oft nur eine begrenzte Menge an Speicherplatz für Container Images angeboten. Daher empfiehlt es sich, eine Bewerbung an eines der Open-Source-Programme zu senden, darunter das Docker-sponsored Open Source Program oder GitLab for Open Source. In der Regel ist bei diesen Programmen eine jährliche Verlängerung der Unterstützung notwendig – das macht die Zukunft etwas ungewiss.
Besser vorbereitet sein
Auch wenn die Verschärfung der Rate Limits für Docker Hub ausgesetzt wurde und weiterhin die alten Tarife gelten, sollten sich Unternehmen und Entwicklungsteams mit der Fragestellung grundsätzlich beschäftigen und eine für die jeweilige Situation passende Lösung auswählen. Es ist stets von Vorteil, vorbereitet zu sein und notwendig werdende Umstellungen dann ohne Zeitdruck in Angriff nehmen zu können.
(map)
