01
Die Stufenansicht öffnen
Das Beispiel trennt Build und Laufzeit. Die Nummerierung beginnt bei null. Ein Klick auf eine Stufe springt zur FROM-Zeile; aufgeklappte Anweisungen zeigen Originaltext und Bedeutung.
Docker / Container
Dockerfile formatieren
Stufengrenzen prüfen, Diagnosen im Quelltext finden und Einzüge erst nach der Vorschau übernehmen.
Dockerfile formatieren
Dockerfile-Quelltext
Ergebnis
Verarbeitung im Browserspeicher, ohne Build- oder Registry-Anfragen.
Ergebnis veraltet. Vor dem Export erneut prüfen.
Dockerfile formatieren wird besonders dann hilfreich, wenn ein langer Multi-Stage-Build beim Review unübersichtlich wird. Die ursprünglichen Zeilen bleiben erhalten, während Sie die Stufen einzeln aufsuchen.
Mit dem Dockerfile-Formatter können Sie einen Dockerfile prüfen und Fortsetzungszeilen ordnen. Der integrierte Dockerfile-Linter meldet unterstützte statische Probleme; er bewertet weder die Größe noch die Sicherheit eines Images.
Dockerfile formatieren mit prüfbaren Änderungen
Von der Stufe zur Deklaration
Dockerfile formatieren und dabei die Struktur sehen: Jede FROM-Anweisung erzeugt einen Eintrag mit Image, optionalem Namen und Position. Auch unbenannte Stufen bleiben erreichbar.
Einzüge vor dem Anwenden vergleichen
Die Vorschau steht getrennt von der Eingabe. Kontrollieren Sie die Zahl geänderter Zeilen und übernehmen Sie den Text bewusst. Einmaliges Rückgängigmachen stellt Eingabe und vorheriges Ergebnis gemeinsam wieder her.
Stufen und Änderungen gezielt prüfen
02
Den Prüfzeitpunkt wählen
Die automatische Prüfung wartet nach Eingaben 350 ms. Ausschalten verwirft wartende Aufgaben. Im manuellen Modus prüfen Sie per Schaltfläche oder Ctrl/Cmd + Enter. Alte Ergebnisse lassen sich nach Änderungen nicht exportieren.
03
Den passenden Einzug festlegen
Fortsetzungen verwenden standardmäßig vier Leerzeichen; zwei Leerzeichen oder Tabulatoren sind wählbar. Die Vorschau nennt die betroffenen Zeilen. Eine weitere Eingabe macht sie ungültig, bevor etwas überschrieben wird.
Was die Analyse sichtbar macht
Diagnosen mit Position
Fehler und Warnungen werden getrennt gezählt. Zeilenlinks bewegen den Editor zur Fundstelle. Die Kategorien sind deutsch; aufklappbare Originaldetails behalten den englischen Engine-Text samt Code.
Anweisungen statt Vermutungen
Die Referenz erklärt die tatsächlich vorhandenen Anweisungen. ARG ist eine Build-Variable, ENV hat eine andere Wirkung, und EXPOSE veröffentlicht keinen Port. Beliebiger Shell-Code wird weder analysiert noch ausgeführt.
Kommentare und Heredocs erhalten
Der Formatter erhält Schreibweise und Reihenfolge. Fehlende Heredoc-Abschlüsse werden als Fehler erkannt. Sieht ein Argument wie JSON aus, ist aber kein String-Array, erscheint ein Hinweis zur möglichen Shell-Interpretation.
Grenzen vor dem Export beachten
- Keine Build- oder Sicherheitszusage
- Das Tool liest keinen Build-Kontext, führt RUN nicht aus und lädt keine Images. Dateiexistenz, Erreichbarkeit, Schwachstellen und erfolgreiches Bauen bleiben damit ungeprüft.
- Kein vollständiger Ersatz für CI-Prüfungen
- Hadolint, ShellCheck und BuildKit haben andere Regeln. Eigene Frontends können außerhalb der Parser-Unterstützung liegen. Ein ignore-Kommentar unterdrückt manche Engine-Meldungen und wird deshalb zusätzlich als Warnung angezeigt.
- Keine semantische Optimierung
- Geändert werden nur führende Anweisungseinzüge, reine Leerzeilen und Fortsetzungseinzüge. RUN wird nicht zusammengelegt, Pakete werden nicht sortiert. COPY --from darf auch ein externes Image bezeichnen und wird nicht allein wegen eines fehlenden Stufennamens beanstandet.
- Einzeldatei mit festen Grenzen
- Akzeptiert werden 131072 UTF-16-Codeeinheiten und 2000 physische Zeilen. Darüber stoppt die Verarbeitung ohne Kürzung. Listen wachsen in Schritten von 50 Einträgen; der Export enthält den vollständigen aktuellen Text mit LF-Zeilenenden.
Dockerfile formatieren: häufige Fragen
Welche Teile der Datei werden beim Formatieren geändert?
Nur die vom Formatter erfassten Einzüge vor Anweisungen, reine Leerzeilen und Fortsetzungszeilen. Kommentare, Schreibweise und Reihenfolge bleiben erhalten. Vergleichen Sie die Vorschau, bevor Sie den Text übernehmen.
Wie lassen sich Hinweise zu Docker-Best-Practices prüfen?
Dieses Tool meldet eine begrenzte Auswahl von Syntax- und Strukturproblemen. Für weitergehende Empfehlungen verwenden Sie die im Projekt festgelegten Hadolint- oder BuildKit-Prüfungen; ein unauffälliges Ergebnis hier ersetzt diese nicht.
Warum sollte das Basis-Image einen festen Tag haben?
Ein veränderlicher Tag kann bei späteren Builds auf andere Inhalte zeigen. Für reproduzierbare Builds kommen konkrete Versionen oder Digests infrage. Auch ein fester Tag ist keine Sicherheitsprüfung; dieses Tool fragt das Image nicht ab.
Lässt sich das Ergebnis als Dockerfile herunterladen?
Ja. Bei aktuellem Ergebnis ohne Fehler lädt die Schaltfläche den vollständigen Text als Datei namens Dockerfile herunter. Nach Änderungen an Eingabe oder Einzug bleibt der Export bis zur nächsten Prüfung gesperrt.
Wird der eingefügte Quelltext an einen Server übertragen?
Der eingefügte Inhalt wird im Browser verarbeitet und nicht an einen Formatierungsdienst oder eine Registry gesendet. Nach dem Neuladen bleibt keine lokale Eingabehistorie zurück. Speichern Sie benötigte Ergebnisse selbst.
Noch eine Frage?
Den nächsten Schritt prüfen
Dockerfile formatieren hilft beim Review: Suchen Sie eine Stufengrenze oder Diagnose auf und exportieren Sie erst die geprüfte Vorschau.
Den tatsächlichen Build anschließend in der eigenen Umgebung prüfen.