Docker/Dockerfile

Docker/Dockerfile - Beschreibung

Beschreibung

Docker erstellt Images, indem es die Anweisungen aus einer Dockerfile liest.

• Eine Dockerfile ist eine Textdatei, die Anweisungen zum Erstellen von Quellcode enthält.

Anwendung

Einfaches Beispiel

Ziele

• Erstellen Sie ein Image und geben Sie dabei den Container-Port 3000 an.
• Führen Sie innerhalb des Containers die Webanwendungsdatei aus, indem Sie sie an node übergeben.

Dockerfile

FROM node:20-alpine
WORKDIR /app
COPY package*.json ./
RUN npm install --omit=dev
COPY . .
EXPOSE 3000
CMD ["node", "server.js"]

Beschreibung

1. Basisimage. Enthält Node.js 20 und das Minimalbetriebssystem Alpine Linux.
2. Erstellt das Verzeichnis /app zur Vereinfachung und macht es funktionsfähig. Alle folgenden Befehle werden darin ausgeführt.
3. Kopiert package.json und (falls vorhanden) package-lock.json aus dem Projekt in den Container. Diese Dateien beschreiben die Abhängigkeiten.
4. Der Paketmanager npm (anstelle dessen kann auch yarn verwendet werden) installiert nur die erforderlichen Abhängigkeiten, wodurch die Größe des Images gering gehalten werden kann.
5. Kopiert das gesamte Projekt nach /app
6. Dokumentiert, dass die Anwendung Port 3000 innerhalb des Containers überwacht. Dadurch wird der Port nicht nach außen geöffnet, sondern lediglich Docker und andere Tools informiert.
7. Legt den Befehl node src/index.js fest, der beim Start des Containers ausgeführt wird. Hier wird Node.js gestartet und die Hauptdatei der Anwendung src/index.js ausgeführt.

Erweiteres Beispiel

Ziele

Zusätzlich zu den vorherigen Zielen müssen wir hier Folgendes tun:

• Eine spezielle Zeitzone für den Container festlegen
• Das Containersystem sichern, indem wir die Anwendung im Namen eines nicht privilegierten Benutzers ausführen
• Eine Statusprüfung vor dem Start hinzufügen

Dockerfile

FROM node:20-alpine
WORKDIR /app
COPY package*.json ./
RUN npm install --omit=dev
COPY . .
ENV TZ=Europe/Berlin
RUN addgroup -S appgroup && adduser -S appuser -G appgroup
RUN mkdir -p /etc/todos
RUN chown -R appuser:appgroup /app && chown -R appuser:appgroup /etc/todos
USER appuser
EXPOSE 3000
HEALTHCHECK --interval=30s --timeout=3s CMD wget --no-verbose --tries=1 --spider http://localhost:3000/ || exit 1
CMD ["node", "src/index.js"]

Beschreibung

1. Basisimage
2. Erstellt das Verzeichnis /app
3. Kopieren von Abhängigkeitsdateien
4. Einstellung der Abhängigkeiten
5. Kopieren des Projekts in /app
6. Legt die Zeitzone Europe/Berlin für das System innerhalb des Containers fest. Nach dem Start kann dies mit dem Befehl docker exec <container-id> date überprüft werden.
7. Fügt die Gruppe appgroup hinzu. Fügt den Benutzer appuser zur Gruppe appgroup hinzu.
8. Erstellt vorab den Ordner /etc/todos. Dies ist erforderlich, um dem Benutzer appuser vorab die richtigen Rechte zuzuweisen.
9. Vergabe von Rechten an den Benutzer appuser für den Ordner /app, in dem sich die Anwendung befindet, und für den Ordner /etc/todos
10. Legt den Benutzer fest, unter dessen Namen die Anwendung als appuser ausgeführt wird.
11. Deklariert den Port der Anwendung als 3000.
12. Überprüfung der Funktionsfähigkeit der Anwendung. HEALTHCHECK führt zyklisch einen Befehl (CMD) aus und ermittelt anhand der Zeitüberschreitung oder des Exit-Codes, ob alles in Ordnung ist oder ein Fehler aufgetreten ist.

• In diesem Beispiel wird die Überprüfung alle 30 Sekunden gestartet. Das Zeitlimit für die Ausführung beträgt 3 Sekunden. Wenn der Befehl keine Antwort zurückgibt, wird er von Docker beendet und als Fehler gewertet.
• Der Befehl wget mit den Parametern --spider --no-verbose --tries=1 sendet eine HTTP-Anfrage, um Informationen über die Webseite zu erhalten, ohne sie herunterzuladen, Anzahl der Versuche: 1.
• Docker interpretiert jeden Code, der sich von 0 unterscheidet, als Fehler.

