Dockerfile Formatter – Schone, Overtuigde Dockerfiles Online (aangedreven door dprint)

Loading…

Over Gratis Online Dockerfile Formatter

Rommelige Dockerfile? Gebroken inspringing, inconsistente spaties en onleesbare RUN-ketens? Deze Dockerfile Formatter gebruikt een dprint-gebaseerde engine (via een beveiligde backend) om uw Dockerfiles en Containerfiles te normaliseren met een schone, overtui gde lay-out. Het houdt uw instructies exact op hun plaats terwijl het bestand gemakkelijker te beoordelen, versiebeheren en automatiseren is in verschillende omgevingen.

Belangrijkste Kenmerken van de Dockerfile Formatter

Maakt inspringing, spaties en regelafbreking schoon voor Dockerfiles en Containerfiles
Normaliseert multi-line RUN-instructies met consistente backslashes en inspringing
Respecteert Dockerfile-semantiek – geen herschikking van instructies, geen wijzigingen in shell-logica
Deterministische uitvoer: zelfde invoer en versie ⇒ zelfde geformatteerde Dockerfile
Perfecte metgezel voor pre-commit hooks, monorepos en CI-taken met dprint
Webbased editor met syntaxismarkering, diff-vriendelijke uitvoer en kopieer/download acties
Werkt goed met multi-stage builds, build-argumenten en typische Node/.NET/Go-images

🛠️ Hoe een Dockerfile te Formatteren for dockerfile-formatter

1. Plak of Upload Uw Dockerfile

Plak uw Dockerfile in de editor of sleep een Dockerfile/Containerfile vanuit uw project. Kleine fragmenten (zoals een enkel FROM/RUN blok) werken ook als u gewoon wilt experimenteren.

2. Voer de Formatter Uit

Klik op "Formatteren". De tool stuurt uw broncode naar een veilige, op dprint gebaseerde backend die de inspringing, spaties, array-stijl instructies en multi-line RUN ketens aanpast zonder de uitvoeringslogica aan te raken.

3. Bekijk, Kopieer of Download

Vergelijk de geformatteerde uitvoer met uw originele bestand. Als u tevreden bent, kopieer het resultaat terug naar uw repository of download de geformatteerde Dockerfile om deze direct te committen.

Technische Details

Ondersteunde Bestandstypen

De formatter richt zich op Docker build-instructies en compatibele container build-bestanden die worden gebruikt in Docker, Podman en vergelijkbare tools.

Type	Voorbeeld	Opmerkingen
Dockerfile	Dockerfile, Dockerfile.prod, Dockerfile.node18	Klassieke Docker build-bestanden voor images
Containerfile	Containerfile	Podman / Buildah stijl configuratiebestanden
Inline fragmenten	FROM node:18-alpine	Kleine fragmenten of voorbeelden worden ook ondersteund voor snelle tests

Opmaakgedrag (dprint-stijl)

Hoogwaardige gedragingen van de onderliggende dprint plugin die door deze tool wordt gebruikt:

Gebied	Gedrag	Voorbeeld
Inspringing	Normaliseert inspringing voor doorlopende regels in RUN en andere instructies	RUN set -eux; \\n npm ci; \\n npm cache clean --force
Lijsten & arrays	Reinigt spaties in JSON-stijl arrays voor CMD/ENTRYPOINT/HEALTHCHECK	CMD ["npm", "start"] → CMD ["npm", "start"] (maar met consistente spaties)
Spaties	Verwijdert overbodige spaties rond instructies terwijl de betekenis behouden blijft	ENV NODE_ENV=production
Regelafbreking	Kan lange RUN ketens herschikken voor leesbaarheid zonder de volgorde te wijzigen	Lange shell pijplijnen worden gemakkelijker te scannen en te beoordelen in diffs
Opmerkingen	Behoudt volledige-regel en inline opmerkingen naast instructies	# basisafbeelding voor bouwfase\nFROM node:18 AS build

Niet-doelen

Deze formatter is bewust beperkt tot lay-out, zodat je het kunt combineren met andere DevOps-tools:

Item	Afgehandeld?	Notities
Hadolint-stijl linting	❌	Gebruik hadolint of vergelijkbare tools voor best-practice controles en waarschuwingen
Beveiligingsscanning	❌	Geen CVE- of kwetsbaarheidsscanning van afbeeldingen of registers
Afbeelding bouwen	❌	Voert docker build niet uit en communiceert niet met Docker Engine
Instructieherordening	❌	Hernooid nooit instructies; alleen inspringing en witruimte veranderen
Basisafbeelding verharding	❌	Adviseert geen basisafbeeldingen; het formatteert wat je aanlevert

CLI & CI Equivalenten

Bevallen de resultaten? Spiegel hetzelfde gedrag lokaal en in CI met dprint en aanvullende tools.

Universeel (dprint)

Initialiseer dprint en voeg Dockerfile-plugin toe

