Dockerfile Unterstützung für GitHub Aktionen

Informationen zu Dockerfile-Anweisungen

Ein Dockerfile enthält Anweisungen und Argumente, die den Inhalt und das Startverhalten eines Docker-Containers definieren. Weitere Informationen zu den Anweisungen findest Du unter "Dockerfile-Referenz" in der Docker-Dokumentation.

Dockerfile Anweisungen und Overrides (Überschreibungen)

Einige Docker-Anweisungen interagieren mit GitHub-Aktionen, und die Metadaten-Datei einer Aktion kann einige Docker-Anweisungen überschreiben. Vergewissere Dich, dass Dir klar ist, wie Dein Dockerfile mit GitHub Actions interagiert, um unerwartetes Verhalten zu verhindern.

USER

Docker-Aktionen müssen vom Standard-Benutzer (root) des Dockers ausgeführt werden. Verwende nicht die USER Anweisung in Deinem Dockerfile, weil Du nicht auf den GITHUB_WORKSPACE zugreifen kannst. Weitere Informationen findest Du unter "Umgebungsvariablen" und USER-Referenz in der Docker-Dokumentation.

FROM

Die erste Anweisung im Dockerfile muss FROM sein. Sie wählt das Docker-Basisabbild aus. Weitere Informationen findest Du unter FROM-Referenz in der Docker-Dokumentation.

Dies sind einige bewährte Methoden, das Argument FROM zu setzen:

• Es wird empfohlen, offizielle Docker-Images (Abbilder) zu verwenden. Zum Beispiel python oder ruby.
• Verwende ein Versions-Tag, falls vorhanden, vorzugsweise mit einer Hauptversion. Verwende beispielsweise node:10 anstelle von node:latest.
• Es wird empfohlen, Docker-Images basierend auf dem Betriebssystem Debian zu verwenden.

WORKDIR

GitHub Enterprise Server setzt den Pfad zum Arbeitsverzeichnis in der GITHUB_WORKSPACE Umgebungsvariable. Es wird empfohlen, die WORKDIR Anweisung in Ihrem Dockerfile zu vermeiden. Bevor die Aktion ausgeführt wird, mountet GitHub Enterprise Server das Verzeichnis GITHUB_WORKSPACE auf was auch immer sich an dieser Stelle im Docker-Image befindet, und setzt GITHUB_WORKSPACE als Arbeitsverzeichnis. Weitere Informationen findest Du unter "Umgebungsvariablen verwenden" und WORKDIR-Referenz in der Docker-Dokumentation.

ENTRYPOINT

Wenn Du Einstiegspunkt in der Metadaten-Datei einer Aktion definierst, wird der ENTRYPOINT im Dockerfile überschrieben. Weitere Informationen findest Du unter „Metadaten-Syntax für GitHub Actions“.

Für die Docker-Anweisung ENTRYPOINT gibt es sowohl eine shell-Form als auch eine exec-Form. Die Docker-Dokumentation für ENTRYPOINT empfiehlt die exec-Form der ENTRYPOINT-Anweisung. Weitere Informationen über exec- und shell-Form findest Du unter ENTRYPOINT-Referenz in der Docker-Dokumentation.

Wenn Du Deinen Container so konfigurierst, dass er die exec-Form der Anweisung ENTRYPOINT verwendet, können die in der Metadaten-Datei der Aktion konfigurierten args (Argumente) nicht in einer Kommando-Shell genutzt werden. Wenn die Args der Aktion eine Umgebungsvariable enthalten, wird die Variable nicht ersetzt. Wenn Du zum Beispiel das folgende exec-Format verwendest, wird nicht der in $GITHUB_SHA gespeicherte Wert ausgegeben, sondern stattdessen „$GITHUB_SHA“.

ENTRYPOINT ["echo $GITHUB_SHA"]

Wenn Du Variablensubstitution willst, verwende entweder die Shell-Form oder führe direkt eine Shell aus. Zum Beispiel kannst Du mit dem folgenden exec-Format eine Shell ausführen, um den Wert auszugeben, der in der Umgebungsvariable GITHUB_SHA gespeichert ist.

ENTRYPOINT ["sh", "-c", "echo $GITHUB_SHA"]

Um args aus der Metadaten-Datei der Aktion an einen Docker Container zu übergeben, der die exec-Form im ENTRYPOINT verwendet, empfehlen wir, ein Shell-Skript namens entrypoint.sh zu erstellen und dieses von der ENTRYPOINT-Anweisung aus anrufen:

Beispiel Dockerfile

# Container image that runs your code
FROM debian:9.5-slim

# Copies your code file from your action repository to the filesystem path `/` of the container
COPY entrypoint.sh /entrypoint.sh

# Executes `entrypoint.sh` when the Docker container starts up
ENTRYPOINT ["/entrypoint.sh"]

Beispiel für die Datei entrypoint.sh

Mit dem obigen Dockerfile-Beispiel sendet GitHub Enterprise Server die Metadaten-Datei der Aktion konfigurierten args als Argumente an entrypoint.sh. Füge #!/bin/sh shebang oben in die Datei entrypoint.sh ein, um explizit die POSIX-konforme Shell des Systems zu verwenden.

#!/bin/sh

# `$*` expands the `args` supplied in an `array` individually
# or splits `args` in a string separated by whitespace.
sh -c "echo $*"

Dein Code muss ausführbar sein. Stelle sicher, dass die Datei entrypoint.sh die Berechtigunge execute hat, bevor Du sie in einem Workflow verwendest. Du kannst die Berechtigung von Deinem Terminal aus mit diesem Befehl ändern:

chmod +x entrypoint.sh

Wenn ein ENTRYPOINT-Shell-Skript nicht ausführbar ist, erhältst Du einen Fehler, der ungefähr so aussieht:

Error response from daemon: OCI runtime create failed: container_linux.go:348: starting container process caused "exec: \"/entrypoint.sh\": permission denied": unknown

CMD

Wenn Du in der Metadaten-Datei der Aktion args definierst, dann überschreibt args die Anweisung CMD, welche im Dockerfile angegeben wurde. Weitere Informationen findest Du unter „Metadaten-Syntax für GitHub Actions“.

Falls Du CMD in Deinem Dockerfile verwendest, solltest Du Dich an diese Richtlinien halten:

1. Dokumentiere die erforderlichen Argumente in der README der Aktion und lasse sie in der CMD-Anweisung weg.
2. Verwenden Sie Standardwerte, die die Verwendung der Aktion ohne Angabe von args erlauben.
3. Wenn die Aktion ein --help Flag oder etwas ähnliches verfügbar macht, verwende dieses, um Deine Aktion selbstdokumentierend zu machen.

Unterstützte Linux-Funktionen

GitHub Actions unterstützt die standardmäßigen Linux-Funktionen, die auch Docker unterstützt. Funktionen können weder hinzugefügt noch entfernt werden. Weitere Informationen über die standardmäßigen Linux-Funktionen, die Docker unterstützt, findest Du unter "Laufzeit-Privilegien und Linux-Funktionen" in der Docker-Dokumentation. Weitere Informationen zu Linux-Funktionen findest Du unter "Überblick über die Linux-Funktionen" in den Linux-Man-Pages.