Wo Docker-Images speichern?
Einleitung
Ihre Container-Registry ist kein Fileshare — sie ist ein Glied Ihrer Software-Lieferkette und eine Laufzeitabhängigkeit jedes Deployments. Ist sie down, können Sie weder hochskalieren noch zurückrollen; ist sie schlecht gemanagt, trennt Sie nur ein einziger veränderlicher Tag davon, nicht mehr zu wissen, was in Produktion läuft. So sieht die Registry-Landschaft 2026 tatsächlich aus — und diese Hygiene zählt mehr als die Frage, welchen Anbieter Sie wählen.
Die Registry-Landschaft 2026
Cloud-Provider-Registries: ECR, Artifact Registry, ACR
Laufen Ihre Workloads auf AWS, Google Cloud oder Azure, lautet die Standardantwort: die Registry des Providers — Amazon ECR, Google Artifact Registry (Nachfolger der eingestellten Container Registry) oder Azure Container Registry. Sie erhalten natives IAM für Push-/Pull-Berechtigungen, private Netzwerk-Endpoints, damit Pulls nie das öffentliche Internet queren, eingebautes Vulnerability-Scanning und regionsübergreifende Replikation. Pulls innerhalb derselben Region sind schnell und in der Regel kostenlos — im Cluster-Maßstab relevant; ein Punkt, der sich durch unsere Cloud-Computing-Projekte zieht, denn Registry-Egress ist ein kleiner, aber wiederkehrender Posten, den viele vergessen, per Design zu eliminieren.
Git-Forge-Registries: GHCR und GitLab
Die GitHub Container Registry und die GitLab Container Registry legen Images direkt neben den Code und die CI, die sie baut; die Authentifizierung setzt auf dem Token auf, das Ihre Pipeline ohnehin besitzt. Für Open-Source-Distribution und für Teams, deren gesamter Lifecycle in der Forge lebt, ist das 2026 die reibungsärmste Option.
Docker Hub
Docker Hub bleibt der größte öffentliche Katalog und der richtige Ort, um ein öffentliches Image zu verteilen. Als privater Enterprise-Speicher ist er selten geworden — und seine anonymen Pull-Rate-Limits machen eine direkte Abhängigkeit aus CI oder Produktion zu einem selbstverschuldeten Ausfall mit Ansage (die Lösung ist ein Pull-Through-Cache, siehe unten).
Self-Hosted: Harbor
Harbor, ein CNCF-graduiertes Projekt, ist der Standard, wenn Datenresidenz, Air-Gapped-Umgebungen oder volle Kontrolle Self-Hosting verlangen: projektweises RBAC, Quotas, Replikation zwischen Registries, ein Proxy-Cache und eingebautes Trivy-Scanning. Quay ist die nennenswerte Alternative. Self-Hosting bedeutet, dass Sie fortan einen Tier-Zero-Service betreiben — budgetieren Sie das ehrlich.
Registry-Hygiene, die wirklich zählt
1. Tags unveränderlich machen
Aktivieren Sie Tag-Immutability, wo die Registry es unterstützt (ECR und Harbor tun es), und deployen Sie über eindeutige Versions-Tags oder Digests — niemals über ein veränderliches :latest. Kann ein Tag stillschweigend umgehängt werden, hat die Frage „Was läuft in Produktion?“ keine verlässliche Antwort — und ein Rollback ebenso wenig.
2. Retention-Policies setzen
Die CI produziert unablässig Images; ohne Lifecycle-Regeln wird eine Registry zur teuren Rumpelkammer. Lassen Sie untagged Manifeste binnen weniger Tage verfallen und behalten Sie die letzten N Releases pro Repository — jede große Registry unterstützt das nativ.
3. Images signieren und bei Admission verifizieren
Signieren Sie Images in der CI mit cosign (Sigstore — schlüsselloses Signieren gegen die OIDC-Identität Ihrer CI) oder Notation und erzwingen Sie die Verifikation am Cluster über eine Admission-Policy wie Kyverno. Eine Signatur, die nichts verifiziert, ist Dekoration; auf der Durchsetzungsseite investiert unsere SecOps-Practice den Großteil ihres Aufwands.
4. In der CI und in der Registry scannen
Scannen Sie in der Pipeline mit Trivy oder Grype, bevor Sie pushen, und lassen Sie das registryseitige Scanning aktiviert (ECR-Scanning, Harbors eingebautes Trivy), damit Images von vor Wochen neu geflaggt werden, wenn neue CVEs erscheinen. Scanning ist nur die halbe Geschichte — das Image muss das Scannen wert sein, und das beginnt beim Build selbst; siehe unseren Leitfaden zu Dockerfile Best Practices.
5. Einen Pull-Through-Cache betreiben
Spiegeln Sie Upstream-Registries, statt live von ihnen abzuhängen: ECR-Pull-Through-Cache-Regeln, Artifact-Registry-Remote-Repositories oder ein Harbor-Proxy-Projekt. Ihre Builds und Cluster laufen durch einen Docker-Hub-Ausfall oder eine Rate-Limit-Klemme hindurch weiter, und Pulls werden schneller und günstiger.
6. Aus der CI per OIDC pushen, nicht mit hinterlegten Keys
Docker Hubs altes Automated-Builds-Feature ist nicht die Art, wie Images 2026 gebaut werden — die CI ist es. Lassen Sie GitHub Actions (oder Ihre CI der Wahl) per OIDC-Föderation eine kurzlebige Cloud-Rolle übernehmen, um nach ECR oder Artifact Registry zu pushen. Keine langlebigen Registry-Credentials, die in CI-Secrets herumliegen.
Fazit
Wählen Sie die Registry, die am nächsten an Ihren Workloads liegt, und stecken Sie Ihre Energie dann in die Hygiene: unveränderliche Tags, Retention, Signieren mit Verifikation, mehrschichtiges Scanning und ein Pull-Through-Cache. Diese Kombination — nicht das Vendor-Logo — macht eine Registry vertrauenswürdig.
Das in Produktion betreiben? Unser AWS-Managed-Services-Team betreibt solche Umgebungen rund um die Uhr — Monitoring, Incident Response, Patching und Kostenkontrolle durch namentlich benannte Senior Engineers, ab 3.000 €/Monat.