Docker & Container

Docker Compose validieren

Eine Compose-Datei prüfen und ihre deklarierten Beziehungen nachvollziehen.

Docker Compose validieren

Compose-YAML-Eingabe

Analyseergebnisse

YAML bleibt in diesem Browser. Keine Docker-Ausführung, Umgebungsdateien oder Netzwerkanfragen.

Prüfoptionen

Die Eingabe ist sichtbar. Einblenden erlaubt YAML-Exporte mit Originalwerten, auch Geheimnissen.

Statische Prüfung: Compose-Schema fee041b (01.09.2026). Keine Interpolation, Dateien, Profilaktivierung oder Container-Ausführung.

Maximal 200.000 UTF-16-Einheiten, 100 Dienste und 500 Beziehungen. Anzeige in Schritten von 50.

Eingabe oder Optionen geändert. Vor dem Export erneut analysieren.

Docker Compose validieren hilft bei der Prüfung eines Stack-Umbaus: Gültiges YAML allein erkennt weder einen fehlenden Volume-Namen noch zwei Dienste am selben Host-Port. Die Diagnose verweist auf die ursprüngliche Stelle. Der Quelltext bleibt unverändert neben dem formatierten Ergebnis, damit sich Änderungen vor einem Commit nachvollziehen lassen.

Docker Compose validieren vor dem Start

Verbindungen statt verstreuter Felder lesen

Docker Compose validieren macht Abhängigkeiten, Mounts und Port-Zuordnungen gemeinsam sichtbar. Ein Pfeil führt vom abhängigen Dienst zu seinem Ziel. Die condition einer langen depends_on-Angabe bleibt erkennbar; sie ist eine deklarierte Bedingung und kein Nachweis, dass die Datenbank bereits bereitsteht.

Drei Dienste sind nacheinander verbunden; unter der Datenbank ist ein Volume angeschlossen.

Sichere Konflikte von möglichen Überschneidungen trennen

Unterschiedliche Container-Ports können denselben Host-Port beanspruchen. TCP und UDP werden getrennt geprüft. Bei Vergabebereichen, gemischten IPv4/IPv6-Wildcards und Diensten mit Profilen bleibt eine Warnung, weil die tatsächlich verwendete Belegung noch nicht feststeht.

Zwei Dienste zeigen auf denselben hervorgehobenen Host-Socket.

Vom Fund zur überprüfbaren Ausgabe

01

Zuerst die Struktur korrigieren

YAML validieren liefert Zeile und Spalte; Schemafehler zeigen einen Feldpfad. Erst nach der Strukturprüfung sind die Beziehungsansichten belastbar. Das Feld version wählt kein historisches Schema aus: Die mitgelieferte Spezifikation bleibt unverändert.

02

Die Host-Seite der Zuordnung lesen

Zwei Container dürfen intern Port 80 verwenden. Entscheidend sind Host-Adresse, veröffentlichter Port und Protokoll. Variablen und automatisch vergebene Ports bleiben unaufgelöst. Daraus wird keine fiktive feste Belegung berechnet.

03

Werte bewusst einblenden

Die Eingabe ist sichtbar, die vollständige Ausgabe zunächst verborgen. Erst das Einblenden erlaubt den YAML-Export mit Originalwerten. Ohne automatische Analyse stehen der Hauptknopf und Ctrl/Cmd + Enter bereit. Änderungen sperren alte Exporte sofort.

Struktur und Zusammenhänge gemeinsam prüfen

Offizielles Schema und gezielte Zusatzregeln

Die Prüfung nutzt den offiziellen Stand vom 01.09.2026 und ergänzt fehlende Dienstquellen, Ressourcenverweise, Zyklen sowie Port-Syntax. Unbekannte Felder werden gemeldet, nicht entfernt. Die Formatierung erhält Kommentare und Anker und überschreibt weder Eingabe noch Reihenfolge der Dienste.

Abhängigkeiten und Volume-Quellen

Um eine Compose-Datei prüfen zu können, erscheinen kurze und lange depends_on-Angaben, Dienst-Namensräume, links und volumes_from als Beziehungen. Benannte Volumes werden mit der obersten Deklaration abgeglichen. Bind-Pfade werden angezeigt, aber nicht geöffnet. Anonyme Volumes bleiben unterscheidbar.

Umgebungsvariablen ohne geheime Vorgaben

Gescannt werden Zeichenkettenwerte mit $VAR, Klammerausdrücken und verschachtelten Alternativen; $$ maskiert das Dollarzeichen. Leere environment-Einträge werden als Übernahme aus der Shell erfasst. Die sortierte Vorlage enthält eindeutige Namen als NAME=, niemals deren Vorgabewerte.

Ausgaben für unterschiedliche Prüfzwecke

