Begriff

Docker Registry

Containerization Distribution S1

2 Quellen 1 Lernpfad 0 Backlinks enriched

Warum wichtig?

Dieser Begriff ist ein Knoten im SengakujiWorks-Wissensnetz. Nutze Level 0 für die erste Einordnung, Level 1 für Praxis, Level 2 für technische Struktur und Level 3 für Grenzen, Fallstricke und Expertenkontext.

Du hast ein Image gebaut (docker build). Es liegt auf deinem Laptop. Dein Kollege will es auch haben. Schickst du ihm einen USB-Stick? Nein. Du lädst es in eine Registry hoch (docker push). Er lädt es herunter (docker pull). Die Registry ist wie ein App Store oder Google Drive für Docker Images. Die bekannteste ist Docker Hub (öffentlich). Firmen nutzen private Registries (Google Artifact Registry, AWS ECR, Harbor), damit der Quellcode geheim bleibt.

Merksatz: Ein zentraler Serverdienst zum Speichern und Verteilen von Docker Images. Es verwaltet Repositories und Tags und regelt den Zugriff (Authentifizierung).

Login: docker login registry.example.com (Benutzer/Passwort).
Taggen: Du musst dem Image sagen, wohin es soll. docker tag mein-app registry.example.com/team/mein-app:v1 Der Servername ist Teil des Imagenamens!
Push: docker push registry.example.com/team/mein-app:v1.
Pull: Auf dem server: docker pull ....

Praxisroutine

In der Praxis lernst du Docker Registry, indem du mit einem kleinen, kontrollierten Beispiel beginnst. Baue zuerst einen Minimalfall, prüfe das Ergebnis, veraendere genau eine Sache und beobachte, was sich ändert. Notiere dir Eingabe, Aktion, Ausgabe und typischen Fehler.

Übung: Erstelle ein Beispiel aus deinem Alltag, fuehre den Ablauf gedanklich Schritt für Schritt durch und markiere die Stelle, an der du Feedback oder ein Log brauchst. Wenn du diese Stelle benennen kannst, verstehst du den Begriff praktisch.

1. Registry API V2 & Content Addressable Storage

Die Registry speichert Blobs (Layer). Jeder Blob hat einen Hash (SHA256). Wenn du Image A (Ubuntu + App) und Image B (Ubuntu + DB) pushst. Die Registry merkt: "Hey, der Ubuntu-Layer abc123 ist schon da." Sie speichert ihn nur einmal (Deduplication). Das spart Petabytes an Speicher bei großen Firmen. Der Client fragt beim Push erst "Hast du Hash X schon?". Registry: "Ja". Client: "Okay, überspringe Upload."

2. Garbage Collection (GC)

Wenn du ein Tag (:latest) überschreibst (Updates), verweist das alte Manifest auf nichts mehr. Aber die Layer (Blobs) bleiben auf der Festplatte. Registry-Admins müssen regelmäßig GC laufen lassen. Der Prozess stoppt oft die Registry (Read-Only Mode), scannt alle Manifeste und löscht verwaiste Blobs ("Dangling Layers").

3. Proxy & Mirroring

In großen Firmen (10.000 Entwickler) ist der Traffic zum Docker Hub teuer/langsam. Man stellt eine Pull-Through Cache Registry ins lokale LAN. Client -> "Gib mir Nginx". lokale Registry -> "Hab ich nicht. Lade von Docker Hub... Speichere... Hier hast du es." Nächster Client -> "Gib mir Nginx". lokale Registry -> "Hier (aus Cache)." Spart Bandbreite und schützt vor Docker Hub Outages.

1. HTTP API V2 und Push-Mechanismus (Content Addressable)

Wenn docker push feuert, lädt es nicht stumm ein 2GB Blob hoch. Der Docker-Client redet mit der REST API (/v2/<name>/blobs/uploads/). Der Client iteriert durch alle 10 Layer deines Images. Er berechnet lokal den SHA256 Hash des Layers. Er funkt zur Registry: "Hast du Hash a3f5... schon?". Hat die Registry den Layer von einem ganz anderen Entwickler-Image (z.B. Node.js Alpine base) bereits in ihrer globalen Datenbank, antwortet sie: "Ja, hab ich! Skip das!". Dieses Content Addressable Storage Design ist der Grund, warum ein Push von 500 MB manchmal nur Millisekunden dauert, weil physisch kein Byte über Netz ging. Alles ist dedupliziert.

2. Manifest Lists (Fat Manifests) für Multi-Arch

Die Welt ist gespalten in AMD64 (Intel Server) und ARM64 (Apple M2, AWS Graviton). Wenn du docker pull nginx:latest machst, wie lädt das System das richtige Binary für deine CPU? Das Geheimnis ist die Manifest-List (Fat Manifest). Hinter dem Tag :latest liegt auf der Registry kein direktes Image. Dort liegt ein intelligenter Router (JSON).

"manifests": [
  { "digest": "sha256:123...", "platform": { "architecture": "amd64" } },
  { "digest": "sha256:456...", "platform": { "architecture": "arm64" } }
]

Dein lokaler Docker Daemon liest das JSON, checkt deine Hardware, und lädt stumm den passenden Digest herunter. Es ist eine architektonische Meisterleistung für unsichtbare Cross-Platform Kompatibilität.

3. Garbage Collection (Registry Bloat)

In CI/CD Pipelines pushen Firmen am Tag 100 neue Versionen. Du überschreibst ständig den Tag :latest. Die Registry trennt den Tag vom alten Image v1 und heftet :latest an v2. Das Image v1 ist nun ein Dangling Image (es hat keinen Tag-Namen mehr), verbraucht aber weiter 500 MB Festplatte auf der Registry. Die Registry-Festplatten (S3 Buckets) laufen voll. Um den Mülleimer zu leeren, muss der Registry-Admin einen "Read-Only Lock" setzen, externe Schreib-Pushes blockieren und den hoch-aggressiven Garbage-Collection Prozess ausführen, der verwaiste Blobs (die kein Manifest mehr referenzieren) schreddert.

Quick-Check

Unterschied Repository vs. Registry?
Registry = Der Server (z. B. Docker Hub). Repository = Ein Ordner darin (z. B. nginx oder myuser/myapp). Ein Repository enthält viele Versionen (Tags) eines Images.
Was ist library/?
Wenn du docker pull ubuntu tippst, macht Docker daraus docker.io/library/ubuntu. library ist das offizielle Repository für "zertifizierte" Images auf dem Hub.
Kann ich eine Registry selbst hosten?
Ja, docker run -p 5000:5000 registry:2. Es ist selbst nur ein Container! Aber Achtung: Du musst dich selbst um SSL, Auth und Backups kümmern.