Best Practices für die Verwaltung von Docker-Images mit Pull und Push

Docker-Images bewegen Ihre Anwendung vom Laptop über CI bis zur Produktion, aber schlampige Pull- und Push-Gewohnheiten können Bereitstellungen unberechenbar machen. Wenn Sie sich auf fließende Tags verlassen, Registry-Authentifizierungsprüfungen überspringen oder Images ohne Namensplan pushen, können Sie den falschen Build bereitstellen, selbst wenn jeder Befehl erfolgreich ist.

Diese Best Practices für die Verwaltung von Docker-Images mit docker pull und docker push konzentrieren sich auf reproduzierbare Tags, sichere Registry-Workflows und einfache Befehle, die Sie in Skripten und CI/CD-Pipelines verwenden können.

Grundlegendes zu docker pull

Der Befehl docker pull ist Ihr Zugang zum riesigen Ökosystem vorgefertigter Docker-Images, die in Registries verfügbar sind. Er lädt ein Image oder einen bestimmten Tag von einer Registry auf Ihren lokalen Docker-Daemon herunter. Dies ist der erste Schritt, wenn Sie ein vorhandenes Image als Basis für Ihre eigene Anwendung verwenden oder einen Dienst ausführen möchten, der auf einem bestimmten Container-Image basiert.

Grundlegende Verwendung

Die einfachste Art, docker pull zu verwenden, ist die Angabe des Image-Namens, optional gefolgt von einem Tag:

docker pull <image_name>[:<tag>]

Beispiele:

• Pullen des latest-Tags von Ubuntu:

  docker pull ubuntu
  

  Dies lädt das als latest getaggte Image herunter, was der Standard ist, wenn kein Tag angegeben wird. Behandeln Sie es als praktischen Tag, nicht als Produktions-Pin.

• Pullen einer bestimmten Version von Alpine Linux:

  docker pull alpine:3.18
  

  Dies stellt sicher, dass Sie eine reproduzierbare Build-Umgebung erhalten.

• Pullen eines Images aus einer bestimmten Registry:

  docker pull registry.example.com/my-app:v1.2
  

  Wenn Sie eine private Registry oder eine andere Registry als Docker Hub verwenden, müssen Sie den Registry-Hostnamen angeben.

Best Practices für docker pull

• Geben Sie immer einen Tag an: Sich auf latest zu verlassen, kann zu unerwartetem Verhalten führen, da ein Registry-Besitzer diesen Tag jederzeit verschieben kann. Explizite Tags wie alpine:3.18 oder nginx:1.25-alpine machen Builds leichter wiederholbar.
• Verwenden Sie unveränderliche Referenzen für die Produktion: Tags sind benutzerfreundlich, können aber überschrieben werden. Für strenge Produktions-Rollouts setzen Sie einen getesteten Tag plus den Image-Digest ein, z. B. nginx:1.25-alpine@sha256:<digest>.
• Räumen Sie ungenutzte Images auf: Bereinigen Sie regelmäßig Ihren lokalen Image-Cache mit docker image prune, um Speicherplatz freizugeben. Images, die Sie pullen, können erheblichen Speicherplatz verbrauchen.
• Verstehen Sie Image-Layer: Docker-Images sind in Layern aufgebaut. Wenn Sie ein Image pullen, laden Sie diese Layer herunter. Docker speichert diese Layer intelligent lokal zwischen, sodass beim Pullen eines Images, das Layer mit einem bereits vorhandenen teilt, nur die neuen Layer heruntergeladen werden, was nachfolgende Pulls beschleunigt.

Grundlegendes zu docker push

Der Befehl docker push wird verwendet, um lokal erstellte oder modifizierte Docker-Images in eine Container-Registry hochzuladen. Dies ist unerlässlich, um Ihre Images mit Mitarbeitern zu teilen, sie auf Cloud-Plattformen bereitzustellen oder als Backups zu speichern.

Grundlegende Verwendung

Um ein Image zu pushen, muss es entsprechend mit dem Hostnamen der Registry, Ihrem Benutzernamen (oder Organisationsnamen), dem Image-Namen und einem Tag getaggt werden.

docker push <image_name>[:<tag>]

Voraussetzungen:

1. Sie müssen eingeloggt sein in die Registry, in die Sie pushen möchten, mit docker login.
2. Das Image muss korrekt getaggt sein für die Ziel-Registry.

Taggen für das Pushen

Bevor Sie ein Image pushen können, müssen Sie es mit dem vollständigen Pfad zum Ziel-Repository in der Registry taggen. Das Standardformat ist:

<registry_hostname>/<username_or_organization>/<image_name>:<tag>

Wenn Sie in Docker Hub pushen, wird der registry_hostname normalerweise weggelassen, und das Format wird zu <username>/<image_name>:<tag>.

Beispiel-Workflow:

Angenommen, Sie haben ein Image namens my-app erstellt und möchten es mit dem Tag v1.0 in Ihr Docker Hub-Konto (myusername) pushen.

1. Erstellen Sie Ihr Image (falls noch nicht geschehen):

   docker build -t my-app .
   