YAML enthält die tatsächlichen Werte und Interpolationsausdrücke. Der JSON-Bericht lässt den vollständigen Quelltext und Variablenvorgaben weg, bewahrt aber Pfade und Beziehungen. Ansichten zeigen jeweils 50 Einträge; der Export enthält alle Einträge innerhalb der Grenzen.

Grenzen der Prüfung ohne Laufzeit

Keine Ausführung oder Erreichbarkeitsprüfung
Das Werkzeug startet keine Container, lädt keine Images und testet keine Healthchecks. Es untersucht keine bereits durch andere Programme belegten Ports. Rechte, Netzwerkverbindungen und die konkrete Docker-Version müssen in der Zielumgebung geprüft werden.
Eine Datei ohne externe Auflösung
Mehrere YAML-Dokumente, doppelte Schlüssel, zyklische Aliase und nicht unterstützte Tags werden abgewiesen. include und extends verhindern den Konfigurationsexport. Es gibt weder Override-Merging noch das Laden von .env oder env_file. Externe Zusammenhänge zuerst lokal auflösen.
Profile werden nicht aktiviert
Alle deklarierten Dienste nehmen teil. Port-Konflikte mit Profilen oder Vergabebereichen werden daher als mögliche Überschneidung behandelt. Eine Warnung kann bei einer bestimmten Profilauswahl gegenstandslos sein; umgekehrt kennt die Prüfung keine anderen laufenden Projekte.
Verbergen bedeutet nicht anonymisieren
Der Quelltext bleibt sichtbar. Nach dem Einblenden kann exportiertes YAML weiterhin Geheimnisse enthalten; Fehler blockieren diesen Export. Die ENV-Vorlage enthält ausschließlich leere Werte. Ein herunterladbarer Fehlerbericht bescheinigt keine gültige oder sichere Bereitstellung.
Begrenzte Expansion und fester Stand
YAML 1.2 mit Ankern und Merge-Schlüsseln wird begrenzt verarbeitet: 200.000 UTF-16-Einheiten, 100 Dienste, 500 Beziehungsdatensätze, 20.000 expandierte Knoten und Tiefe 40. Der Schema-Commit beginnt mit fee041b. Neue Spezifikationsfelder erfordern eine Aktualisierung.
Mounts und Abhängigkeiten bleiben Deklarationen
Bind-, benannte Volume- und tmpfs-Mounts werden gezielt untersucht. Andere vom Schema erlaubte Mount-Typen verlangen manuelle Prüfung. Es werden keine Host-Pfade aufgelöst und keine Bereitschaftszeiten simuliert. Ein Abhängigkeitspfeil beweist keine funktionierende Anwendungsverbindung.

Docker Compose validieren: Fragen

Warum Compose und .env vor dem Deploy prüfen?

Falsche Feldnamen, fehlende Verweise und Portüberschneidungen lassen sich oft vor dem Start finden. Hier wird ausschließlich das eingefügte Compose-Dokument geprüft. Die tatsächliche .env-Datei, ihre Werte und die spätere Auflösung gehören zusätzlich in die lokale Prüfung.

Warum ist scheinbar korrektes YAML ungültig?

Einrückung, doppelte Schlüssel oder ein falscher Datentyp können die Bedeutung verändern. Außerdem ist syntaktisch gültiges YAML noch keine gültige Compose-Struktur. Prüfen Sie zuerst die gemeldete Position und danach den Schema-Pfad; das Werkzeug repariert Werte nicht stillschweigend.

Zeigt das Werkzeug die Fehlerstelle?

Syntaxfehler erhalten Zeile und Spalte, fehlerhafte Felder zusätzlich einen Pfad. Die betreffende Eingabezeile wird markiert. Bei geerbten Ankerwerten kann die nächstgelegene auflösbare Deklaration die relevante Stelle sein; die Originaldatei wird dabei nicht geändert.

Werden meine Dateien an einen Server gesendet?

Die Analyse läuft im Browser-Worker. Eingefügte URLs werden nicht geladen und externe Dateien nicht geöffnet. Es gibt keinen Docker-Daemon-Zugriff. Kopieren und Herunterladen erfolgen nur durch die jeweiligen Bedienaktionen.

Wie passt ein Compose-Editor in einen Git-Workflow?

Prüfen Sie vor einem Commit den Quelltext, die Diagnose und bei Bedarf die formatierte Ausgabe. Der Editor schreibt nicht in Ihr Repository und erstellt keine Commits. Kommentare und Werte bleiben erhalten; den endgültigen Diff und die Prüfung mit der verwendeten Compose-Version übernehmen Sie lokal.

Soll eine Compose-Diagnose präziser werden?

Deklarationen vor dem Start abgleichen

Docker Compose validieren, die gemeldeten Pfade korrigieren und erst nach Prüfung der Host-Bindings die gewünschten Werte einblenden und exportieren.