ForHosting KIT · Entwickler-Tools

Dockerfile Best Practices mit Zeilennummern prüfen

Dieser Prüfer für Dockerfile Best Practices untersucht drei häufige Probleme, bevor ein Image das Build-System erreicht.

● BetaKostenlos · im Browser

Im Browser ausführen – kostenlos API ansehen

Nutzen Sie es über WebAPIE-MailTelegramApp bald

Er meldet ein fehlendes WORKDIR, Basis-Images mit dem veränderlichen Tag latest und aufeinanderfolgende RUN-Anweisungen, die unnötige Layer erzeugen können. Jeder Fund enthält die Quellzeile, einen stabilen Typ und eine klare Erläuterung. Damit eignet sich das Ergebnis sowohl für Ihre manuelle Prüfung als auch für einen automatisierten Schritt in der kontinuierlichen Integration.

Erhalten Sie einen kurzen und verwertbaren Bericht

Fügen Sie den vollständigen Dockerfile-Inhalt in das Textfeld ein und starten Sie die Prüfung. Die Antwort zeigt, ob die Datei bestanden hat, nennt die Anzahl der Funde und führt jedes Problem mit einer bei eins beginnenden Zeilennummer, einem maschinenlesbaren stabilen Typ und einer knappen Meldung auf. Der Prüfer konzentriert sich bewusst auf drei häufige Wartungsrisiken und ersetzt keine umfassende Container-Sicherheitslösung. Ein fehlendes WORKDIR wird Zeile 1 zugeordnet, weil es die gesamte Datei betrifft. Eine FROM-Anweisung wird in ihrer eigenen Zeile gemeldet, wenn ihr Image ausdrücklich latest verwendet oder keinen Tag besitzt und somit zu latest aufgelöst wird. Folgen zwei RUN-Anweisungen aufeinander, erscheint die spätere mit einem Verweis auf die frühere Zeile. Kommentare und Leerzeilen verdecken diesen Zusammenhang nicht. Eine einwandfreie Datei liefert ein leeres findings-Array, sodass valid unmittelbar als Erfolgskriterium dienen kann. Mit einem umgekehrten Schrägstrich fortgesetzte Zeilen bilden eine logische Anweisung; als Position bleibt die erste physische Zeile erhalten, damit sie zum Editor passt.

Verstehen Sie den Nutzen dieser drei Regeln

WORKDIR legt den Dateisystemkontext für spätere RUN-, COPY-, CMD- und ENTRYPOINT-Anweisungen ausdrücklich fest. Fehlt es, übernimmt der Build stillschweigend ein vom Basis-Image gewähltes Verzeichnis, das sich bei einer Aktualisierung ändern kann. Ein versionierter Tag oder ein unveränderlicher Digest für das FROM-Image verbessert die Reproduzierbarkeit. Sowohl eine Referenz ohne Tag als auch latest können auf andere Inhalte zeigen, obwohl das Dockerfile unverändert blieb. Außerdem erzeugt jede RUN-Anweisung normalerweise einen Dateisystem-Layer. Aufeinanderfolgende Installations-, Bereinigungs- oder Einrichtungsschritte gehören oft in einen Shell-Aufruf, damit temporäre Dateien im selben Layer entfernt werden und der Verlauf übersichtlich bleibt. Der Fund ist als Empfehlung formuliert, weil getrennte RUN-Anweisungen beabsichtigt sein können, wenn Cache-Grenzen einen bewährten Ablauf beschleunigen. Das Werkzeug schreibt keine Befehle um und behauptet nicht, dass jede Zusammenlegung sicher ist. Die endgültige Entscheidung trifft, wer den Build, seine Cache-Strategie und das Fehlerverhalten der Befehle kennt.

Prüfen Sie vor zeitaufwendigen Image-Builds

Führen Sie die Prüfung im Editor, vor einem Commit oder früh in der kontinuierlichen Integration aus, bevor Basis-Images geladen und Anwendungen kompiliert werden. Senden Sie den ursprünglichen Quelltext statt einer geparsten Darstellung, damit physische Zeilen und Fortsetzungen erhalten bleiben. Der Algorithmus arbeitet deterministisch: Gleiche Eingaben erzeugen gleiche Ausgaben, ohne Netzwerk, Uhrzeit, Zufall, Docker-Daemon oder umgebungsspezifischen Zustand. Deshalb eignet er sich auch für generierte Dockerfiles. Betrachten Sie den Bericht als grundlegenden Wartungshinweis, nicht als Beweis für Sicherheit oder Baubarkeit. Das Werkzeug führt keine Shell-Befehle aus, löst keine Variablen in Image-Namen auf, untersucht keine Pakete, validiert keine COPY-Quellen, erzwingt keinen unprivilegierten USER und sucht nicht nach Schwachstellen. Ergänzen Sie diese schnelle Textprüfung durch einen echten Build, Image-Scans, Richtlinien und Tests des resultierenden Prozesses. Besteht die Eingabe nur aus Leerraum oder Kommentaren, schlägt die Anfrage fehl, weil keine Dockerfile-Anweisung bewertet werden kann.

Anwendungsfälle

Dockerfile vor dem Commit prüfen

Erkennen Sie veränderliche Referenzen und unklare Arbeitsverzeichnisse, solange Sie die betroffenen Zeilen bearbeiten.

Generierte Containerdefinitionen kontrollieren

Prüfen Sie Vorlagenausgaben, bevor die Pipeline Zeit in den Build und die Veröffentlichung eines Images investiert.

