Dockerfile-Formatierer – Saubere, Meinungsstarke Dockerfiles Online (dprint-betrieben)

Loading…

Über Kostenloser Online-Dockerfile-Formatierer

Unordentliches Dockerfile? Kaputte Einrückung, inkonsistente Abstände und unlesbare RUN-Ketten? Dieser Dockerfile-Formatierer verwendet eine dprint-basierte Engine (über ein sicheres Backend), um Ihre Dockerfiles und Containerfiles mit einem sauberen, meinungsstarken Layout zu normalisieren. Er behält Ihre Anweisungen exakt bei, macht die Datei jedoch leichter zu überprüfen, zu versionieren und über Umgebungen hinweg zu automatisieren.

Hauptfunktionen des Dockerfile-Formatierers

Bereinigt Einrückung, Abstände und Zeilenumbrüche für Dockerfiles und Containerfiles
Normalisiert mehrzeilige RUN-Anweisungen mit konsistenten Backslashes und Einrückung
Respektiert Dockerfile-Semantik – keine Neuanordnung von Anweisungen, keine Änderungen an Shell-Logik
Deterministische Ausgabe: gleiche Eingabe und Version ⇒ gleiches formatiertes Dockerfile
Perfekter Begleiter für Pre-Commit-Hooks, Monorepos und CI-Jobs mit dprint
Webbasierter Editor mit Syntaxhervorhebung, diff-freundlicher Ausgabe und Kopier-/Download-Aktionen
Funktioniert gut mit Multi-Stage-Builds, Build-Args und typischen Node/.NET/Go-Images

🛠️ So formatieren Sie ein Dockerfile for dockerfile-formatter

1. Fügen Sie Ihr Dockerfile ein oder laden Sie es hoch

Fügen Sie Ihr Dockerfile in den Editor ein oder ziehen Sie ein Dockerfile/Containerfile aus Ihrem Projekt herein. Kleine Ausschnitte (wie ein einzelner FROM/RUN-Block) funktionieren ebenfalls, wenn Sie nur experimentieren möchten.

2. Formatter ausführen

Klicken Sie auf "Formatieren". Das Tool sendet Ihre Quelle an ein sicheres, dprint-basiertes Backend, das Einrückungen, Abstände, Array-artige Anweisungen und mehrzeilige RUN-Ketten anpasst, ohne die Ausführungslogik zu verändern.

3. Überprüfen, Kopieren oder Herunterladen

Vergleichen Sie die formatierte Ausgabe mit Ihrer ursprünglichen Datei. Wenn Sie zufrieden sind, kopieren Sie das Ergebnis zurück in Ihr Repository oder laden Sie das formatierte Dockerfile herunter, um es direkt zu committen.

Technische Details

Unterstützte Dateitypen

Der Formatter zielt auf Docker-Build-Anweisungen und kompatible Container-Build-Dateien ab, die in Docker, Podman und ähnlichen Tools verwendet werden.

Typ	Beispiel	Hinweise
Dockerfile	Dockerfile, Dockerfile.prod, Dockerfile.node18	Klassische Docker-Build-Dateien für Images
Containerfile	Containerfile	Podman / Buildah Stil Konfigurationsdateien
Inline-Ausschnitte	FROM node:18-alpine	Kleine Fragmente oder Beispiele werden ebenfalls für schnelle Tests unterstützt

Formatierungsverhalten (dprint-Stil)

Hochrangige Verhaltensweisen des zugrunde liegenden dprint-Plugins, das von diesem Tool verwendet wird:

Bereich	Verhalten	Beispiel
Einrückung	Normalisiert die Einrückung für fortgesetzte Zeilen in RUN- und anderen Anweisungen	RUN set -eux; \\n npm ci; \\n npm cache clean --force
Listen & Arrays	Bereinigt Abstände in JSON-artigen Arrays für CMD/ENTRYPOINT/HEALTHCHECK	CMD ["npm", "start"] → CMD ["npm", "start"] (aber mit konsistenten Leerzeichen)
Abstände	Entfernt überflüssige Leerzeichen um Anweisungen, während die Bedeutung erhalten bleibt	ENV NODE_ENV=production
Zeilenumbruch	Kann lange RUN-Ketten für bessere Lesbarkeit umbrechen, ohne die Reihenfolge zu ändern	Lange Shell-Pipelines werden in Diffs leichter zu überprüfen und zu scannen
Kommentare	Bewahrt vollständige und Inline-Kommentare neben Anweisungen	# base image for build stage\nFROM node:18 AS build

Nicht-Ziele

Dieser Formatierer ist bewusst auf das Layout beschränkt, damit Sie ihn mit anderen DevOps-Tools kombinieren können:

Element	Behandelt?	Hinweise
Hadolint-ähnliches Linting	❌	Verwenden Sie hadolint oder ähnliche Tools für Best-Practice-Prüfungen und Warnungen
Sicherheitsscans	❌	Keine CVE- oder Schwachstellenscans von Images oder Registries
Image-Erstellung	❌	Führt docker build nicht aus und interagiert nicht mit Docker Engine
Anweisungsneuanordnung	❌	Ordnet Anweisungen niemals neu; nur Einrückungen und Leerzeichen ändern sich
Basis-Image-Härtung	❌	Empfiehlt keine Basis-Images; es formatiert, was Sie bereitstellen

CLI & CI-Äquivalente

Gefällt Ihnen das Ergebnis? Spiegeln Sie das gleiche Verhalten lokal und in CI mit dprint und ergänzenden Tools.

Universal (dprint)

Dprint initialisieren und Dockerfile-Plugin hinzufügen

dprint init
# In dprint.json, add:
# {
#   "plugins": ["https://plugins.dprint.dev/dockerfile-0.x.wasm"]
# }
# Then format your Dockerfiles:
dprint fmt Dockerfile

