Zum Inhalt springen

Docker/Image/Erstellung

Aus Foxwiki

Docker/Image/Erstellung - Image-building best practices

Docker-Images erstellen

  • Docker-Hub bietet umfangreiche Möglichkeiten zum Erstellen eigener Images und zum Austausch dieser Images.
Erstellen einer Dockerfile
  • Jedes Docker-Image basiert auf einer Dockerfile
  • Eine Dockerfile ist eine Textdatei, die Anweisungen zum Erstellen eines Images enthält

1. Verwenden Sie folgenden Kommandozeilenbefehl, um ein Verzeichnis mit dem Namen mydockerbuild zu erstellen: 

mkdir mydockerbuild

2. In das neue Verzeichnis navigieren 

 cd mydockerbuild

3.  Neue Textdatei erstellen 

nano Dockerfile

Dockerfile schreiben

Die neu erstellte Textdatei dient als Bauplan für Ihr selbst entwickeltes Image

  • Anstatt das Image von Grund auf neu zu programmieren, wird in diesem Docker-Handbuch das Demo-Image docker/whalesay als Vorlage verwendet.
  • Um das Image in die Dockerfile aufzunehmen, muss darin der Befehl FROM angegeben werden.
  • Um die neueste Version des Images zu erhalten, wird das Tag :latest verwendet.
FROM docker/whalesay:latest

Bisher arbeitet docker/whalesay so, dass Sie dem Wal die Worte in den Mund legen müssen

  • Das Terminal zeigt genau den Text an, der zuvor in Kombination mit dem Befehl zum Starten des Containers eingegeben wurde.
  • Als Nächstes wird die automatische Generierung neuer Text-Ausgabedaten mit Hilfe des Programms fortunes gezeigt.
  • Die Grundfunktion von Fortunes besteht darin, Glückskeks-Sprüche und humorvolle Aphorismen zu generieren
  • Um den lokalen Paketindex zu aktualisieren und fortunes zu installieren, verwenden Sie den folgenden Befehl:
RUN apt-get -y update && apt-get install -y fortunes

Anschließend definieren Sie ein CMD-Statement

  • Das CMD-Statement wird beim Start des Containers ausgeführt, sofern es beim Aufruf (docker run image CMD) nicht überschrieben wurde
  • Verwenden Sie folgenden Befehl, um das Programm fortunes mit der Option -a („Wähle aus allen Datenbanken“) auszuführen und die Ausgabe über das Programm cowsay im Terminal anzeigen zu lassen:
CMD /usr/games/fortune -a | cowsay

Ihr Dockerfile sollte nun folgendermaßen aussehen: 

FROM docker/whalesay:latest
RUN apt-get -y update && apt-get install -y fortunes
CMD /usr/games/fortune -a | cowsay
Hinweis
Befehle innerhalb eines Dockerfiles sind immer einzeilig und beginnen stets mit einem Schlüsselwort
  • Die zugrundeliegende Syntax ist case-insensitive – es ist also egal, ob Sie groß- oder kleinschreiben
  • Es hat sich jedoch eine konsequente Großschreibung von Schlüsselwörtern etabliert
  • Textdatei speichern: Speichern Sie Ihre Eingabe
  • Sollten Sie den Editor Nano verwenden, nutzen Sie dazu die Tastenkombination [STRG] + [O] und bestätigen Sie mit [ENTER]
  • Nano gibt Ihnen die Meldung aus, dass drei Zeilen in die ausgewählte Datei geschrieben wurden
  • Beenden Sie den Texteditor mit der Tastenkombination [STRG] + [X]
  • Image aus Dockerfile erstellen: Um ein Image aus einem Dockerfile zu erstellen, navigieren Sie zunächst in das Verzeichnis, in dem Sie die Textdatei abgelegt haben
  • Die Image-Erstellung starten Sie mit dem Kommandozeilenbefehl docker build
  • Möchten Sie das Image individuell benennen oder mit einem Tag versehen, verwenden Sie die Option -t sowie nachfolgend die gewünschte Kombination aus Bezeichnung und Tag
  • Es gilt das Standardformat name:tag