Container-Repository untersuchen

Erzeugen Sie einheitliche Funde mit Zeilenangaben, um einfache Bereinigungen über mehrere Dienste zu priorisieren.

Häufige Fragen

Was kostet eine Prüfung?

Jede API-Anfrage kostet $0.002. Die Browserversion können Sie auch direkt auf dieser Seite verwenden.

Gilt ein Image ohne Tag als latest?

Ja. Docker behandelt einen fehlenden Tag als latest; empfohlen werden daher ein versionierter Tag oder ein Digest.

Fasst das Werkzeug RUN-Anweisungen automatisch zusammen?

Nein. Es meldet aufeinanderfolgende RUN-Befehle, schreibt sie aber nicht um, da getrennte Cache-Grenzen beabsichtigt sein können.

Warum erscheint fehlendes WORKDIR in Zeile 1?

Die Auslassung betrifft die gesamte Datei und besitzt keine eigene Zeile; Zeile 1 dient deshalb als globale Position.

Prüft dieses Werkzeug Syntax oder Sicherheit?

Nein. Es führt drei grundlegende Kontrollen aus und sollte durch Builds, Richtlinien und Schwachstellen-Scans ergänzt werden.

Für Entwickler — API-Zugang

Alles auf dieser Seite ist auch per API verfügbar. Dieser Abschnitt richtet sich an Teams, die es in ihre eigenen Systeme einbinden möchten; alle anderen nutzen einfach das Tool oben.

Endpunkt

POSThttps://api.kit.forhosting.com/dev2/dockerfile-lint-basic

Authentifizierung per Bearer-Token. Ein einziger POST stellt die Aufgabe in die Warteschlange; das Ergebnis erhalten Sie per Webhook oder über einen signierten Link.

Aufruf aus Ihrem Stack

curl -X POST https://api.kit.forhosting.com/dev2/dockerfile-lint-basic \
  -H "Authorization: Bearer $KIT_KEY" \
  -H "Content-Type: application/json" \
  -d '{"text":"FROM node:20-alpine\nWORKDIR /app\nCOPY package*.json ./\nRUN npm ci && npm cache clean --force\nCOPY . .\nCMD [\"node\", \"server.js\"]"}'

const res = await fetch("https://api.kit.forhosting.com/dev2/dockerfile-lint-basic", {
  method: "POST",
  headers: {
    "Authorization": `Bearer ${process.env.KIT_KEY}`,
    "Content-Type": "application/json"
  },
  body: JSON.stringify({
    "text": "FROM node:20-alpine\nWORKDIR /app\nCOPY package*.json ./\nRUN npm ci && npm cache clean --force\nCOPY . .\nCMD [\"node\", \"server.js\"]"
  })
});
const { task_id } = await res.json();

import os, requests

res = requests.post(
    "https://api.kit.forhosting.com/dev2/dockerfile-lint-basic",
    headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
    json={
    "text": "FROM node:20-alpine\nWORKDIR /app\nCOPY package*.json ./\nRUN npm ci && npm cache clean --force\nCOPY . .\nCMD [\"node\", \"server.js\"]"
},
)
task_id = res.json()["task_id"]

<?php
$res = file_get_contents("https://api.kit.forhosting.com/dev2/dockerfile-lint-basic", false, stream_context_create([
  "http" => [
    "method"  => "POST",
    "header"  => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
    "content" => '{"text":"FROM node:20-alpine\\nWORKDIR /app\\nCOPY package*.json ./\\nRUN npm ci && npm cache clean --force\\nCOPY . .\\nCMD [\\"node\\", \\"server.js\\"]"}',
  ],
]));
$task = json_decode($res, true);

body := bytes.NewBufferString(`{"text":"FROM node:20-alpine\nWORKDIR /app\nCOPY package*.json ./\nRUN npm ci && npm cache clean --force\nCOPY . .\nCMD [\"node\", \"server.js\"]"}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/dev2/dockerfile-lint-basic", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)

Beispiel-Anfrage

{
  "text": "FROM node:20-alpine\nWORKDIR /app\nCOPY package*.json ./\nRUN npm ci && npm cache clean --force\nCOPY . .\nCMD [\"node\", \"server.js\"]"
}

Beispiel-Antwort

{
  "task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
  "type": "dev2.dockerfile_lint_basic",
  "status": "queued",
  "_links": {
    "result": "/tasks/tsk_…/result"
  }
}

Die API arbeitet asynchron: Sie erhalten sofort eine task_id. Polling ist mit 1 Anfrage pro Sekunde erlaubt.

Preis

pro Anfrage$0.002

Der Preis steht auf der Seite – keine Tokens, keine Credits. Fehlgeschlagene Aufgaben werden nicht berechnet.

Fehler

HTTP	Code	Bedeutung
`401`	`unauthorized`	Der API-Schlüssel fehlt oder ist ungültig – prüfen Sie den Authorization-Header (Bearer).
`402`	`insufficient_balance`	Ihr Guthaben reicht für diese Aufgabe nicht aus – Aufladungen verfallen nicht.
`404`	`unknown_type`	Unbekannter Aufgabentyp – prüfen Sie das Feld „type“ gegen den Katalog.
`429`	`rate_limited`	Zu viele Anfragen – warten Sie kurz; Polling ist mit 1 Anfrage pro Sekunde erlaubt.

Vollständige KIT-Dokumentation lesen →