Dockerfile

Aus Zweites Gehirn, dem persönlichen Wiki
Dockerfile
TypKonzept
QuellenQuelle - Docker Bootcamp
Erstellt2026-09-27
Aktualisiert2026-09-27
Tagsdocker, container, devops, build

Ein Dockerfile ist eine Textdatei mit Anweisungen, aus der docker build ein eigenes Image baut: Basis-Image wählen, Pakete installieren, Dateien kopieren, Startbefehl festlegen. So wird die Einrichtung einer Anwendung als Code beschrieben, versioniert und jederzeit gleich wiederholbar.

Wozu

Lange docker run-Befehle werden unübersichtlich, ähnliche Container braucht man immer wieder, und manches (Software nachinstallieren und konfigurieren) lässt sich mit der Kommandozeile allein nicht automatisieren. Die Lösung: die Konfiguration in ein Dockerfile schreiben und mit docker build ein massgeschneidertes Image bauen (Quelle - Docker Bootcamp, Folie 150).

Syntax

  • Jede Zeile hat die Form ANWEISUNG Parameter. Anweisungen schreibt man nach Konvention gross, sie sind aber nicht case-sensitiv.
  • Kommentare beginnen mit # am Zeilenanfang.
  • Die Datei heisst standardmässig Dockerfile, ohne Endung (Folie 151).

Die wichtigsten Anweisungen

Anweisung Zweck
FROM image:tag Basis-Image, muss die erste Anweisung sein. Meist ein offizielles Image, oft Alpine oder Debian. Das Ur-Image heisst scratch („from scratch“) (Folie 157)
RUN befehl Befehl beim Bauen ausführen, meist Pakete installieren. Jede RUN-Zeile erzeugt eine Schicht, darum Befehle mit && bündeln: RUN apt-get update && apt-get install -y paket (Folie 159)
COPY quelle ziel lokale Dateien ins Image kopieren, im Regelfall verwenden (Folie 161)
ADD quelle ziel wie COPY, kann zusätzlich URLs laden und Archive entpacken. Nur fürs Entpacken nehmen, für Downloads besser curl/wget in RUN
CMD ["programm", "arg"] Standardbefehl beim Start. Exec-Form (empfohlen) startet das Programm direkt, Shell-Form löst Platzhalter und Variablen auf. Nur das letzte CMD gilt (Folie 163)
ENTRYPOINT [...] fester Hauptbefehl, Argumente von docker run werden angehängt. Macht den Container zu einem „ausführbaren Programm“ (service-based image). Mit CMD kombiniert liefert CMD die Standardargumente (Folien 165–166)
WORKDIR /pfad Arbeitsverzeichnis setzen, statt RUN cd (Folie 168)
ARG name=wert Variable nur für die Bauphase, setzbar mit docker build --build-arg (Folie 170)
ENV name=wert Umgebungsvariable für Bau und Laufzeit, beim Start mit -e überschreibbar
EXPOSE 80/tcp dokumentiert, auf welchem Port der Container lauscht. Öffnet nichts, wird nur von docker run -P genutzt (Folie 174)
VOLUME /pfad legt fest, dass dort ein Volume entsteht, z.B. damit eine Datenbank ihre Daten nie im Container speichert (Folie 172)
LABEL schlüssel=wert Metadaten, sichtbar mit docker image inspect (Folie 183)

Faustregel CMD vs. ENTRYPOINT: CMD grundsätzlich bevorzugen, ENTRYPOINT nur für Images, die wie ein Programm aufgerufen werden (Folie 166). Übungsbeispiel: ein Image, das immer vim startet (ENTRYPOINT) und eine Datei öffnet, deren Name per CMD vorgegeben und beim Start änderbar ist (Folie 179).

docker build

docker build .                      # Dockerfile im aktuellen Verzeichnis
docker build -f mydockerfile .      # anderer Dateiname
docker build -t meine-app:1.0 .     # Image gleich mit Tag versehen
  • Der übergebene Pfad ist der Build-Kontext: alle Dateien, auf die der Build zugreifen kann. Darum das Dockerfile in einen eigenen Ordner legen, der nur das Nötige enthält, und nie docker build auf das Wurzelverzeichnis ausführen (Folie 154).
  • .dockerignore schliesst Dateien aus dem Kontext aus, mit Mustern wie data*, *data, **/data (Folie 185).
  • Ablauf: Zuerst wird das ganze Dockerfile auf Syntaxfehler geprüft, dann werden die Anweisungen der Reihe nach ausgeführt. Unveränderte Schritte kommen aus dem Build-Cache („CACHED“) (Folie 155).

Multi-Stage-Builds

Images werden oft unnötig gross, weil sie Werkzeuge wie einen Compiler enthalten, die zur Laufzeit niemand braucht. Lösung: mehrere FROM in einem Dockerfile. Eine erste Stufe baut die Anwendung, die letzte kopiert nur das Ergebnis in ein kleines Image (Folien 196–197):

FROM golang:1.15.1-alpine AS builder
# ... Anwendung kompilieren ...
FROM alpine
COPY --from=builder /pfad/im/builder /pfad/im/ziel

Alpine Linux und musl

Alpine ist eine wenige Megabyte kleine Linux-Distribution und beliebt als Basis-Image. Sie verwendet apk statt apt und die C-Standardbibliothek musl statt glibc (Folien 190–194). Das hat Folgen:

  • Code ist oft auf glibc abgestimmt, Programme können sich unter musl anders verhalten (Beispiel: strftime in Python).
  • Fertig kompilierte Python-Pakete (Wheels) gibt es oft nur für glibc. Unter Alpine muss z.B. pip install pandas den Code erst selbst kompilieren, unter Ubuntu nicht.
Sicherheitshinweis aus der Quelle

Werte aus ENV und ARG bleiben im Image sichtbar, etwa mit docker image history. Passwörter und andere Geheimnisse gehören deshalb nicht dorthin, vor allem nicht, wenn das Image weitergegeben wird (Folie 176). Für Geheimnisse gibt es Secrets (siehe Container-Orchestrierung).

Beispiel

Einordnung (Claude)

Die Folien zeigen das Dockerfile der Kurs-Flask-App nicht als Text. Ein typisches Dockerfile nach den Regeln oben könnte so aussehen (Beispiel von Claude, nicht aus der Quelle):

FROM python:3.12-slim
WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
COPY . .
EXPOSE 5000
CMD ["python", "app.py"]

Die Abhängigkeiten werden vor dem restlichen Code kopiert, damit Docker die teure pip install-Schicht aus dem Cache nehmen kann, solange sich nur der Code ändert. Die Kursbeispiele nutzen alte Versionen (z.B. golang:1.15.1), die heute nicht mehr gepflegt werden.

Verwandt

  • Container – was aus dem Image entsteht
  • Docker Compose – kann Images direkt aus Dockerfiles bauen (build:)
  • Docker – docker build und Docker Hub
  • Softwaretest – reproduzierbare Umgebungen auch für Tests
  • Angular CLI – anderes Werkzeug, das Projekte reproduzierbar baut

Links auf diese Seite

Kategorien: docker | container | devops | build