Im aktuellen Beispiel soll ein Image mit dem Namen docker-whale erzeugt werden: 

docker build -t docker-whale .

Der abschließende Punkt gibt an, dass sich das zugrundeliegende Dockerfile im ausgewählten Verzeichnis befindet

  • Alternativ haben Sie die Möglichkeit, einen Dateipfad oder eine URL zu den Quelldateien anzugeben

Der build-Prozess startet, sobald Sie den Befehl mit [ENTER] bestätigt haben

  • Zunächst überprüft der Docker-Daemon, ob ihm alle Dateien vorliegen, die für die Erstellung des Images benötigt werden
  • In der Docker-Terminologie werden diese unter dem Begriff „Context“ zusammengefasst
  • Im Anschluss wird das Image docker/whalesay mit dem Tag :latest lokalisiert
  • Liegt der für die Image-Erstellung benötigte Context vollständig vor, startet der Docker-Daemon die via FROM eingebundene Image-Vorlage in einem temporären Container und geht zum nächsten Befehl im Dockerfile über
  • Im aktuellen Beispiel handelt es sich dabei um den RUN-Befehl, der die Installation des fortunes-Programms zur Folge hat

Am Ende jedes Schritts im Rahmen der Image-Erstellung gibt Docker Ihnen eine ID für den entsprechenden Layer (Schicht) aus, der in diesem Schritt erstellt wurde

  • Dabei gilt: Jede Zeile im zugrundeliegenden Dockerfile entspricht einem Layer des darauf aufbauenden Images

Wurde der RUN-Befehl beendet, stoppt der Docker-Daemon den dafür erstellten Container, entfernt diesen und startet einen neuen temporären Container für das Layer des CMD-Statements

  • Am Ende des Erstellungsprozesses wird auch dieser temporäre Container beendet und entfernt
  • Docker gibt Ihnen die ID des neuen Images aus:
Successfully built a8f2048c9ab8

Ihr neu erstelltes Image finden Sie unter dem Namen docker-whale in der Übersicht ihrer lokal gespeicherten Images 

sudo docker images

Um einen Container aus Ihrem neu erstellten Image zu starten, verwenden Sie den Kommandozeilenbefehl sudo docker run in Kombination mit dem Namen des Images: 

sudo docker run docker-whale

Wurde das Image fehlerfrei aus dem Dockerfile erstellt, sollte Ihr Wal Sie nun mit mehr oder weniger weisen Sprüchen begeistern

  • Beachten Sie: Jedes Mal, wenn Sie den Container neu starten, wird ein anderer Spruch generiert

Image layering

Using the docker image history command, you can see the command that was used to create each layer within an image

Docker image history

Use the docker image history command to see the layers in the getting-started image you created 

docker image history getting-started

IMAGE               CREATED             CREATED BY                                      SIZE                COMMENT
a78a40cbf866        18 seconds ago      /bin/sh -c #(nop)  CMD ["node" "src/index.j…    0B
f1d1808565d6        19 seconds ago      /bin/sh -c yarn install --production            85.4MB
a2c054d14948        36 seconds ago      /bin/sh -c #(nop) COPY dir:5dc710ad87c789593…   198kB
9577ae713121        37 seconds ago      /bin/sh -c #(nop) WORKDIR /app                  0B
b95baba1cfdb        13 days ago         /bin/sh -c #(nop)  CMD ["node"]                 0B
<missing>           13 days ago         /bin/sh -c #(nop)  ENTRYPOINT ["docker-entry…   0B
<missing>           13 days ago         /bin/sh -c #(nop) COPY file:238737301d473041…   116B
<missing>           13 days ago         /bin/sh -c apk add --no-cache --virtual .bui…   5.35MB
<missing>           13 days ago         /bin/sh -c #(nop)  ENV YARN_VERSION=1.21.1      0B
<missing>           13 days ago         /bin/sh -c addgroup -g 1000 node     && addu…   74.3MB
<missing>           13 days ago         /bin/sh -c #(nop)  ENV NODE_VERSION=12.14.1     0B
<missing>           13 days ago         /bin/sh -c #(nop)  CMD ["/bin/sh"]              0B
<missing>           13 days ago         /bin/sh -c #(nop) ADD file:e69d441d729412d24…   5.59MB

