Blog

Docker Hub Tipps und Tricks

Aktualisiert Oktober 21, 2025

5 Minuten

Docker Hub ist die Standard-Container-Registry, die von Ihrem lokalen Docker-Client verwendet wird. Er beherbergt alle Arten von Container-Images, von offiziellen wie Debian bis hin zu inoffiziellen, die jeder selbst erstellen kann. In diesem Blogpost erkläre ich, worauf Sie bei der Auswahl eines Images achten sollten, und zeige Ihnen einige Tricks, die ich bei der Entwicklung unserer eigenen Images gelernt habe.

Die Wahl des richtigen Bildes

Wenn ich ein Image auswähle, achte ich auf ein paar Dinge. Zuerst prüfe ich, ob es sich um ein offizielles Image handelt oder nicht. Offizielle Images werden von der gleichen Gemeinschaft gepflegt wie die Software, die Sie ausführen möchten, und daher habe ich etwas mehr Vertrauen in diese Images. Zweitens schaue ich mir die Anzahl der Pulls dieses Images an. Das Debian-Image, auf das ich vorhin verwiesen habe, hat z.B. mehr als 10 Millionen Pulls und daher erwarte ich, dass es stabiler ist. Drittens sehe ich mir den Zeitstempel der letzten Aktualisierung der Images an. Wenn dieser ein paar Monate zurückliegt, dann wurden die Images auf einer älteren Version der Basis-Images aufgebaut und es könnten viele Sicherheitspatches fehlen. Viertens überprüfe ich, ob es sich um ein Image handelt, das mit einem automatischen Build verbunden ist. Ein Beispiel für ein solches Image ist Home Assistant. Ein automatisiertes Build führt in der Regel zu häufigeren Updates und damit zu weniger Sicherheitslücken. Und schließlich werfen Sie einen Blick auf die Größe des Images. Manchmal ist es ein Problem, dass größere Images zu einer langsameren Bereitstellung führen, manchmal aber auch nicht.

Unser eigenes Miniconda-Bild erstellen

Bei unseren Kunden bauen wir oft Container auf der Grundlage von Miniconda. Miniconda wird von Continuum entwickelt und bündelt den Paketmanager conda und eine Python-Version. Eine großartige Kombination, auf der jeder DataScience-Container basieren kann. Continuum hat sein eigenes Miniconda-Image, aber es gab einige Dinge, die mir an diesem Image nicht gefielen. Die Images sind ziemlich alt, wobei das letzte Image vor über 2 Monaten aktualisiert wurde. Ältere Versionen scheinen nach ihrer ersten Veröffentlichung nie aktualisiert zu werden. Außerdem können Sie mit den Tags, die Continuum zur Verfügung stellt, keine Python-Version angeben, sondern nur die zu verwendende Miniconda-Version. Und schließlich könnten einige Dinge in der Dockerdatei optimiert werden, um die Größe des endgültigen Images zu verringern.

Was haben wir also verbessert?

Dockerdatei

Zunächst haben wir die Dockerdatei geändert:

VON debian:stretch-slim

ARG BUILD_DATE
ARG MINICONDA_VERSION=3
ARG MINICONDA_RELEASE=aktuell
ARG PYTHON_VERSION

LABEL org.label-schema.name="Kontinuum Miniconda  $PYTHON_VERSION"  
  org.label-schema.build-date=$BUILD_DATE 
  org.label-schema.version=$MINICONDA_VERSION-$MINICONDA_RELEASE

ENV PATH="/opt/miniconda${MINICONDA_VERSION}/bin:${PATH}"

RUN set -x  && 
  apt-get update  && 
  apt-get install -y curl bzip2  && 
  curl -s --url "https://repo.continuum.io/miniconda/Miniconda${MINICONDA_VERSION}-${MINICONDA_RELEASE}-Linux-x86_64.sh" --output /tmp/miniconda.sh  && 
  bash /tmp/miniconda.sh -b -f -p "/opt/miniconda${MINICONDA_VERSION}"  && 
  rm /tmp/miniconda.sh  && 
  apt-get purge -y --auto-remove curl bzip2  && 
  apt-get clean  && 
  conda config --set auto_update_conda true  && 
  wenn [ "$MINICONDA_VERSION" = "2" ]; dann
  conda install -y futures;
  fi  && 
  wenn [ "$MINICONDA_RELEASE" = "zuletzt" ]; dann
  conda update conda -y --force;
  fi  && 
  wenn [ -n "$PYTHON_VERSION" ]; dann
  conda install python=$PYTHON_VERSION  -y --force;
  fi  && 
  conda sauber -tipsy  && 
  find /opt/miniconda${MINICONDA_VERSION}  -depth ( ( -type d -a ( -name test -o -name tests ) ) -o ( -type f -a ( -name '*.pyc' -o -name '*.pyo' ) ) ) | xargs rm -rf  && 
  echo "PATH=/opt/miniconda${MINICONDA_VERSION}/bin:${PATH}"  > 
