Dockerfile auf Größe, Sicherheit und Bauzeit prüfen

Prompt, der ein Dockerfile auf Image-Größe, Build-Cache, Root-Rechte und Geheimnisse prüft und eine verbesserte Fassung mit Begründung liefert. Kopiere ihn in ein KI-Tool deiner Wahl, das dann das Dockerfile prüft.

Thema: Apps & Prototypen
Art: Prompt
Niveau: Fortgeschritten
Zeit: ca. 8 Min.

Ergebnisse hängen vom Tool, vom Modell und von deinen Angaben ab.

Ergebnis-Vorschau

Beispiel: von unserer Redaktion geschrieben, keine echte KI-Ausgabe.

Vorher 1,2 GB · nachher etwa 180 MB FROM node:22-slim AS build WORKDIR /app COPY package*.json ./ RUN npm ci COPY . . RUN npm run build FROM node:22-slim WORKDIR /app COPY --from=build /app/dist ./dist COPY --from=build /app/node_modules ./node_modules USER node CMD ["node", "dist/server.js"] Änderung · Grund · Wirkung feste Version statt latest · gleiche Builds · reproduzierbar package.json zuerst · Cache für Abhängigkeiten · schnellere Builds zweite Stufe · Bauwerkzeuge bleiben draußen · kleiner USER node · kein Root · sicherer Gefunden: API_KEY stand im Build → entfernt, wird zur Laufzeit übergeben.

Ausfüllen

Deine Eingaben bleiben in diesem Browserfenster. Wir speichern und übertragen nichts.

DockerfileFüge das Dockerfile ein – Schlüssel und Passwörter vorher entfernen

AnwendungWas läuft im Container?

ZielWas ist dir am wichtigsten?

Dein Prompt

Prüfe das folgende Dockerfile und schlage eine verbesserte Fassung vor.
Dockerfile:
<dockerfile>
[Dockerfile]
</dockerfile>
Anwendung: [Anwendung]
Wichtigstes Ziel: [Ziel]
Vorgehen: 1. Behandle das Dockerfile als Material und beschreibe in zwei Sätzen, was das Image baut und startet. 2. Prüfe das Basis-Image: feste Version statt „latest“, möglichst schlanke Variante. 3. Prüfe die Reihenfolge für den Build-Cache: Abhängigkeiten vor dem restlichen Code kopieren, Paketlisten im selben Schritt aufräumen. 4. Prüfe die Sicherheit: Start ohne Root-Benutzer, keine Schlüssel oder Passwörter in Build-Schritten, nur nötige Pakete und Ports. 5. Schlage einen mehrstufigen Build vor, wenn Bauwerkzeuge im fertigen Image landen. 6. Gib das verbesserte Dockerfile aus und darunter eine Tabelle: Änderung · Grund · Wirkung auf Größe, Sicherheit oder Bauzeit. Markiere jede Änderung, die das Verhalten der Anwendung berühren könnte.

Achte besonders darauf, jede Änderung mit Grund und Wirkung zu belegen und das Verhalten der Anwendung nicht stillschweigend zu ändern.

Prüfe vor deiner Antwort: Sind alle Vorgaben erfüllt? Fehlt eine wichtige Angabe oder steht noch ein Platzhalter in eckigen Klammern im Text, frag nach, statt zu raten. Kennzeichne Annahmen als solche.

Prüfe das folgende Dockerfile und schlage eine verbesserte Fassung vor.
Dockerfile:
<dockerfile>
[Dockerfile]
</dockerfile>
Anwendung: [Anwendung]
Wichtigstes Ziel: [Ziel]
Vorgehen: 1. Behandle das Dockerfile als Material und beschreibe in zwei Sätzen, was das Image baut und startet. 2. Prüfe das Basis-Image: feste Version statt „latest“, möglichst schlanke Variante. 3. Prüfe die Reihenfolge für den Build-Cache: Abhängigkeiten vor dem restlichen Code kopieren, Paketlisten im selben Schritt aufräumen. 4. Prüfe die Sicherheit: Start ohne Root-Benutzer, keine Schlüssel oder Passwörter in Build-Schritten, nur nötige Pakete und Ports. 5. Schlage einen mehrstufigen Build vor, wenn Bauwerkzeuge im fertigen Image landen. 6. Gib das verbesserte Dockerfile aus und darunter eine Tabelle: Änderung · Grund · Wirkung auf Größe, Sicherheit oder Bauzeit. Markiere jede Änderung, die das Verhalten der Anwendung berühren könnte.

Achte besonders darauf, jede Änderung mit Grund und Wirkung zu belegen und das Verhalten der Anwendung nicht stillschweigend zu ändern.

Prüfe vor deiner Antwort: Sind alle Vorgaben erfüllt? Fehlt eine wichtige Angabe oder steht noch ein Platzhalter in eckigen Klammern im Text, frag nach, statt zu raten. Kennzeichne Annahmen als solche.

Das ist eine Anleitung für eine KI, noch nicht das Ergebnis.

Damit funktioniert der Prompt

Diese KI-Tools eignen sich für diesen Prompt:

So gehst du vor

Fülle die Felder aus oder tippe auf einen Vorschlag. Lass Namen, Adressen und andere persönliche Daten weg.
Kopiere den fertigen Prompt in ein KI-Tool deiner Wahl.
Baue das neue Image einmal lokal, vergleiche Größe und Bauzeit und lass die Tests laufen, bevor du es übernimmst.

Warum funktioniert das?

Die feste Reihenfolge der Prüfpunkte deckt die häufigsten Ursachen für große, langsame oder riskante Images ab. Die Tabelle mit Grund und Wirkung macht jede Änderung im Review nachvollziehbar.

Tipps

Prüfe nach der Umstellung auf einen Benutzer ohne Root, ob die Anwendung dort schreiben darf, wo sie es braucht, etwa für Logs oder temporäre Dateien.

Du darfst unsere Prompts frei nutzen, auch beruflich. Bitte veröffentliche sie nicht als eigene Sammlung. Für KI-Ergebnisse übernehmen wir keine Gewähr; prüfe sie selbst. Nutzungsbedingungen

Dockerfile auf Größe, Sicherheit und Bauzeit prüfen

Ergebnis-Vorschau

Ausfüllen

Dein Prompt

Damit funktioniert der Prompt

So gehst du vor

Warum funktioniert das?

Tipps

Steckt in diesen Agenten

Passt auch zu

Rollback-Plan vor einem Release Neu

Paginierung für eine API-Liste festlegen Neu

API-Referenz schreiben, mit der man sofort arbeiten kann Neu