Each of the lines represents a layer in the image

  • The display here shows the base at the bottom with the newest layer at the top
  • Using this, you can also quickly see the size of each layer, helping diagnose large images

You'll notice that several of the lines are truncated

  • If you add the --no-trunc flag, you'll get the full output
docker image history --no-trunc getting-started

Layer caching

Now that you've seen the layering in action, there's an important lesson to learn to help decrease build times for your container images

  • Once a layer changes, all downstream layers have to be recreated as well

Look at the following Dockerfile you created for the getting started app 

syntax=docker/dockerfile:1
FROM node:lts-alpine
WORKDIR /app
COPY . 
RUN yarn install --production
CMD ["node", "src/index.js"]

Going back to the image history output, you see that each command in the Dockerfile becomes a new layer in the image

  • You might remember that when you made a change to the image, the yarn dependencies had to be reinstalled
  • It doesn't make much sense to ship around the same dependencies every time you build
Caching von Abhängigkeiten

To fix it, you need to restructure your Dockerfile to help support the caching of the dependencies

  • For Node-based applications, those dependencies are defined in the package.json file
  • You can copy only that file in first, install the dependencies, and then copy in everything else
  • Then, you only recreate the yarn dependencies if there was a change to the package.json

1. Update the Dockerfile to copy in the package.json first, install dependencies, and then copy everything else in 

syntax=docker/dockerfile:1
FROM node:lts-alpine
WORKDIR /app
COPY package.json yarn.lock ./
RUN yarn install --production
COPY . 
CMD ["node", "src/index.js"]

2. Build a new image using docker build 

docker build -t getting-started .

You should see output like the following 

 [+] Building 16.1s (10/10) FINISHED
 => [internal] load build definition from Dockerfile
 => => transferring dockerfile: 175B
 => [internal] load .dockerignore
 => => transferring context: 2B
 => [internal] load metadata for docker.io/library/node:lts-alpine
 => [internal] load build context
 => => transferring context: 53.37MB
 => [1/5] FROM docker.io/library/node:lts-alpine
 => CACHED [2/5] WORKDIR /app
 => [3/5] COPY package.json yarn.lock ./
 => [4/5] RUN yarn install --production
 => [5/5] COPY . 
 => exporting to image
 => => exporting layers
 => => writing image     sha256:d6f819013566c54c50124ed94d5e66c452325327217f4f04399b45f94e37d25
 => => naming to docker.io/library/getting-started
  • Now, make a change to the src/static/index.html file
  • For example, change the <title> to "The Awesome Todo App"
  • Build the Docker image now using docker build -t getting-started again
  • This time, your output should look a little different
 [+] Building 1.2s (10/10) FINISHED
 => [internal] load build definition from Dockerfile
 => => transferring dockerfile: 37B
 => [internal] load .dockerignore
 => => transferring context: 2B
 => [internal] load metadata for docker.io/library/node:lts-alpine
 => [internal] load build context
 => => transferring context: 450.43kB
 => [1/5] FROM docker.io/library/node:lts-alpine
 => CACHED [2/5] WORKDIR /app
 => CACHED [3/5] COPY package.json yarn.lock ./
 => CACHED [4/5] RUN yarn install --production
 => [5/5] COPY . 
 => exporting to image
 => => exporting layers
 => => writing image     sha256:91790c87bcb096a83c2bd4eb512bc8b134c757cda0bdee4038187f98148e2eda
 => => naming to docker.io/library/getting-started