/etc/profile.d/miniconda.sh

ENTRYPOINT ["conda"]
CMD ["--help"]

Wir haben das Debian-Basis-Image auf ein Release umgestellt. Wir haben z.B. nicht den latest-Tag verwendet. Als Nächstes fügen wir ein paar build args ein, um die heruntergeladene/installierte Version von miniconda zu ändern. Wir haben ein Label angegeben, um zu zeigen, welche Version/Release dieses Image bündelt, und schließlich haben wir eine einzelne RUN Anweisung, um die Gesamtgröße des Images zu reduzieren.

Automatisierte Erstellung

Zweitens haben wir unser Github-Repositorium mit unserem Docker Hub verknüpft, um automatisierte Builds nutzen zu können. Docker Hub pingt Github an und plant automatisch einen Rebuild der Images, wenn es eine Änderung am Master-Branch feststellt. Da wir außerdem einen Rebuild aktiviert haben, wenn sich das Basis-Image ändert, fügen wir automatisch Sicherheitspatches in unsere Images ein.

Nachdem eine Änderung erkannt wurde, verwendet Docker Hub die von Ihnen angegebenen Build-Regeln, um den Build-Prozess zu starten. Für unser Miniconda-Image haben wir 4 Build-Regeln mit den folgenden Docker-Tags konfiguriert:

latest-2.7,2.7,2
4.5.11-3.5,3.5
latest-3.6,3.6,3,latest
latest-3.7,3.7

Jede Build-Regel führt zu einem Build, und da wir einen modifizierten Build-Hook (siehe nächster Schritt) in unser Repository aufnehmen, können wir die Tags verwenden, um den Build-Schritt selbst zu beeinflussen.

Haken bauen

#!/bin/bash

IMAGE_TAG=${IMAGE_NAME#*:}

MINICONDA_RELEASE=${IMAGE_TAG%-*}
PYTHON_VERSION=${IMAGE_TAG#*-}
MINICONDA_VERSION=${PYTHON_VERSION:0:1}

# Build auslösen
docker build --build-arg  BUILD_DATE=</span>date -u +<span class="s2">"%Y-%m-%dT%H:%M:%SZ"</span><span class="sb"> 
  --build-arg  MINICONDA_VERSION=$MINICONDA_VERSION  
  --build-arg  MINICONDA_RELEASE=$MINICONDA_RELEASE  
  --build-arg  PYTHON_VERSION=$PYTHON_VERSION  
  -t  $DOCKER_REPO:${DOCKER_TAG//,/ -t  $DOCKER_REPO:}  .

Wenn Sie ein hooks/build Skript in Ihr Git Repo stellen, verwendet Docker Hub dieses Skript, um Ihr Image zu erstellen. In unserem Fall verwenden wir es, um die $IMAGE_NAME zu manipulieren und die Build-Argumente aus ihr zu extrahieren. $IMAGE_NAME ist der primäre Name des Bildes (z.B. index.docker.io/godatadriven/miniconda:latest-2.7), $DOCKER_REPO der Repo-Teil (index.docker.io/godatadriven/miniconda) und $DOCKER_TAG alle Tags (latest-2.7,2.7,2). Wir verwenden bash um das primäre Tag eines Images in seine Komponenten zu zerlegen und diese an den Docker-Build-Prozess zu übergeben. z.B. latest-2.7 führt zu $MINICONDA_RELEASE==latest, $MINICONDA_VERSION==2, und $PYTHON_VERSION==2.7.

Die letzte Zeile des Docker-Builds sorgt dafür, dass dieses Bild mit jedem einzelnen Tag in der Docker-Build-Regel versehen wird. Im obigen Beispiel wird dieses Bild beispielsweise mit godatadriven/miniconda:latest-2.7, godatadriven/miniconda:2.7 und godatadriven/miniconda:2 markiert.

Schlusswort

Ich bin der Meinung, dass die Kombination aus einer Dockerdatei mit Build-Args, den automatischen Builds mit Build-Regeln und dem benutzerdefinierten Build-Hook uns viel Flexibilität gibt, wenn es darum geht, festzulegen, welche/wie die Images gebaut werden sollen. Da wir außerdem immer dann neu bauen, wenn sich die Basis-Images ändern, halten wir automatisch mit Sicherheitspatches Schritt (in diesem Fall debian:stretch-slim).

Nächstes Mal zeige ich Ihnen, wie Sie diesen Ansatz erweitern und einige Tests einbeziehen können, um sicherzustellen, dass die von uns erstellten Images auch tatsächlich laufen.

Tags:

Unsere Ideen