Ein Image mit Cache-Kontrolle und sicherem Umgang mit Secrets erstellen
In diesem Schritt lernen Sie, wie Sie den Docker-Build-Cache kontrollieren und mit Secrets während des Build-Prozesses umgehen können, indem Sie den secret-Mount-Typ von BuildKit verwenden. Der Build-Cache kann Builds deutlich beschleunigen, aber manchmal müssen Sie ihn deaktivieren. Der sichere Umgang mit Secrets ist entscheidend, um sensible Informationen nicht in Ihren Image-Layern einzubetten.
Stellen Sie zunächst sicher, dass Sie sich im Verzeichnis ~/project befinden:
cd ~/project
Passen wir die Dockerfile an, um einen Schritt einzufügen, für den wir die Cache-Kontrolle demonstrieren wollen, sowie einen Platzhalter für die Verwendung eines Secrets.
Öffnen Sie die Dockerfile zur Bearbeitung:
nano Dockerfile
Ändern Sie den Inhalt, um einen RUN-Befehl hinzuzufügen, der eine Datei mit einem Zeitstempel erstellt, sowie einen Platzhalter für die Verwendung eines Secrets:
FROM ubuntu:latest
ARG MESSAGE="Hello, Docker!"
RUN apt-get update && apt-get install -y cowsay
LABEL maintainer="Your Name <[email protected]>"
RUN echo "Build time: $(date)" > /app/build_info.txt
## Dies ist ein Platzhalter für einen Befehl, der ein Secret verwenden würde
## RUN --mount=type=secret,id=mysecret cat /run/secrets/mysecret > /app/secret_info.txt
CMD ["cowsay", "$MESSAGE"]
Wir haben RUN echo "Build time: $(date)" > /app/build_info.txt hinzugefügt. Dieser Befehl erstellt eine Datei /app/build_info.txt mit dem Zeitstempel, wann dieses Layer gebaut wurde. Standardmäßig cached Docker Layers. Wenn Sie das Image mehrmals bauen, ohne die Anweisungen vor diesem RUN-Befehl zu ändern, könnte dieses Layer aus dem Cache kommen, und der Zeitstempel würde sich nicht aktualisieren.
Speichern Sie die geänderte Dockerfile mit Strg + X, dann Y und Enter.
Nun bauen wir das Image mit einem neuen Tag, my-cached-image:
docker build -t my-cached-image .
Beobachten Sie die Ausgabe. Wenn Sie das Image kürzlich gebaut haben, sehen Sie möglicherweise ---> Using cache für einige Schritte.
Um die Cache-Kontrolle zu demonstrieren, bauen wir das Image erneut, diesmal deaktivieren wir den Cache für den gesamten Build mit dem --no-cache-Flag:
docker build --no-cache -t my-no-cache-image .
Sie werden sehen, dass Docker jedes Layer neu baut, selbst wenn sich die Anweisungen nicht geändert haben. Dies ist nützlich, wenn Sie sicherstellen wollen, dass alle Abhängigkeiten frisch bezogen werden oder wenn ein vorheriger Build den Cache beschädigt hat.
Nun zum Umgang mit Secrets. Die auskommentierte Zeile ## RUN --mount=type=secret,id=mysecret cat /run/secrets/mysecret > /app/secret_info.txt zeigt, wie Sie ein Secret mit BuildKit verwenden würden. Um dies zu nutzen, müssten Sie BuildKit aktivieren (was in neueren Docker-Versionen oft standardmäßig aktiviert ist) und das Secret während des Builds mit dem --secret-Flag bereitstellen.
Zum Beispiel, wenn Sie eine Datei namens mysecret.txt mit Ihrem Secret hätten, würden Sie so bauen (dieser Befehl funktioniert nicht direkt, da wir keine mysecret.txt-Datei haben und die Zeile auskommentiert ist, aber er zeigt die Syntax):
## docker build --secret id=mysecret,src=mysecret.txt -t my-secret-image .
Die Anweisung RUN --mount=type=secret,id=mysecret macht den Inhalt des Secrets nur während des Build-Schritts unter /run/secrets/mysecret verfügbar. Das Secret wird nicht in den finalen Image-Layern gespeichert. Dies ist die sichere Methode, um sensible Informationen wie API-Keys oder Passwörter während des Builds zu handhaben.
Da wir keine Secret-Datei haben und die Zeile auskommentiert ist, werden wir den Secret-bezogenen Build-Befehl nicht ausführen. Dennoch ist das Verständnis von --no-cache und dem secret-Mount-Typ wichtig, um Ihre Builds zu kontrollieren und sensible Daten sicher zu handhaben.