First off, you should notice that the build was much faster

  • And, you'll see that several steps are using previously cached layers
  • Pushing and pulling this image and updates to it will be much faster as well

Multi-stage builds

Multi-stage builds are an incredibly powerful tool to help use multiple stages to create an image

  • There are several advantages for them
  • Separate build-time dependencies from runtime dependencies
  • Reduce overall image size by shipping only what your app needs to run

Maven/Tomcat example

When building Java-based applications, you need a JDK to compile the source code to Java bytecode

  • However, that JDK isn't needed in production
  • Also, you might be using tools like Maven or Gradle to help build the app
  • Those also aren't needed in your final image
  • Multi-stage builds help
# syntax=docker/dockerfile:1
FROM maven AS build
WORKDIR /app
COPY . 
RUN mvn package
FROM tomcat
COPY --from=build /app/target/file.war /usr/local/tomcat/webapps

In this example, you use one stage (called build) to perform the actual Java build using Maven

  • In the second stage (starting at FROM tomcat), you copy in files from the build stage
  • The final image is only the last stage being created, which can be overridden using the --target flag

React example

When building React applications, you need a Node environment to compile the JS code (typically JSX), SASS stylesheets, and more into static HTML, JS, and CSS

  • If you aren't doing server-side rendering, you don't even need a Node environment for your production build

You can ship the static resources in a static nginx container 

# syntax=docker/dockerfile:1
FROM node:lts AS build
WORKDIR /app
COPY package* yarn.lock ./
RUN yarn install
COPY public ./public
COPY src ./src
RUN yarn run build
FROM nginx:alpine
COPY --from=build /app/build /usr/share/nginx/html

In the previous Dockerfile example, it uses the node:lts image to perform the build (maximizing layer caching) and then copies the output into an nginx container

Tutorial

Docker-Images herunterladen

Hochladen von Docker-Images auf Docker-Hub

Das whalesay-Image finden Sie, indem Sie die Startseite des Docker-Hubs aufrufen und den Begriff whalesay in die Suchleiste rechts neben dem Docker-Logo eingeben

Klicken Sie in den Suchergebnissen auf die Ressource mit der Bezeichnung docker/whalesay, um das öffentliche Repository für dieses Image aufzurufen

Docker-Repositorys sind immer nach demselben Muster aufgebaut: Im Kopfbereich der Seite finden Nutzer die Bezeichnung des Images, die Kategorie des Repositorys sowie den Zeitpunkt des letzten Uploads (last pushed)

Darüber hinaus bietet jedes Docker-Repository folgende Info-Boxen:

Feld Beschreibung
Description ausführliche Beschreibung, in der Regel inklusive Gebrauchsanweisung
Docker Pull Command Kommandozeilenbefehl, um das Image aus dem Repository herunterzuladen (pull)
Owner Information über den Ersteller des Repositorys
Comments Kommentarbereich am Seitenende

Den Informationsboxen des Repositorys lässt sich entnehmen, dass es sich bei whalesay um eine Modifikation des quelloffenen Perl-Skripts cowsay handelt

  • Das von Tony Monroe im Jahr 1999 entwickelte Programm generiert in seiner Ursprungsform eine ASCII-Grafik in Form einer Kuh, die zusammen mit einer Nachricht im Terminal des Benutzers erscheint

Um docker/whalesay herunterzuladen, benutzen Sie den Befehl docker pull nach folgendem Grundschema: 

docker pull [OPTIONS] NAME [:TAG|@DIGEST]

Der Befehl docker pull weist den Daemon an, ein Image aus dem Repository zu laden

  • Um welches Image es sich handelt, bestimmen Sie durch die Angabe der Image-Bezeichnung (NAME)
  • Darüber hinaus können Sie Docker anweisen, wie der gewünschte Befehl ausgeführt werden soll (OPTIONS)
  • Ebenfalls optional ist die Angabe von Tags (:TAG) und eindeutigen Identifikationsnummern (@DIGEST), die es ermöglichen, eine bestimmte Version eines Images herunterzuladen

