Docker-Images auf eigene Registry pushen

Docker-Images auf eigene Registry pushen

Im folgenden Artikel möchten wir anhand eines Dockerfiles ein Image bauen, taggen und zu einer Registry pushen. Hierbei wird eine selbst-gehostete Registry auf Basis des offiziellen Images von Docker verwendet. Dies kann beispielsweise zur Bereitstellung von Images innerhalb eines Kubernetes-Clusters dienen. Grundsätzlich können auch Drittanbieter-Registrys wie z.B. der Docker-Hub genutzt werden, sofern man dies möchte.

Push-Skript erstellen

Grundsätzlich können alle Befehle direkt in der Konsole ausgeführt werden. Allerdings benötigen wir verschiedene Infos wie z.B. das Image-Name oder den Tag mehrfach. Ich empfehle daher, ein kleines Shell-Skript anzulegen. Dies erleichtert auch das Deployment, da dort festgehalten und versioniert wird, welche Tags/Versionen existieren. Zunächst die Meta-Informationen:

name=my-app
tag=0.1.4
fullTag=${name}:${tag}
registryUrl=localhost:5000

Nun wird das Docker-Image erstellt, getaggt und in unsere Registry gepusht:

docker build -t ${fullTag} .
if [ $? != 0 ]; then
    echo "Fehler beim erstellen des Images"
    exit 1
fi
 
docker login -u "admin" -p " " ${registryUrl}
docker tag ${fullTag} ${registryUrl}/${fullTag}
docker push ${registryUrl}/${fullTag}
echo "Image gepusht: ${fullTag}"

Im Beispiel wird eine lokale Docker-Registry ohne Authentifizierung genutzt. Fragen wir unsere Registry ab, zeigt sie das soeben erstellte Repo:

$ curl http://localhost:5000/v2/_catalog
{"repositories":["my-app"]}

Auch die gepushten Tags lassen sich abfragen:

$ curl http://localhost:5000/v2/my-app/tags/list
{"name":"my-app","tags":["0.1.4"]}

Proxy für Build setzen

Dockerfiles laden nicht selten verschiedene Pakete aus dem Internet herunter. In Unternehmensnetzwerken stellt dies ein Problem dar: Meist besitzen die Systeme keinen direkten Internetzugang. Hierfür kommt ein Proxy zum Einsatz. Damit die Verbindung hergestellt werden kann, ist es nötig, den Proxy entsprechend für jede Anwendung zu setzen.

Linux besitzt hierzu die Umgebungsvariablen http_proxy und https_proxy. Nicht alle Anwendungen berücksichtigen diese, aber viele. Dazu gehören auch verbreitete CLI-Werkzeuge wie curl oder wget. Über Buildargumente können wir diese Variablen von außen für den Container setzen:

docker build --build-arg http_proxy=${http_proxy}\
    --build-arg https_proxy=${https_proxy} \
    --build-arg no_proxy=localhost,127.0.0.1 \
    -t ${fullTag} .

Obwohl traditionell in Linux eher die kleingeschriebene Variante genutzt wird, empfehle ich aus Erfahrung, beide zu setzen. Es gibt zwar wenige Programme, welche nur die großgeschriebene Variante unterstützen. Aber wenn man eines erwischt, kann das zu einer langen Fehlersuche führen. Darüber hinaus ist zu empfehlen, die Firmen-Domain für den Proxy auszuschließen. Die Adresse des Proxy-Servers sowie jegliche andere Hostnamen werden am besten als FQDN angegeben.

Leave a Reply