dprint init
# In dprint.json, voeg toe:
# {
#   "plugins": ["https://plugins.dprint.dev/dockerfile-0.x.wasm"]
# }
# Formatteer vervolgens je Dockerfiles:
dprint fmt Dockerfile

Dichtstbijzijnde match met deze online formatter, zodat ontwikkelaars en CI dezelfde stijl gebruiken.

Linux/macOS

Lint met hadolint (complementeert formattering)

hadolint Dockerfile

Combineer formattering (stijl) met linting (best practices, kleinere afbeeldingen, healthchecks).

Git / pre-commit

Voer dprint uit op gewijzigde Dockerfiles voor commit

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

Garandeert dat elke Dockerfile die naar main wordt samengevoegd al geformatteerd is.

Veelvoorkomende Gebruiksscenario's

Dev & Platform Engineering

Normaliseer Dockerfiles over microservices heen voor code review
Ruim verouderde Dockerfiles op die zijn overgenomen van meerdere teams of templates
Standaardiseer stijl bij het migreren van images, basis-OS-versies of bouwstrategieën

# Typische multi-stage Dockerfile (schoon, review-vriendelijk)\nFROM node:18 AS build\nWORKDIR /app\nCOPY package*.json ./\nRUN npm ci && npm cache clean --force\nCOPY . .\nRUN npm run build\n\nFROM node:18-alpine\nWORKDIR /app\nCOPY --from=build /app/dist ./\nCMD ["node", "index.js"]

CI/CD-pijplijnen

Laat builds mislukken wanneer Dockerfiles niet correct zijn opgemaakt
Stijl automatisch herstellen op feature branches via pre-commit hooks of CI-taken
Houd Docker-configuratie leesbaar in langlevende monorepo's en platformrepo's

# Voorbeeld Git pre-commit hook (pseudo-code)\n#!/bin/sh\nchanged=$(git diff --cached --name-only --diff-filter=ACM | grep -E 'Dockerfile|Containerfile' || true)\n[ -z "$changed" ] && exit 0\ndprint fmt $changed\ngit add $changed

Teamonboarding & consistentie

Geef nieuwe teamleden één duidelijke Dockerfile-stijl om te volgen
Verwijder code-stijl debatten uit PR's: laat de formatter de bron van waarheid zijn
Breng lokale opmaak, repo-hooks en CI-taken in lijn met dezelfde dprint-configuratie

# Voorbeeld fragment voor docs/onboarding.md\n1. Installeer dprint lokaal\n2. Kopieer de gedeelde dprint.json van de platformrepo\n3. Voer `dprint fmt Dockerfile` uit voordat je een pull-request opent

❓ Frequently Asked Questions

Verandert opmaak hoe mijn image wordt gebouwd?

Nee. De formatter raakt alleen witruimte, inspringing en regelafbreking aan. Het behoudt de volgorde en inhoud van je Dockerfile-instructies. Zolang je originele Dockerfile geldig was, zou de resulterende image-build hetzelfde gedrag vertonen.

Is dit hetzelfde als linten met hadolint?

Nee. Deze tool is een formatter, geen linter. Het repareert stijl- en lay-outproblemen (spatiëring, inspringing, afbreken), maar het waarschuwt je niet voor best practices (zoals het gebruik van specifieke basisimages, healthchecks of laaggrootten). Combineer het daarvoor met hadolint of een andere Dockerfile-linter.

Kan ik deze stijl afdwingen in CI?

Ja. Je kunt dprint configureren met de Dockerfile-plugin in je repository en `dprint fmt` (of `dprint check`) uitvoeren in je CI-pijplijn. Op die manier kan CI mislukken wanneer Dockerfiles afwijken van de verwachte stijl, overeenkomend met wat je ziet in deze online formatter.

Ondersteunt het multi-stage builds?

Ja. Multi-stage Dockerfiles worden opgemaakt zoals elk ander bestand. Elke FROM, COPY, RUN en ENV instructie wordt behouden, en de lay-out wordt consistent gemaakt over alle stadia zonder bouwsemantiek te veranderen.

Wordt mijn Dockerfile geüpload naar een server?

Voor deze tool wordt opmaak uitgevoerd via een beveiligd backend-eindpunt met een dprint-gebaseerde formatter. Je bron wordt gebruikt om het antwoord te berekenen en is niet bedoeld voor langdurige opslag. Zoals altijd: vermijd het plakken van zeer vertrouwelijke infrastructuurdetails in een online tool, tenzij je de volledige stack beheert.

Pro Tips

Best Practice

Voer automatisch formatteren uit in CI zodat de Dockerfile-stijl nooit afwijkt tussen services of teams.

Best Practice

Combineer deze formatter met een linter zoals hadolint om zowel lay-out als richtlijnen voor beste praktijken te dekken.

Best Practice

Spreek vroeg in een project een standaard multi-stage Dockerfile-sjabloon af en houd het geformatteerd zodat nieuwe services dezelfde structuur volgen.

Best Practice

Als je in een monorepo werkt, deel dan één dprint-configuratie zodat applicatiecode, infra-code en Dockerfiles consistente conventies gebruiken.