Eine lokale Kopie des docker/whalesay-Images erhalten Sie somit durch folgenden Befehl: 

docker pull docker/whalesay

In der Regel können Sie diesen Schritt jedoch überspringen

  • Möchten Sie einen Container starten, lädt der Docker-Daemon Images, die er auf dem lokalen System nicht finden kann, automatisch aus dem Repository herunter

Docker-Images als Container starten

Um ein Docker-Image zu starten, nutzen Sie den Befehl docker run nach folgendem Grundschema: 

docker run [OPTIONS] IMAGE [:TAG|@DIGEST] [CMD] [ARG…]

Einziger obligatorischer Bestandteil des Befehls docker run ist die Bezeichnung des gewünschten Docker-Images

  • Auch wenn Sie Container starten, haben Sie die Möglichkeit, fakultative Optionen, TAGs und DIGESTs zu definieren
  • Darüber hinaus lässt sich der Befehl docker run mit weiteren Befehlen kombinieren, die ausgeführt werden, sobald der Container startet
  • In diesem Fall wird der vom Image-Ersteller definierte CMD (COMMAND, ein Befehl, der beim Starten des Containers automatisch ausgeführt wird) überschrieben
  • Weitere optionale Konfigurationen lassen sich durch zusätzliche Argumente (ARG…) definieren
  • Diese ermöglichen es beispielweise, Benutzer hinzuzufügen oder Umgebungsvariablen (Environment-Variables) zu übergeben

Nutzen Sie den Kommandozeilenbefehl 

docker run docker/whalesay cowsay boo

um das als Image vorliegende Perl-Skript herunterzuladen und in einem Container auszuführen

  • Sie werden sehen, dass sich whalesay in einem wesentlichen Punkt vom Ursprungsskript unterscheidet
  • Wird *docker/whalesay* mit dem Standardbefehl ausgeführt, beschränkt sich der Docker-Wal auf ein kurzes *boo*

Wird das Image docker/whalesay ausgeführt, gibt das Skript eine ASCII-Grafik in Form eines Wals sowie die mit dem cowsay-Befehl übergebene Textnachricht „boo“ im Terminal aus

Wie beim Testlauf sucht der Daemon das gewünschte Image zunächst im lokalen Dateiverzeichnis

  • Da sich hier kein gleichnamiges Paket findet, wird ein Pulling aus dem Docker-Repository eingeleitet
  • Anschließend startet der Daemon das modifizierte Cowsay-Programm
  • Ist dieses durchgelaufen, wird der Container automatisch beendet

Wie cowsay bietet Ihnen auch Dockers whalesay die Möglichkeit, in den Programmablauf einzugreifen, um die Textausgabe im Terminal zu beeinflussen

  • Testen Sie diese Funktion, indem Sie das „boo“ im Ausgangsbefehl durch eine beliebige Zeichenfolge ersetzen – z. B. durch einen lahmen Wal-Witz.
sudo docker run docker/whalesay cowsay What did the shark say to the whale? What are you blubbering about?

Alle Docker-Images auf dem lokalen System anzeigen

Sind Sie sich nicht sicher, ob Sie ein bestimmtes Image bereits heruntergeladen haben, können Sie eine Übersicht aller Images auf Ihrem lokalen System aufrufen

  • Nutzen sie dazu folgenden Kommandozeilenbefehl:
sudo docker images

Der Befehl docker images (alternativ docker image ls) gibt Ihnen alle lokalen Images inklusive Dateigröße, Tag und Image-ID aus

Starten Sie einen Container, wird das zugrundeliegende Image als Kopie aus dem Repository heruntergeladen und dauerhaft auf Ihrem Computer gespeichert

  • So sparen Sie Zeit, falls Sie zu einem späteren Zeitpunkt erneut auf das betreffende Image zugreifen möchten
  • Ein erneuter Download wird nur dann eingeleitet, wenn sich die Image-Quelle verändert – beispielsweise, wenn im Repository eine aktuellere Version zur Verfügung steht

