public-image-mirror: der Registry-Spiegel von DaoCloud im Detail
gcr . Ollama Ollama Docker Deepseek-R1 ollama DeepSeek Ollama [ ] Hergestellt mit contrib.rocks.
Auf einen Blick
- Was ist das?
- Ein Mirror-Dienst für gcr.io, ghcr.io, quay.io und weitere Container-Registries, der über ein einfaches Domain-Präfix arbeitet und sein Cache-Verhalten offen dokumentiert.
- Für wen ist es gedacht?
- public-image-mirror passt zu Nutzern in Netzwerkumgebungen mit langsamem Zugang zu Übersee-Registries, die mit dem Präfix m.daocloud.io schnell_IMAGES ziehen wollen; wer Kubernetes-Betrieb bis hin zu kubeadm, kind und containerd abwickelt, findet im README konkrete Konfigurationspfade, sollte aber die Empfehlungen zu Versions-Tags statt latest und zu Pull-Zeiten in der Nacht beachten.
- Darf ich es kommerziell nutzen?
- Ja. Apache-2.0 ist eine freizügige Lizenz: Sie dürfen darauf aufbauende Software nutzen, verändern und verkaufen, solange Sie die Urheberrechts- und Lizenzhinweise beibehalten.
- Wird es noch gepflegt?
- Ja. Die letzten Commits kamen vor 4 Tagen.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich Shell, laut der Sprachstatistik von GitHub.
Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 14. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.
TIEFGEHENDE OPEN-SOURCE-ANALYSE
Warum ein Spiegel für Container-Registries
Viele Container-Images liegen auf Registries in Übersee, etwa auf gcr.io, und der Download aus Netzen mit schlechter Anbindung ist langsam. Das Projekt DaoCloud/public-image-mirror bietet dafür einen Mirror-Dienst, der Registry-Namen entweder mit einer DaoCloud-Domain ergänzt oder ersetzt. Das README nennt drei Ziele: eine einfache, wirksame Namenszuordnung, das Hinzufügen neuer Paketquellen ohne Codeänderung sowie einen stabilen Betrieb, der die Quellen eng verfolgt und die Synchronisation täglich prüft.
Das Projekt versteht sich ausdrücklich nur als Spiegel der Quell-Registries, nicht als eigene Distribution. Die Metadaten weisen rund 14.900 Sterne und über 1.500 Forks aus, bei 8 offenen Issues. Die Lizenz ist Apache-2.0, die Sprachangabe Shell, und ein Datum des letzten Pushs ist in der Dokumentation nicht angegeben.
Hash-Treue und die Cache-Zeiten im Detail
Alle sha256-Digests bleiben laut README durch einen Lazy-Loading-Mechanismus mit der Quell-Registry identisch. Der zwischengespeicherte Inhalt wird 30 Tage vorgehalten, danach muss er neu synchronisiert werden. Manifeste liegen eine Stunde im Speichercache, weshalb ein aktualisierter Tag erst etwa eine Stunde später sichtbar wird.
Blobs werden nur eine Minute zwischengespeichert, und wenn ein Blob in dieser Minute die 30-Tage-Grenze erreicht und gelöscht wird, können Anfragen mit 404 antworten. Aus der Tag-Flüchtigkeit folgt eine praktische Empfehlung des README: Bilder bevorzugt mit @sha256: festlegen, dann mit eindeutigen Versions-Tags, und latest nur zuletzt verwenden, weil ein veränderlicher Tag alte Daten ausliefert, bis die Hintergrund-Synchronisation ihn nachzieht.
Präfix voranstellen statt Registry-Namen ersetzen
Der empfohlene Weg ist, dem vollständigen Image-Verweis das Präfix m.daocloud.io/ voranzustellen. Aus docker.io/library/busybox wird damit m.daocloud.io/docker.io/library/busybox, und der Schnellstart zeigt denselben Mechanismus mit docker run -d -P m.daocloud.io/docker.io/library/nginx.
Die Alternative ist die Ersetzung des Registry-Hosts durch eine eigene Subdomain, etwa docker.io/library/busybox zu docker.m.daocloud.io/library/busybox. Diese Ersetzungsregeln sind laut README manuell gepflegt; Wünsche für neue Regeln laufen als Issue. Das README warnt zudem davor, andere Quellen als docker.io in die Docker-Option registry-mirrors einzutragen, denn die Inhalte der einzelnen Quell-Registries unterscheiden sich.
Unterstützte Registries und Client-Konfiguration
Die Ersetzungstabelle listet elf Quellen auf: docker.elastic.co zu elastic.m.daocloud.io, docker.io zu docker.m.daocloud.io, dhi.io zu dhi.m.daocloud.io, gcr.io zu gcr.m.daocloud.io, ghcr.io zu ghcr.m.daocloud.io, k8s.gcr.io zu k8s-gcr.m.daocloud.io, registry.k8s.io zu k8s.m.daocloud.io, mcr.microsoft.com zu mcr.m.daocloud.io, nvcr.io zu nvcr.m.daocloud.io, quay.io zu quay.m.daocloud.io sowie registry.ollama.ai zu ollama.m.daocloud.io. Bei k8s.gcr.io vermerkt das README die Migration zu registry.k8s.io.
Für Docker zeigt das README den Eintrag https://docker.m.daocloud.io in der registry-mirrors-Liste der Datei /etc/docker/daemon.json. Für Podman landet die Konfiguration in /etc/containers/registries.conf oder im Rootless-Fall in ~/.config/containers/registries.conf, mit location docker.io und einem darunterliegenden mirror-Eintrag; anders als Docker erlaubt Podman Mirrors für jede Registry einzeln. Für containerd verweist das README auf die offizielle hosts.md-Dokumentation und auf die Einstellung containerd_registries_mirrors bei kubespray.
Kubernetes-Beschleunigung von kubeadm bis repimage
Für kubeadm setzt die ClusterConfiguration in der Version kubeadm.k8s.io/v1beta3 sowohl imageRepository als auch dns.imageRepository auf k8s.m.daocloud.io. Beim Werkzeug kind läuft der Cluster mit dem Image m.daocloud.io/docker.io/kindest/node:v1.22.1, wie der Befehl kind create cluster im README zeigt.
Für alle Pods eines Clusters führt das README das separate Projekt repimage von wzshiming an: Ein Webhook schreibt Image-Verweise neu, ohne YAML oder Helm-Charts zu ändern, bereitgestellt über einen kubectl create-Befehl gegen eine Repimage.yaml. Daneben beschreibt das Projekt eine lokale Cache-Bereitstellung für Intranets, deren Details im Ordner docs/local-cache dokumentiert sind und die die Abhängigkeit vom externen Netz verringert.
Ollama und DeepSeek-R1 im Experimentbereich
Ein eigener Abschnitt behandelt Ollama und DeepSeek. Die Installation läuft über docker run -d -v ollama:/root/.ollama -p 11434:11434 --name ollama docker.m.daocloud.io/ollama/ollama, für die GPU-Variante mit --gpus=all und nach installiertem Nvidia Container Toolkit. Der Modellzugriff erfolgt dann im laufenden Container mit ollama run ollama.m.daocloud.io/library/deepseek-r1:1.5b.
Das README stuft diesen Teil als experimentell ein und weist darauf hin, dass der offizielle Ollama-Kanal ohnehin schnell genug sei, weshalb der direkte Weg über ollama.com eine gleichwertige Alternative ist. Die Spiegel-Unterstützung für registry.ollama.ai ist entsprechend als Inbetriebphase markiert.
Betriebstransparenz und Statusquellen
Der Betrieb ist ungewöhnlich offen dokumentiert. Informationen zu Whitelist und Ratelimiting erscheinen im Issue #2328, Fragen gehören in Issue #4183. Für Pull-Aufgaben empfiehlt das README die Ruhezeiten zwischen 01:00 und 07:00 Uhr Pekinger Zeit, da andere Zeiträume überlastet sind.
Der Backend-Code liegt unter OpenCIDN/ocimirror, eine Statusseite der Synchronisationswarteschlange unter queue.m.daocloud.io/status/ hält nur die letzte Stunde an Aufzeichnungen vor, und der Dienstzustand ist unter status.daocloud.io/status/docker verlinkt. Als Schwestprojekt nennt das README public-binary-files-mirror für die Beschleunigung von Binärdateien. Damit steht für jeden Betriebsaspekt eine prüfbare Quelle bereit, was bei freien Mirror-Diensten nicht selbstverständlich ist.
Redaktionelles Fazit
public-image-mirror passt zu Nutzern in Netzwerkumgebungen mit langsamem Zugang zu Übersee-Registries, die mit dem Präfix m.daocloud.io schnell_IMAGES ziehen wollen; wer Kubernetes-Betrieb bis hin zu kubeadm, kind und containerd abwickelt, findet im README konkrete Konfigurationspfade, sollte aber die Empfehlungen zu Versions-Tags statt latest und zu Pull-Zeiten in der Nacht beachten.
Community-Notizen