Nächste Entsprechung zu diesem Online-Formatierer, sodass Entwickler und CI denselben Stil verwenden.

Linux/macOS

Mit hadolint linten (ergänzt die Formatierung)

hadolint Dockerfile

Kombinieren Sie Formatierung (Stil) mit Linting (Best Practices, kleinere Images, Healthchecks).

Git / pre-commit

Dprint auf geänderte Dockerfiles vor dem Commit ausführen

# .pre-commit-config.yaml (conceptual)
- repo: local
  hooks:
    - id: dprint-dockerfile
      name: dprint Dockerfiles
      entry: dprint fmt
      language: system
      files: "(Dockerfile|Containerfile)$"

Stellt sicher, dass jede in den Hauptzweig gemergte Dockerfile bereits formatiert ist.

Häufige Anwendungsfälle

Entwicklungs- & Plattformtechnik

Dockerfiles vor Code-Review über Microservices hinweg normalisieren
Alte Dockerfiles bereinigen, die von mehreren Teams oder Vorlagen übernommen wurden
Stil beim Migrieren von Images, Basis-Betriebssystemversionen oder Build-Strategien standardisieren

# Typisches mehrstufiges Dockerfile (sauber, reviewfreundlich)
FROM node:18 AS build
WORKDIR /app
COPY package*.json ./
RUN npm ci && npm cache clean --force
COPY . .
RUN npm run build

FROM node:18-alpine
WORKDIR /app
COPY --from=build /app/dist ./
CMD ["node", "index.js"]

CI/CD-Pipelines

Builds fehlschlagen lassen, wenn Dockerfiles nicht korrekt formatiert sind
Stil auf Feature-Branches automatisch über Pre-Commit-Hooks oder CI-Jobs korrigieren
Docker-Konfiguration in langlebigen Monorepos und Plattform-Repos lesbar halten

# Beispiel-Git-Pre-Commit-Hook (Pseudocode)
#!/bin/sh
changed=$(git diff --cached --name-only --diff-filter=ACM | grep -E 'Dockerfile|Containerfile' || true)
[ -z "$changed" ] && exit 0
dprint fmt $changed
git add $changed

Team-Einarbeitung & Konsistenz

Neuen Teammitgliedern einen einheitlichen, vorgegebenen Dockerfile-Stil zur Verfügung stellen
Code-Stil-Debatten aus PRs entfernen: Der Formatter ist die einzige Wahrheit
Lokale Formatierung, Repo-Hooks und CI-Jobs auf dieselbe dprint-Konfiguration abstimmen

# Beispielausschnitt für docs/onboarding.md
1. dprint lokal installieren
2. Gemeinsame dprint.json aus dem Plattform-Repo kopieren
3. `dprint fmt Dockerfile` vor dem Öffnen eines Pull Requests ausführen

❓ Frequently Asked Questions

Ändert die Formatierung, wie mein Image gebaut wird?

Nein. Der Formatter ändert nur Leerzeichen, Einrückungen und Zeilenumbrüche. Er bewahrt die Reihenfolge und den Inhalt Ihrer Dockerfile-Anweisungen. Solange Ihr ursprüngliches Dockerfile gültig war, sollte der resultierende Image-Build gleich funktionieren.

Ist das dasselbe wie Linting mit hadolint?

Nein. Dieses Tool ist ein Formatter, kein Linter. Es behebt Stil- und Layoutprobleme (Abstände, Einrückungen, Umbrüche), warnt Sie aber nicht vor Best Practices (wie die Verwendung bestimmter Basis-Images, Healthchecks oder Layergrößen). Kombinieren Sie es dafür mit hadolint oder einem anderen Dockerfile-Linter.

Kann ich diesen Stil in CI durchsetzen?

Ja. Sie können dprint mit dem Dockerfile-Plugin in Ihrem Repository konfigurieren und `dprint fmt` (oder `dprint check`) in Ihrer CI-Pipeline ausführen. So kann CI fehlschlagen, wenn Dockerfiles vom erwarteten Stil abweichen, entsprechend dem, was Sie in diesem Online-Formatter sehen.

Unterstützt es Multi-Stage-Builds?

Ja. Mehrstufige Dockerfiles werden wie jede andere Datei formatiert. Jede FROM-, COPY-, RUN- und ENV-Anweisung bleibt erhalten, und das Layout wird über alle Stufen hinweg konsistent gestaltet, ohne die Build-Semantik zu ändern.

Wird mein Dockerfile auf einen Server hochgeladen?

Für dieses Tool wird die Formatierung über einen sicheren Backend-Endpoint mit einem dprint-basierten Formatter durchgeführt. Ihr Quellcode wird zur Berechnung der Antwort verwendet und soll nicht langfristig gespeichert werden. Vermeiden Sie wie immer das Einfügen hochvertraulicher Infrastrukturdetails in Online-Tools, es sei denn, Sie kontrollieren den gesamten Stack.

Pro Tips

Best Practice

Führen Sie die Formatierung automatisch in CI aus, damit der Dockerfile-Stil nie zwischen Diensten oder Teams abweicht.

Best Practice

Kombinieren Sie diesen Formatierer mit einem Linter wie hadolint, um sowohl Layout als auch Best-Practice-Richtlinien abzudecken.

Best Practice

Vereinbaren Sie früh in einem Projekt eine standardisierte Multi-Stage-Dockerfile-Vorlage und halten Sie sie formatiert, damit neue Dienste derselben Struktur folgen.

Best Practice

Wenn Sie in einem Monorepo arbeiten, teilen Sie eine einzige dprint-Konfiguration, damit Anwendungscode, Infrastrukturcode und Dockerfiles konsistente Konventionen verwenden.