Docker-Images taggen und ins Docker-Hub hochladen

Möchten Sie Ihr selbsterstelltes Image docker-whale ins Hub laden, um es dort der Community oder einer Arbeitsgruppe zur Verfügung zu stellen, müssen Sie es zunächst mit einem gleichnamigen Repository in Ihrem persönlichen Namespace verknüpfen

  • In der Docker-Terminologie wird dieser Schritt Tagging genannt

Um ein Image über das Docker-Hub zu veröffentlichen, gehen Sie folgendermaßen vor:

1. Repository erstellen: Loggen Sie sich mit Ihrer Docker-ID und dem persönlichen Passwort im Docker-Hub ein und erstellen Sie ein öffentliches Repository mit dem Namen docker-whale

2. Image-ID ermitteln: Ermitteln Sie die ID Ihres selbsterstellten Images docker-whale mithilfe des Kommandozeilenbefehls docker images

  • Diese benötigen wir für das Tagging im nächsten Schritt.

3. Image taggen: Taggen Sie das Image docker-whale mithilfe des Kommandozeilenbefehls docker tag nach folgendem Schema: 

sudo docker tag [Image-ID][Docker-ID]/[Image-Name]:[TAG]

Auf das aktuelle Beispiel bezogen lautet der Kommandozeilenbefehl für das Tagging somit: 

sudo docker tag a8f2048c9ab8 [Namespace]/docker-whale:latest

Ob Ihr Image korrekt getaggt wurde, überprüfen Sie in der Übersicht via docker images

  • Der Name des Repositorys sollte nun Ihre Docker-ID beinhalten
  1. Image hochladen: Um das Image hochzuladen, müssen Sie sich zunächst im Docker-Hub anmelden
  • Dies erfolgt über den Kommandozeilenbefehl docker login


sudo docker login

Das Terminal fordert Sie auf, Ihren Benutzernahmen (die Docker-ID) sowie ihr Passwort einzugeben


War die Anmeldung erfolgreich, verwenden Sie den Kommandozeilenbefehl docker push, um Ihr Image in das neu erstellte Repository hochzuladen 

sudo docker push [Namespace]/docker-whale

Der Upload-Prozess sollte lediglich einige Sekunden in Anspruch nehmen

  • Der aktuelle Status wird Ihnen über das Terminal ausgegeben

Melden Sie sich über den Browser im Docker-Hub an, um sich das hochgeladene Image anzeigen zu lassen

Möchten Sie mehr als ein Image pro Repository hochladen, verwenden Sie verschiedene Tags, um Ihre Images in unterschiedlichen Versionen anzubieten

  • Beispielsweise:
[Namespace]/docker-whale:latest
[Namespace]/docker-whale:version1
[Namespace]/docker-whale:version2

Eine Übersicht verschiedener Image-Versionen lässt sich in Docker-Hub-Repositorys über den Reiter „Tags“ abrufen

Images verschiedener Projekte hingegen sollten in separaten Repositorys angeboten werden

War der Upload erfolgreich, steht Ihr selbsterstelltes Image nun jedem Docker-Nutzer weltweit über das öffentliche Repository zur Verfügung.

  • Testlauf: Testen Sie den Erfolg des Uploads, indem Sie das soeben hochgeladene Image herunterladen

Beachten Sie, dass Sie die lokale Version des Images zunächst löschen müssen, um eine neue Kopie mit demselben Tag herunterzuladen

  • Andernfalls meldet Docker, dass das gewünschte Image bereits in der aktuellen Version vorliegt

Um lokale Docker-Images zu löschen, nutzen Sie den Kommandozeilenbefehl docker rmi in Kombination mit der entsprechenden Image-ID

  • Diese ermitteln Sie wie gehabt via docker images. Meldet Docker Konflikte – z. B. weil eine Image-ID in mehreren Repositorys oder von einem Container verwendet wird –, bekräftigen Sie Ihren Befehl mit der Option --force (Kurz: -f), um den Löschvorgang zu erzwingen
