Softonic

Dockerfile-Generator

Schritt 1 / 2 Dockerfile
Ergebnisse

Ein Dockerfile gehört zu den Dateien, die kurz wirken, bis man an die Details denkt: Die Reihenfolge der Layer ist entscheidend für den Cache, COPY package.json gehört vor RUN npm install, und kompilierte Sprachen profitieren von einem Multi-Stage-Build. Dieser Generator schreibt ein einsatzbereites Dockerfile für den von Ihnen gewählten Stack, mit bereits korrektem Caching-Muster.

So generieren Sie ein Dockerfile

  1. 1

    Wählen Sie den Stack

    Node.js, Python, PHP, Go oder Rust. Jede Vorlage nutzt ein passendes Basis-Image für die Sprache und den korrekten Befehl zur Abhängigkeitsinstallation.

  2. 2

    Arbeitsverzeichnis und Port festlegen

    Wählen Sie das WORKDIR und den Port, auf dem Ihre App lauscht; beide werden in die Datei geschrieben.

  3. 3

    Das Dockerfile prüfen

    Achten Sie darauf, dass die EXPOSE-Zeile und der Startbefehl zu Ihrer App passen. Die Go- und Rust-Vorlagen verwenden einen Multi-Stage-Build.

  4. 4

    Das Dockerfile kopieren

    Kopieren Sie das Ergebnis und fügen Sie es in das Stammverzeichnis Ihres Repos ein, dann bauen Sie das Image.

Warum Multi-Stage-Builds

Ein naives Dockerfile installiert die gesamte Compiler-Toolchain in das finale Image. Multi-Stage-Builds geben Ihnen eine “Builder”-Stufe, die kompiliert, und eine finale Stufe, die nur das kompilierte Artefakt enthält:

FROM node:20-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build

FROM node:20-alpine
WORKDIR /app
COPY --from=builder /app/dist ./dist
COPY --from=builder /app/node_modules ./node_modules
USER node
EXPOSE 3000
CMD ["node", "dist/index.js"]

Das finale Image entfernt jede Entwicklungsabhängigkeit, Quelldatei und den Build-Cache, was die Image-Größe oft um 60-80 Prozent reduziert.

Varianten des Basis-Images

Die Vorlagen verwenden wo möglich Slim- oder Alpine-Images. Wenn Sie das Basis-Image selbst anpassen, sind dies die typischen Optionen:

Variante Typische Größe Wann man sie wählen sollte
full 300-900 MB Entwicklungs-Images, ungewöhnliche Systemabhängigkeiten
slim 80-200 MB Produktionsstandard für die meisten Sprachen
alpine 30-100 MB Kleine Images, Vorsicht bei glibc-vs-musl-Problemen
distroless 20-80 MB Maximale Sicherheit; keine Shell, kein Paketmanager

Regeln für das Layer-Caching

Docker cached jede Zeile; sobald sich ein Layer ändert, wird alles darunter neu gebaut. Reihenfolge vom am wenigsten bis zum am stärksten veränderlichen:

  1. FROM Basis-Image (ändert sich selten).
  2. Systempakete (apt-get install), seltene Änderungen.
  3. Abhängigkeitsmanifeste (package.json, requirements.txt, composer.json).
  4. Schritt zur Installation der Abhängigkeiten. Läuft nur, wenn sich das Manifest ändert.
  5. Kopieren des Quellcodes. Der am häufigsten geänderte Layer; alles danach wird bei jedem Commit neu gebaut.
  6. Kompilieren und finales CMD.

Diese Reihenfolge zu durchbrechen ist der häufigste Grund, warum CI-Builds langsam werden.

Sicherheitscheckliste

  • Als Nicht-Root ausführen. Setzen Sie USER appuser (oder USER 1000) gegen Ende.
  • Versionen festlegen. python:3.12.7-slim schlägt python:3.12 schlägt python:latest.
  • Setzen Sie explizites WORKDIR anstelle von /.
  • Verwenden Sie COPY nicht ADD für lokale Dateien; ADD hat Auto-Extraktionsnebenwirkungen.
  • Fügen Sie einen HEALTHCHECK hinzu, damit Orchestratoren einen festgefahrenen Prozess erkennen können.
  • Bereinigen Sie Paket-Caches in derselben RUN-Zeile: apt-get install ... && rm -rf /var/lib/apt/lists/*.

Häufig gestellte Fragen

Slim ist der sicherere Standard, da es weiterhin auf glibc basiert, wie die meisten vorkompilierten Wheels von Bibliotheken. Alpine verwendet musl und verursacht gelegentlich mysteriöse Laufzeitfehler in Python (pandas, numpy) oder Node (node-gyp-native-Module). Wählen Sie alpine, wenn die Image-Größe kritisch ist und Sie den Stack getestet haben.

Ja, legen Sie eine in Ihrem Projekt an. Ohne sie sendet Docker Ihr gesamtes Repository an den Daemon als Build-Kontext: Git-Historie, node_modules, lokale .env-Dateien, Tests. Das ist langsam, verschwendet Cache und leakt Geheimnisse.

Ja. Verwenden Sie docker buildx mit der Option --platform, um für beide Architekturen zugleich zu bauen. Die von den Vorlagen verwendeten Basis-Images veröffentlichen arm64-Varianten.

Nein. Stack-, Arbeitsverzeichnis- und Portwahl werden nur dazu verwendet, das Dockerfile auf dieser Seite zu erzeugen; nichts wird gespeichert oder geteilt.

Verwandte Tools

ASCII-Tabelle Referenz

Vollständige ASCII-Tabelle von 0 bis 127 mit Dezimal-, Hex-, Oktal-, Binär- und numerischer HTML-Zeichenreferenz für jedes Zeichen, einschließlich Steuerzeichen wie NUL, LF und DEL.

HTML-Zeichenreferenz

Durchsuchbare Liste von HTML-Entitäten, ihren benannten und numerischen Codes sowie eine Ein-Klick-Kopie für Sonderzeichen und Symbole.

Referenz für Tastenkombinationen

Durchsuchen Sie dokumentierte Standardkürzel für VS Code, Chrome und Bash mit GNU Readline unter macOS, Windows und Linux.

Zufallsbuchstaben-Generator

Erzeugen Sie zufällige A-Z-Buchstaben. Wählen Sie Anzahl, Großschreibung, Kleinschreibung oder gemischte Schreibweise für Spiele, Aufgaben und Unterricht.

Telefonnummern prüfen

Prüfen Sie die Struktur von Telefonnummern nach Land und zeigen Sie Region, Typ sowie E.164-, internationale, nationale und RFC-3966-Formate an.

Zufälliger Farbgenerator

Erzeuge 1 bis 50 zufällige HEX-Farben mit Farbfeldern zum Prüfen, Kopieren und Verwenden in CSS, Tests oder Palettenideen.

Tool in anderen Sprachen verfügbar