Zum Inhalt springen

Docker/Dockerfile: Unterschied zwischen den Versionen

Aus Foxwiki
Zeile 8: Zeile 8:


== Anwendung ==
== Anwendung ==
=== Einfaches Beispiel ===
<syntaxhighlight lang="bash" highlight="1" line copy>
</syntaxhighlight>
=== Erweiteres Beispiel ===
<syntaxhighlight lang="bash" highlight="1" line copy>
</syntaxhighlight>
=== Komplexes Beispiel ===
<syntaxhighlight lang="bash" highlight="1" line copy>
<syntaxhighlight lang="bash" highlight="1" line copy>
</syntaxhighlight>
</syntaxhighlight>

Version vom 6. November 2025, 13:51 Uhr

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

Erweiteres Beispiel

Komplexes Beispiel

Problembehebung

Syntax

# 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

FROM

RUN

CMD

LABEL

EXPOSE

ENV

ADD

COPY

ENTRYPOINT

VOLUME

USER

WORKDIR

ARG

ONBUILD

STOPSIGNAL

HEALTHCHECK

SHELL

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

Parameter

Instruction Description

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.


Konfiguration

Dateien

Datei Beschreibung


Anhang

Siehe auch



Dokumentation

Links

Projekt

Weblinks