1. Führt die Hauptdatei der Anwendung index.js aus.

Komplexes Beispiel

Ziele

• FIXME Ziel dieser Dockerfile

Dockerfile

Beschreibung

1. FIXME Kurze Erklärung der Zeilen im Listing

Syntax

Parameter

Überblick

Instruction	Beschreibung
ADD	Lokale oder entfernte Dateien und Verzeichnisse hinzufügen.
ARG	Build-Zeit-Variablen verwenden.
CMD	Standardbefehle festlegen.
COPY	Dateien und Verzeichnisse kopieren.
ENTRYPOINT	Standardausführbares Programm festlegen.
ENV	Umgebungsvariablen setzen.
EXPOSE	Dokumentieren, auf welchen Ports die Anwendung lauscht.
FROM	Neue Build-Stufe von einem Basisimage erstellen.
HEALTHCHECK	Gesundheit eines Containers prüfen.
LABEL	Metadaten zum Image hinzufügen.
MAINTAINER	Autor eines Images angeben (veraltet).
ONBUILD	Anweisungen für die Verwendung des Images in nachfolgenden Builds angeben.
RUN	Build-Befehle ausführen.
SHELL	Standardshell des Images festlegen.
STOPSIGNAL	Systemaufruf-Signal zum Beenden eines Containers festlegen.
USER	Benutzer- und Gruppen-ID setzen.
VOLUME	Volume-Mounts anlegen.
WORKDIR	Arbeitsverzeichnis wechseln.

# Comment
INSTRUCTION arguments

• Die Anweisung ist nicht case-sensitiv.
• Es ist jedoch üblich, sie in GROSSBUCHSTABEN zu schreiben, damit sie leichter von den Argumenten zu unterscheiden sind.
• Die Dockerfile-Datei muss mit der Anweisung FROM beginnen.
• FROM darf nur von einer oder mehreren ARG-Anweisungen vorangestellt werden, die Argumente deklarieren, die in FROM-Zeilen im Dockerfile verwendet werden.

Kommentare

• BuildKit behandelt Zeichenfolgen, die mit # beginnen, als Kommentar, es sei denn, die Zeichenfolge ist eine zulässige Parser-Direktive.
• Kommentarzeilen werden vor der Ausführung der Anweisungen in der Dockerfile gelöscht. Der Kommentar im folgenden Beispiel wird vor der Ausführung des Befehls echo durch die Shell gelöscht.

RUN echo hello \
# comment
world