sudo docker rmi -f a8f2048c9ab8

Lassen Sie sich erneut eine Übersicht aller lokalen Images anzeigen: 

sudo docker images

Die gelöschten Elemente sollten in der Terminal-Ausgabe nicht mehr auftauchen

  • Nutzen Sie nun den im Repository angegebenen Pull-Befehl, um eine neue Kopie des Images aus dem Docker-Hub herunterzuladen:
sudo docker pull [Namespace]/docker-whale

Anhang

Siehe auch

Dokumentation

Projekt

TMP

Images selbst definieren

FROM debian:stable-slim

ARG USERNAME=pandoc
ARG USER_UID=1000
ARG USER_GID=1000

RUN apt-get update && apt-get install -y --no-install-recommends \
apt-utils bash wget make graphviz biber \
texlive-base texlive-plain-generic texlive-latex-base \
#
&& groupadd --gid $USER_GID $USERNAME \
&& useradd -s /bin/bash --uid $USER_UID --gid $USER_GID -m $USERNAME \
#
&& apt-get autoremove -y && apt-get clean -y && rm -rf /var/lib/apt/lists/*

WORKDIR /pandoc
USER $USERNAME

docker build -t <NAME> -f <DOCKERFILE> .

FROM gibt die Basis an, d. h. hier ein Image von Debian in der Variante stable-slim, d. h. das ist der Basis-Layer für das zu bauende Docker-Image

Über ARG werden hier Variablen gesetzt

RUN ist der Befehl, der im Image (hier Debian) ausgeführt wird und einen neuen Layer hinzufügt

  • In diesen Layer werden alle Dateien eingefügt, die bei der Ausführung des Befehls erzeugt oder angelegt werden
  • Hier im Beispiel wird das Debian-Tool apt-get gestartet und weitere Debian-Pakete installiert

Da jeder RUN-Befehl einen neuen Layer anlegt, werden die restlichen Konfigurationen ebenfalls in diesem Lauf durchgeführt

  • Insbesondere wird ein nicht-Root-User angelegt, der von der UID und GID dem Default-User in Linux entspricht
  • Die gemounteten Dateien haben die selben Rechte wie auf dem Host, und durch die Übereinstimmung von UID/GID sind die Dateien problemlos zugreifbar und man muss nicht mit dem Root-User arbeiten (dies wird aus offensichtlichen Gründen als Anti-Pattern angesehen)
  • Bevor der RUN-Lauf abgeschlossen wird, werden alle temporären und später nicht benötigten Dateien von apt-get entfernt, damit diese nicht Bestandteil des Layers werden

Mit WORKDIR und USER wird das Arbeitsverzeichnis gesetzt und auf den angegebenen User umgeschaltet

  • Damit muss der User nicht mehr beim Aufruf von außen gesetzt werden

Über docker build -t <NAME> -f <DOCKERFILE> . wird aus dem angegebenen Dockerfile und dem Inhalt des aktuellen Ordners (".") ein neues Image erzeugt und mit dem angegebenen Namen benannt

Hinweis zum Umgang mit Containern und Updates

Bei der Erstellung eines Images sind bestimmte Softwareversionen Teil des Images geworden

  • Man kann prinzipiell in einem Container die Software aktualisieren, aber dies geht in dem Moment wieder verloren, wo der Container beendet und gelöscht wird
  • Außerdem widerspricht dies dem Gedanken, dass mehrere Personen mit dem selben Image/Container arbeiten und damit auch die selben Versionsstände haben
  • In der Praxis löscht man deshalb das alte Image einfach und erstellt ein neues, welches dann die aktualisierte Software enthält
Abgerufen von „https://wiki.foxtom.de/index.php?title=Docker/Image/Erstellung&oldid=157653“