Die meisten Anfänger tippen los und wundern sich über langsame Builds. Dabei ist ein Dockerfile ein Rezept mit fester Anweisungsreihenfolge.
Ein Dockerfile beschreibt Schritt für Schritt, wie ein Container-Image entsteht. Das Image ist die unveränderliche Vorlage, aus der Container gestartet werden.
Zuerst steht die FROM-Anweisung: Sie legt ein Basis-Image fest, etwa eine schlanke Linux-Distribution mit Python. Jede Anweisung erzeugt dabei eine Schicht, und die Reihenfolge entscheidet über den Build-Cache. Selten geänderte Schritte wie Abhängigkeiten gehören deshalb vor häufig geänderten wie dem Quellcode.
Dann folgt COPY. Es kopiert Dateien aus dem Build-Kontext in das Image, also aus dem Verzeichnis, das dem Build mitgegeben wird. Ein häufiger Irrtum: Dateien außerhalb dieses Kontexts sind schlicht nicht verfügbar. Bewährt hat sich, zuerst nur die Datei mit den Abhängigkeiten zu kopieren und zu installieren, dann erst den Quellcode.
Danach kommen RUN für Installationsbefehle sowie USER. Ohne USER läuft der Prozess im Container als root, also mit vollen Rechten. Die Anweisung USER setzt einen unprivilegierten Benutzer und senkt das Risiko, falls der Container kompromittiert wird.
Zuletzt legen CMD den Startbefehl und EXPOSE den Port fest. EXPOSE dokumentiert nur, welchen Port die Anwendung im Container erreicht; geöffnet wird er erst beim Start mit docker run. Der Befehl docker build arbeitet das Dockerfile ab und erzeugt das Image, versehen mit einem Tag wie 1.2. Solche Tags sind beweglich; ein Digest wie sha256:… identifiziert dagegen genau einen Inhalt.
Ein Dockerfile ist also kein Skript, sondern ein Rezept: Jede Anweisung baut eine Schicht, und deren Reihenfolge bestimmt Tempo und Sicherheit des Images.
📌 Schichten und Build-Cache · COPY und Build-Kontext · USER statt root
📚 Cloud von Grund auf · Tag 3 von 30
#docker #devops #CloudSecurity
Ein Dockerfile beschreibt Schritt für Schritt, wie ein Container-Image entsteht. Das Image ist die unveränderliche Vorlage, aus der Container gestartet werden.
Zuerst steht die FROM-Anweisung: Sie legt ein Basis-Image fest, etwa eine schlanke Linux-Distribution mit Python. Jede Anweisung erzeugt dabei eine Schicht, und die Reihenfolge entscheidet über den Build-Cache. Selten geänderte Schritte wie Abhängigkeiten gehören deshalb vor häufig geänderten wie dem Quellcode.
Dann folgt COPY. Es kopiert Dateien aus dem Build-Kontext in das Image, also aus dem Verzeichnis, das dem Build mitgegeben wird. Ein häufiger Irrtum: Dateien außerhalb dieses Kontexts sind schlicht nicht verfügbar. Bewährt hat sich, zuerst nur die Datei mit den Abhängigkeiten zu kopieren und zu installieren, dann erst den Quellcode.
Danach kommen RUN für Installationsbefehle sowie USER. Ohne USER läuft der Prozess im Container als root, also mit vollen Rechten. Die Anweisung USER setzt einen unprivilegierten Benutzer und senkt das Risiko, falls der Container kompromittiert wird.
Zuletzt legen CMD den Startbefehl und EXPOSE den Port fest. EXPOSE dokumentiert nur, welchen Port die Anwendung im Container erreicht; geöffnet wird er erst beim Start mit docker run. Der Befehl docker build arbeitet das Dockerfile ab und erzeugt das Image, versehen mit einem Tag wie 1.2. Solche Tags sind beweglich; ein Digest wie sha256:… identifiziert dagegen genau einen Inhalt.
Ein Dockerfile ist also kein Skript, sondern ein Rezept: Jede Anweisung baut eine Schicht, und deren Reihenfolge bestimmt Tempo und Sicherheit des Images.
📌 Schichten und Build-Cache · COPY und Build-Kontext · USER statt root
📚 Cloud von Grund auf · Tag 3 von 30
#docker #devops #CloudSecurity
2 Tage vor