2. Taggen Sie das Image für Docker Hub:

   docker tag my-app:latest myusername/my-app:v1.0
   

   Hinweis: Wir taggen den latest-Build von my-app auf den spezifischen Registry-Pfad myusername/my-app:v1.0.

3. Melden Sie sich bei Docker Hub an:

   docker login
   

Verwenden Sie ein Docker Hub-Zugriffstoken oder den empfohlenen Token-Flow Ihrer Registry, anstatt ein Kontopasswort in die Automatisierung einzugeben.

1. Pushen Sie das getaggte Image:

   docker push myusername/my-app:v1.0
   

Best Practices für docker push

• Taggen Sie mit Bedeutung: Verwenden Sie beschreibende Tags (z. B. Versionsnummern, Release-Namen, staging, production) anstelle von nur latest. Dies erleichtert die Identifizierung und Verwaltung bestimmter Versionen Ihres Images.
• Verwenden Sie bei Bedarf mehr als einen Tag: Ein Release-Image kann sowohl 1.4.2- als auch git-3f2a9c1-Tags haben. Die Version hilft Menschen; der Commit-Hash verweist auf den Quellcode.
• Scannen Sie Images auf Schwachstellen: Scannen Sie Ihre Images vor dem Pushen, insbesondere in öffentliche Repositories oder sensible Umgebungen, mit Tools wie Docker Scout oder Drittanbieter-Scannern auf bekannte Schwachstellen.
• Minimieren Sie die Image-Größe: Kleinere Images sind schneller zu pushen und zu pullen. Optimieren Sie Ihr Dockerfile, um die Image-Größe zu reduzieren (z. B. Multi-Stage-Builds verwenden, temporäre Dateien bereinigen, minimale Basis-Images wie Alpine verwenden).
• Verwenden Sie private Registries für sensible Daten: Verwenden Sie für proprietären Code oder sensible Konfigurationen immer eine private Registry und verwalten Sie die Zugriffskontrollen angemessen.
• Automatisieren Sie Tagging und Pushen: Integrieren Sie Image-Tagging und -Pushen in Ihre CI/CD-Pipeline für automatisierte Builds und Bereitstellungen.

Fortgeschrittene Szenarien und Tipps

Pullen und Pushen mehrerer Tags

Standardmäßig arbeiten docker pull und docker push mit einer Image-Referenz. Sie können dieselbe Image-ID mehrfach taggen und jeden Tag pushen. Einige Docker-Versionen unterstützen auch docker image push --all-tags <repository>, wenn Sie absichtlich alle lokalen Tags für ein Repository pushen möchten.

Beispiel: Pushen eines Images mit mehreren Tags

# Fügen Sie einen 'latest'-Tag hinzu, der auf dieselbe Image-ID verweist
docker tag myusername/my-app:v1.0 myusername/my-app:latest

# Pushen Sie den neuen 'latest'-Tag
docker push myusername/my-app:latest

Authentifizierung für private Registries

Für private Registries (wie AWS ECR, Google GCR, Azure ACR oder selbst gehostete Registries) müssen Sie sich authentifizieren, bevor Sie pullen oder pushen können.

# Beispiel für Docker Hub
docker login

# Beispiel für AWS ECR (verwendet oft einen Helfer-Befehl)
aws ecr get-login-password --region <region> | docker login --username AWS --password-stdin <aws_account_id>.dkr.ecr.<region>.amazonaws.com

Lesen Sie immer die Dokumentation Ihrer spezifischen Registry für die korrekte Authentifizierungsmethode.

Image-Layer und Caching

Dockers geschichtetes Dateisystem hält Pulls effizient. Wenn Sie ein Image pullen, überprüft Docker seinen lokalen Content-Store auf vorhandene Layer und lädt nur Layer herunter, die es noch nicht hat. Während docker build kann BuildKit auch zwischengespeicherte Layer aus früheren Builds wiederverwenden, wenn die Dockerfile-Anweisungen und Eingaben sich nicht geändert haben.

Images aktuell halten

Pullen Sie regelmäßig Basis-Images und bauen Sie Ihre Anwendungs-Images neu, um Sicherheitspatches und Updates zu integrieren.

# Pullen Sie das neueste Basis-Image
docker pull python:3.11-slim

# Bauen Sie Ihr Anwendungs-Image mit dem aktualisierten Basis-Image neu
docker build -t myusername/my-app:v1.1 .

# Pushen Sie die neue Version
docker push myusername/my-app:v1.1

Praktische Erkenntnisse

Halten Sie den Workflow für die tägliche Arbeit langweilig: Pullen Sie explizite Basis-Image-Tags, bauen Sie mit einem Versions- und Commit-Tag, scannen Sie das Ergebnis, loggen Sie sich mit einem Token ein und pushen Sie dann nur die Referenzen, die Sie bereitstellen möchten. Notieren Sie für die Produktion den Digest, der die Tests bestanden hat, damit dasselbe Image später gepullt werden kann, selbst wenn sich ein veränderlicher Tag ändert.