• Kommentare unterstützen keine Zeichen zur Fortsetzung einer Zeile.
• Aus Gründen der Abwärtskompatibilität werden führende Leerzeichen vor Kommentaren (#) und Anweisungen (z. B. RUN) ignoriert, sind jedoch nicht empfehlenswert.

Parser-Direktiven

Die folgenden Parser-Direktiven werden unterstützt:

• syntax
• escape
• check (ab Dockerfile v1.8.0)

• Parser-Direktiven-Schlüssel, wie z. B. syntax oder check, unterscheiden nicht zwischen Groß- und Kleinschreibung, werden jedoch gemäß Konvention in Kleinbuchstaben geschrieben.
• Werte für eine Direktive unterscheiden zwischen Groß- und Kleinschreibung und müssen in der für die Direktive geeigneten Schreibweise geschrieben werden.
• Die Parser-Direktiven müssen über den Anweisungen beschrieben werden.
• Leerzeichen, die die Direktivenzeile nicht unterbrechen, sind zulässig und werden nicht verarbeitet.

syntax

Verwenden Sie die syntax-Direktive, um die für den Build zu verwendende Dockerfile-Syntaxversion anzugeben.

• Wenn keine Angabe erfolgt, verwendet BuildKit eine gebündelte Version des Dockerfile-Frontends.
• Durch die Angabe einer Syntaxversion können Sie automatisch die neueste Dockerfile-Version verwenden, ohne BuildKit oder Docker Engine aktualisieren oder sogar eine benutzerdefinierte Dockerfile-Implementierung verwenden zu müssen.

In den meisten Fällen wird empfohlen, die Direktive docker/dockerfile:1 zu verwenden. In diesem Fall lädt BuildKit vor dem Build die neueste stabile Version von Dockerfile herunter.

# syntax=docker/dockerfile:1

escape

• Die Escape-Direktive legt das Zeichen fest, das zum Escapen von Zeichen in einer Dockerfile verwendet wird.
• Wenn nichts angegeben ist, ist das Standard-Escape-Zeichen \.
• Der Dockerfile-Parser verwendet die Maskierung nur für die Übertragung der Zeile am Ende der RUN-Zeile (um einen mehrzeiligen Befehl zu einem einzigen zusammenzufügen).
• Alles andere innerhalb von RUN wird nicht vom Dockerfile-Parser interpretiert, sondern von der Shell selbst (/bin/sh oder eine andere).

# escape=\

Or

# escape=`

• Das Ändern der Escape-Sequenz ist besonders nützlich, wenn Sie mit Windows-Pfaden in Dockerfile arbeiten.

check

• Die сheck-Direktive wird verwendet, um zu konfigurieren, wie Build-Prüfungen ausgewertet werden.
• Standardmäßig werden alle Prüfungen ausgeführt und Fehler als Warnungen behandelt.

Deaktivieren einzelner Prüfungen:

# check=skip=JSONArgsRecommended,StageNameCasing

Deaktivieren aller Prüfungen:

# check=skip=all

Standardmäßig werden Warnungen beim Kompilieren ignoriert.

Damit die Kompilierung bei Vorliegen von Warnungen mit einem Fehler beendet wird:

# check=error=true

Environment replacement

• Umgebungsvariablen werden mit dem Befehl ENV festgelegt.

• Sie werden in der Dockerfile mit $variable_name oder ${variable_name} gekennzeichnet.

Die Syntax ${variable_name} unterstützt auch einige der unten angegebenen Standard-Bash-Modifikatoren:

• ${variable:-word} gibt an, dass das Ergebnis diesem Wert entspricht, wenn die Variable gesetzt ist. Ist die Variable nicht gesetzt, ist Wort das Ergebnis.

• ${variable:+word} gibt an, dass Wort das Ergebnis ist, wenn die Variable gesetzt ist, andernfalls ist das Ergebnis eine leere Zeichenfolge.

...

Umgebungsvariablen werden durch die folgende Liste von Anweisungen in der Dockerfile unterstützt:

• ADD
• COPY
• ENV
• EXPOSE
• FROM
• LABEL
• STOPSIGNAL
• USER
• VOLUME
• WORKDIR
• ONBUILD

Es ist auch möglich, Umgebungsvariablen mit den Anweisungen RUN, CMD und ENTRYPOINT zu verwenden.

• In diesem Fall erfolgt die Variablenersetzung jedoch durch die Befehlszeilenshell und nicht durch den BuildKit-Compiler.

Zeichenschirmung

• Es besteht die Möglichkeit, ganze Variablennamen zu maskieren, indem man ein \ vor die Variable setzt: \$foo oder \${foo} werden beispielsweise in die Literale $foo bzw. ${foo} umgewandelt.

• Beispiel (die geparste Darstellung wird nach dem # angezeigt):

FROM busybox
ENV FOO=/bar
WORKDIR ${FOO}   # WORKDIR /bar
ADD . $FOO       # ADD . /bar
COPY \$FOO /quux # COPY $FOO /quux

Shell- und exec- Formen

Die Anweisungen RUN, CMD und ENTRYPOINT können beide in zwei Formen vorliegen:

• exec-Form

INSTRUCTION ["executable","param1","param2"]

• Shell-Form

INSTRUCTION command param1 param2

• Die exec-Form ermöglicht es, Shell-String-Munging zu vermeiden und Befehle mit einer bestimmten Befehlsshell oder einer anderen ausführbaren Datei aufzurufen. Sie verwendet eine JSON-Array-Syntax, wobei jedes Element im Array ein Befehl, ein Flag oder ein Argument ist.

• Die Shell-Form ist flexibler und legt Wert auf Benutzerfreundlichkeit, Flexibilität und Lesbarkeit. Die Shell-Form verwendet automatisch eine Befehlsshell, während dies bei der exec-Form nicht der Fall ist.

Verwenden Sie eine andere Shell.

Um die Standard-Shell zu ändern, können Sie den Befehl SHELL verwenden:

SHELL ["/bin/bash", "-c"]
RUN echo hello

Datei .dockerignore

Um Dateien und Verzeichnisse aus dem Build-Kontext auszuschließen, können Sie die Datei .dockerignore verwenden.

Aufruf

Optionen

Unix	GNU	Parameter	Beschreibung

Konfiguration

Dateien

Datei	Beschreibung

---