Was ist YAML? Unterschied zu JSON, Syntax und typische Einrückungsfehler

Was ist YAML und wofür nutzt man es?

YAML ist eine menschenfreundliche Sprache zur Datenserialisierung, die Struktur über Einrückung statt über Klammern ausdrückt und Werte als Paare aus Schlüssel und Wert speichert. Weil sie sich wie eine saubere Gliederung liest, nutzen Entwickler sie für Konfigurationsdateien, CI Pipelines, Docker Compose und Kubernetes Manifeste.

Ein einfacher Vergleich hilft. JSON ist wie ein penibler Sachbearbeiter, der alles in Kästchen mit Kommas sortiert. YAML schreibt dieselben Informationen wie ein ordentliches Notizbuch mit Aufzählungen. Folglich erfasst das Auge den Inhalt schneller. Allerdings kann ein einziges verrutschtes Leerzeichen die Bedeutung ändern. Was ist YAML also technisch, welche Regeln machen es stark, und wo stolpern Entwickler am häufigsten? Wir von Talha Aslan und Team lesen in Kundenprojekten täglich YAML Dateien; in diesem Leitfaden teilen wir die Fallen, die uns in der Praxis immer wieder begegnen.

Schon der Name ist ein kleiner Scherz. Heute steht das Akronym offiziell für "YAML Ain't Markup Language". Das heißt, YAML versteht sich als Datensprache und nicht als Auszeichnungssprache. Die Regeln stehen in der offiziellen YAML Spezifikation auf yaml.org, und die Syntaxerklärungen in diesem Artikel stützen sich auf dieses Dokument.

Wie funktioniert YAML, und wie liest ein Parser die Datei?

Zunächst ist eine YAML Datei reiner Text. Wenn ein Programm sie nutzen will, kommt eine Bibliothek ins Spiel, die man Parser nennt. Der Parser liest den Text und baut anhand von Einrückung und Zeichen einen Baum. Danach übersetzt er diesen Baum in die Datentypen Ihrer Programmiersprache. Zum Beispiel erhalten Sie in Python Dictionaries und Listen, in JavaScript dagegen Objekte und Arrays.

Die Spezifikation beschreibt drei Grundbausteine. Erstens gibt es das Mapping, also Paare aus Schlüssel und Wert. Zweitens gibt es die Sequenz, eine geordnete Liste. Schließlich gibt es den Skalar, einen einzelnen Wert wie Text, Zahl, Datum oder Boolean. Jede YAML Datei, egal wie groß, kombiniert diese drei Strukturen.

Den Typ eines Skalars errät der Parser zudem oft selbst. Ohne Anführungszeichen liest er 42 als Zahl und true als Boolean. Diese implizite Typisierung macht YAML also bequem. Andererseits entstehen daraus die Typfallen, die wir weiter unten besprechen. Kurz gesagt kommen Stärke und Risiko von YAML aus derselben Quelle: Die Sprache entscheidet für Sie.

Was ist YAML Syntax bei Schlüssel und Wert?

Die einfachste YAML Zeile besteht aus einem Schlüssel, einem Doppelpunkt, einem Leerzeichen und einem Wert. Schreiben Sie zum Beispiel name: Talha oder port: 8080, dann behandelt der Parser beides als Einträge eines Mappings. Das Leerzeichen nach dem Doppelpunkt ist dabei Pflicht. Schreiben Sie port:8080, lesen die meisten Parser das Ganze daher als einen einzigen Text.

Schlüssel sind konkret meist einfacher Text, Sie können sie aber auch in Anführungszeichen setzen. Werte können Texte, Zahlen, Booleans, Null oder eine weitere verschachtelte Struktur sein. Für einen leeren Wert schreiben Sie null, nutzen ~ oder lassen den Wert einfach weg.

• Text: titel: Hallo Welt, Anführungszeichen sind optional.
• Zahl: anzahl: 12 oder quote: 0.75.
• Boolean: aktiv: true; YAML 1.2 kennt nur true und false.
• Null: notiz: null oder notiz: ~.
• Kommentar: alles nach dem Zeichen # ignoriert der Parser.

Die Unterstützung für Kommentare wirkt wie ein Detail. Im Team macht sie allerdings einen echten Unterschied. Sie können direkt in der Datei erklären, warum eine Einstellung einen bestimmten Wert hat. Standard JSON bietet keine Kommentare. Deshalb wählen viele Teams YAML für Dateien, die Menschen von Hand bearbeiten.

Wie schreiben Sie Listen und verschachtelte Strukturen in YAML?

Für eine Liste setzen Sie vor jeden Eintrag einen Strich und ein Leerzeichen. Eine Serverliste enthält also Zeilen wie - web1 und - web2. Für kurze Listen gibt es außerdem eine Inline Schreibweise, die an JSON erinnert: sprachen: [de, en, tr]. Ebenso schreiben Sie ein kurzes Mapping in eine Zeile, etwa {name: Anna, alter: 30}.

Verschachtelung entsteht dann ausschließlich über Einrückung. Zeilen, die Sie unter einem Schlüssel weiter einrücken, werden zu dessen Kindern. Schreiben Sie zum Beispiel datenbank: und darunter zwei Leerzeichen tiefer host: localhost und port: 5432, dann enthält der Schlüssel datenbank nun ein Mapping.

Listen und Mappings lassen sich auch kombinieren. In einer Benutzerliste beginnt jeder Strich einen neuen Benutzer, und die eingerückten Zeilen darunter beschreiben dessen Felder. So erhalten Sie das Array aus Objekten, das Sie aus JSON kennen, ganz ohne Klammern. Der häufigste Fehler ist hier allerdings ein Feld, das nicht exakt mit seinen Geschwistern fluchtet. Steht ein Feld nur ein Leerzeichen zu weit links, meldet der Parser entweder einen Fehler oder hängt die Daten an eine unerwartete Stelle.

Als Faustregel empfehlen wir höchstens drei oder vier Ebenen. Tiefere Strukturen verschlechtern die Lesbarkeit und erhöhen das Risiko von Einrückungsfehlern.

Wie schreiben Sie mehrzeiligen Text in YAML?

Mehrzeiliger Text gehört zu den beliebtesten Eigenschaften von YAML. In JSON müssen Sie Zeilenumbrüche mit Escape Zeichen kodieren. YAML bietet stattdessen zwei Blockstile: den senkrechten Strich | und das Größerzeichen >.

• Literal Block (|): behält Zeilenumbrüche exakt bei. Nutzen Sie ihn für Skripte, Zertifikate oder Texte, bei denen das Layout zählt.
• Gefalteter Block (>): macht aus einfachen Zeilenumbrüchen Leerzeichen und behält Leerzeilen als Absatz. Das passt zu langen Beschreibungen.
• Steuerung des Zeilenendes: |- entfernt den letzten Umbruch, |+ behält alle.
• Einrückung: der Blockinhalt muss tiefer beginnen als sein Schlüssel, sonst endet der Block.

Wollen Sie zum Beispiel in einer CI Datei mehrere Befehle nacheinander ausführen, schreiben Sie run: | und listen die Befehle eingerückt darunter. Dann bleibt jeder Befehl in seiner eigenen Zeile, und die Datei bleibt gut lesbar. Ein gefalteter Block passt dagegen perfekt, wenn Sie einen langen Satz im Editor umbrechen, aber als eine Zeile speichern möchten.

Wer die beiden Zeichen verwechselt, erzeugt allerdings stille Fehler. Die Datei scheitert nicht; nur Ihr Text fügt sich anders zusammen als erwartet. Daher empfehlen wir für Befehlsblöcke fast immer den Literal Block.

Welche Regeln gelten für die Einrückung in YAML?

In YAML ist die Einrückung die Struktur selbst. Deshalb sollten Sie die Regeln genau kennen. Die Spezifikation erlaubt für die Einrückung nur Leerzeichen. Wie viele Leerzeichen Sie nutzen, bleibt Ihnen überlassen. Allerdings müssen alle Geschwister auf derselben Ebene in exakt derselben Spalte beginnen.

1. Rücken Sie nur mit Leerzeichen ein, niemals mit Tabs.
2. Wählen Sie pro Projekt eine Einrückungsbreite; zwei Leerzeichen sind am verbreitetsten.
3. Richten Sie Schlüssel derselben Ebene in derselben Spalte aus.
4. Beginnen Sie Kindelemente mindestens ein Leerzeichen tiefer als das Elternelement.
5. Setzen Sie Listenstriche bündig mit dem Elternschlüssel oder tiefer, und bleiben Sie in der ganzen Datei konsistent.

Der letzte Punkt sorgt oft für Verwirrung. Manche Teams setzen Listenstriche in dieselbe Spalte wie den Elternschlüssel, andere rücken sie zwei Leerzeichen ein. Beide Stile sind also gültig. Probleme beginnen erst, wenn eine Datei beide mischt. In der Praxis ist es am gesündesten, einen Stil festzulegen und ihn mit einem Formatierer oder Linter durchzusetzen.

Zudem empfehlen wir, im Editor die Anzeige unsichtbarer Zeichen einzuschalten. Ein Leerzeichen und einen Tab unterscheiden Sie mit bloßem Auge nicht. Sobald Sie beide sichtbar machen, fangen Sie die Hälfte der Fehler schon beim Tippen ab.

Warum entsteht der YAML Tab Fehler, und wie beheben Sie ihn?

Den Fehler, der uns in YAML Dateien am häufigsten begegnet, verursachen Tabs in der Einrückung. Die offizielle Spezifikation verbietet Tabs für die Einrückung ausdrücklich. Der Grund ist einfach: Verschiedene Editoren zeigen einen Tab unterschiedlich breit an, also könnte dieselbe Datei auf zwei Rechnern wie zwei verschiedene Strukturen aussehen.

Der genaue Fehlertext hängt zudem vom Parser ab. Meist erscheint eine ähnliche Warnung mit Zeile und Spalte, in der der Tab steht. Manche Werkzeuge übersehen den Tab jedoch und bauen eine falsche Struktur; dann zeigt sich das Problem erst viel später in einem ganz anderen Feld. Dieser zweite Fall ist gefährlicher.

1. Springen Sie zur Zeilennummer aus der Fehlermeldung und machen Sie die unsichtbaren Zeichen am Zeilenanfang sichtbar.
2. Wenden Sie den Editorbefehl zum Umwandeln von Tabs in Leerzeichen auf die ganze Datei an.
3. Aktivieren Sie für YAML Dateien dauerhaft die Option, Leerzeichen statt Tabs einzufügen.
4. Legen Sie im Projekt eine .editorconfig Datei an und definieren Sie dort die Einrückung mit Leerzeichen für YAML.
5. Prüfen Sie die Datei anschließend mit einem YAML Validator oder Linter.

Eine Klarstellung: Ein Tab darf durchaus innerhalb eines Wertes stehen, etwa in einem Text in Anführungszeichen. Das Verbot betrifft nur die Einrückung, die die Struktur festlegt. Trotzdem ist es die sicherste Gewohnheit, in YAML Dateien überhaupt keine Tabs zu verwenden.

Welche anderen YAML Fehler passieren am häufigsten?

Neben Tabs sehen wir eine Handvoll Fehler immer wieder. Die meisten davon ergeben sogar eine syntaktisch gültige Datei. Anders gesagt bleibt der Parser still, und nur die Daten stimmen nicht. Nutzen Sie die folgende Liste deshalb als Prüfliste beim Review.

• Fehlendes Leerzeichen nach dem Doppelpunkt: aus schluessel:wert macht der Parser einen einzigen Text.
• Doppelpunkt mit Leerzeichen im Wert: titel: Hinweis: wichtig scheitert, setzen Sie den Wert in Anführungszeichen.
• Werte mit Raute am Anfang: farbe: #ff0000 hält der Parser für einen Kommentar, der Wert bleibt leer.
• Doppelte Schlüssel: die Spezifikation verbietet denselben Schlüssel zweimal auf einer Ebene, manche Parser behalten trotzdem still den letzten.
• Falsch ausgerichtete Listeneinträge: ein Feld zu weit links hängt sich an die höhere Ebene.
• Verwechselte Anführungszeichen: Escape Sequenzen funktionieren in einfachen Anführungszeichen nicht, in doppelten schon.

Doppelte Schlüssel schmerzen vor allem in langen Kubernetes oder CI Dateien. Stellen Sie sich vor, Sie definieren dieselbe Umgebungsvariable oben und noch einmal unten. Bleibt der Parser still, müssen Sie raten, welcher Wert gilt. Deshalb lohnt sich ein Linter, der doppelte Schlüssel findet, sehr schnell.

Was ist das Norwegen Problem, und wie entstehen YAML Typfallen?

Das Norwegen Problem ist die bekannteste Typfalle von YAML. Stellen Sie sich eine Datei mit Ländercodes vor, in der Sie für Norwegen NO schreiben. Ein Parser nach den Regeln von YAML 1.1 liest diesen Wert nicht als Text. Stattdessen liest er ihn als Boolean false, denn YAML 1.1 behandelt auch Wörter wie yes, no, on, off, y und n als Booleans.

YAML 1.2 hat das dann weitgehend behoben. Sein empfohlenes Kernschema kennt als Booleans nur true und false. Dennoch behalten viele beliebte Bibliotheken das ältere Verhalten von 1.1 bei. Prüfen Sie also in der offiziellen Dokumentation Ihrer Bibliothek, welchen Regeln sie folgt.

• Versionsnummern: version: 1.10 kann zur Kommazahl 1.1 werden.
• Führende Nullen: manche Parser lesen Werte wie 0755 als Oktalzahl.
• Zahlen mit Doppelpunkt: in YAML 1.1 kann 22:22 zu einer Zahl im Sechzigersystem werden.
• Texte, die wie ein Datum aussehen: 2024-01-01 kann zu einem Datumsobjekt werden.
• Postleitzahlen und Telefonnummern: führende Nullen können verschwinden.

Die Lösung ist einfach: Setzen Sie jeden Wert, bei dessen Typ Sie unsicher sind, in Anführungszeichen. Ländercodes, Versionen, Postleitzahlen, Telefonnummern und IDs sollten grundsätzlich Anführungszeichen bekommen. So muss der Parser nie raten.

Was ist der Unterschied zwischen YAML und JSON?

YAML und JSON transportieren dasselbe Datenmodell: Mappings, Listen und Skalare. Der Unterschied liegt darin, wie sie dieses Modell als Text schreiben. JSON nutzt geschweifte und eckige Klammern, Kommas und doppelte Anführungszeichen in einem strengen Format. RFC 8259, der JSON Standard, hält diese Regeln eng und klar. YAML stützt sich dagegen auf Einrückung und verhält sich flexibler.

Außerdem kommt ein interessantes Detail hinzu. Die Spezifikation von YAML 1.2 versteht sich als Obermenge von JSON. In der Praxis kann ein Parser für YAML 1.2 also gültiges JSON lesen. Umgekehrt gilt das nicht, denn ein JSON Parser kann keine eingerückte YAML Datei lesen.

Konkret sieht die Aufteilung im Alltag so aus. JSON dominiert den Datenaustausch zwischen Maschinen, etwa bei API Antworten und im Browser. YAML glänzt dagegen in Konfigurationsdateien, die Menschen von Hand pflegen. Zu JSON bei der Authentifizierung lesen Sie unseren Beitrag Was ist JWT. Wie Sie JSON aus KI Modellen erhalten, zeigt unser Leitfaden zu Structured Outputs. Diese Themen wiederholen wir hier nicht.

Kurz gesagt geht es bei der Wahl um den Kontext und nicht um Geschmack. Fragen Sie, wer die Datei schreibt, wer sie liest und wie teuer ein Fehler wäre. Die Antworten zeigen Ihnen das passende Format.

YAML, JSON oder TOML: Welches Format sollten Sie wählen?

Als dritte Option hat sich TOML für Konfigurationen verbreitet. TOML arbeitet mit Abschnittsüberschriften ähnlich wie INI Dateien und hängt nicht von der Einrückung ab. Die folgende Tabelle stellt alle drei Formate nebeneinander.

Konkret lautet unsere Faustregel so. Nutzen Sie JSON, wenn Daten zwischen Programmen wandern. Wählen Sie YAML, wenn Menschen die Datei von Hand bearbeiten und die Verschachtelung tief ist. Greifen Sie zu TOML für flache Einstellungen mit wenigen Ebenen. Außerdem entscheidet oft das Ökosystem für Sie; nutzen Sie Kubernetes oder GitHub Actions, lautet die Antwort ohnehin YAML.

Was ist YAML im Projektalltag, und wo begegnet es Ihnen?

Die meisten Leser, die nach was ist YAML suchen, haben es bereits in irgendeinem Werkzeug gesehen. Die häufigsten Einsatzbereiche sind Konfigurationsdateien, Definitionen für Continuous Integration sowie Container und Orchestrierung.

• Anwendungskonfiguration: viele Web Frameworks speichern Umgebungseinstellungen in YAML.
• CI/CD Pipelines: Sie definieren Build, Test und Deployment Schritte in YAML.
• Docker Compose: eine Datei beschreibt mehrere Container.
• Kubernetes: YAML Manifeste beschreiben Pods, Services und Deployments.
• Automatisierung der Infrastruktur: Playbooks zur Servereinrichtung und Aufgabenlisten.
• Front Matter: statische Seitengeneratoren lesen Titel, Datum und Tags aus YAML am Anfang jedes Beitrags.

Alle diese Werkzeuge haben eines gemeinsam: Die Dateien liegen in der Versionskontrolle, und Menschen bearbeiten sie. Kommentare und das klare Layout von YAML bringen hier echten Mehrwert. Allerdings steuern dieselben Dateien oft direkt die Produktion; ein kleiner Einrückungsfehler kann also teuer werden. Daher sollte die Validierung ein fester Schritt in Ihrem Ablauf sein.

Wie nutzen Sie YAML in CI Dateien?

Continuous Integration bedeutet, dass Ihr Code bei jeder Änderung automatisch baut und Tests durchläuft; das ganze Konzept erklärt unser Beitrag Was ist CI/CD. Für viele Teams ist eine CI Datei der erste Ort, an dem sie fragen, was ist YAML überhaupt. Die meisten beliebten CI Dienste definieren Workflows über YAML Dateien im Repository.

Eine typische CI Datei beginnt mit dem Auslöser, also welcher Branch und welches Ereignis den Lauf starten. Danach folgen die Jobs. Jeder Job nennt seine Laufzeitumgebung und eine geordnete Folge von Schritten. Weil die Schritte eine Liste bilden, beginnt jeder mit einem Strich, und die Befehle schreiben Sie meist in einen Literal Block.

Der häufigste Fehler in CI Dateien ist ein falsch ausgerichtetes Feld in einem Schritt. Beginnt zum Beispiel das Feld run vier statt zwei Leerzeichen unter dem Strich, kann der Parser es einer anderen Ebene zuordnen. In diesem Fall startet der Dienst den Workflow meist gar nicht und zeigt eine ähnliche Warnung zu einer ungültigen Datei.

Noch ein Tipp: Prüfen Sie die CI Datei lokal mit einem Linter, bevor Sie sie hochladen. So verkürzen Sie die Schleife aus Hochladen, Warten, Fehler sehen und Korrigieren. Stoßen Sie dabei beim Installieren eines Python Werkzeugs auf einen Konflikt mit dem Paketmanager des Systems, hilft unser Leitfaden zum Fehler externally managed environment Schritt für Schritt.

Wie sieht YAML in einer Docker Compose Datei aus?

Mit Docker Compose beschreiben Sie eine Anwendung aus mehreren Containern in einer einzigen YAML Datei. Sind Container neu für Sie, beginnen Sie am besten mit unserem Docker Leitfaden.

Eine Compose Datei beginnt meist mit dem Schlüssel services auf oberster Ebene. Darunter erscheint jeder Dienst als Mapping mit eigenem Namen. Jeder Dienst enthält dann Felder wie Image, Portzuordnungen, Umgebungsvariablen und eingebundene Volumes. Ports und Volumes bilden Listen, Umgebungsvariablen schreiben Sie dagegen als Liste oder als Mapping.

Typfallen tauchen in Compose Dateien zudem häufig auf. Schreiben Sie zum Beispiel eine Portzuordnung wie 22:22 ohne Anführungszeichen, kann ein Parser mit dem Verhalten von YAML 1.1 sie als Zahl im Sechzigersystem lesen. Deshalb empfiehlt auch die Docker Dokumentation, Portwerte in Anführungszeichen zu setzen. Ebenso sollten Sie Umgebungswerte wie true oder yes in Anführungszeichen setzen, wenn sie Text bleiben sollen.

Zudem unterstützt Compose die Anker und Aliase von YAML. Sie markieren gemeinsame Einstellungen einmal mit &gemeinsam und verwenden sie in anderen Diensten mit *gemeinsam erneut. Das reduziert Wiederholungen in langen Dateien.

Warum ist YAML in Kubernetes Manifesten so verbreitet?

Kubernetes beschreibt jedes Objekt im Cluster über eine Manifestdatei, und Teams schreiben diese Dateien meist in YAML. Die API selbst spricht im Hintergrund JSON, trotzdem hat sich YAML als Standard für handgeschriebene Manifeste durchgesetzt. Den Unterschied der Rollen beider Werkzeuge erklärt unser Beitrag Docker und Kubernetes im Vergleich.

Jedes Manifest beginnt mit einigen festen Feldern auf oberster Ebene: API Version, Objektart, Metadaten und ein Abschnitt spec, der den gewünschten Zustand beschreibt. Weil diese Struktur tief verschachtelt ist, zählt Disziplin bei der Einrückung hier besonders. Außerdem können Sie mit dem Trenner --- mehrere Dokumente in eine Datei schreiben; ein Deployment und einen Service zusammen abzulegen, ist ein gängiges Muster.

• Die Containerliste beginnt mit einem Strich, und die Felder darunter müssen fluchten.
• Setzen Sie Label Werte, die wie Zahlen oder Booleans aussehen, in Anführungszeichen.
• Schreiben Sie Ressourcenlimits als Text zusammen mit ihrer Einheit.
• Testen Sie die Datei mit der serverseitigen Validierung des Clusters, bevor Sie sie anwenden.

In Kubernetes zeigt sich ein YAML Fehler oft als Meldung im Stil von "unbekanntes Feld". Die übliche Ursache ist ein Feld, das auf die falsche Ebene gerutscht ist. Ein schneller erster Schritt ist also zu prüfen, unter welchem Elternelement das genannte Feld steht.

Ist YAML sicher, und worauf sollten Sie achten?

Was ist YAML aus Sicht der Sicherheit? YAML selbst ist zunächst nur ein Datenformat. Allerdings unterstützen manche Parser erweiterte Typ Tags, mit denen sie aus einer Datei Objekte der Programmiersprache erzeugen. Lädt man eine nicht vertrauenswürdige Datei in diesem vollen Modus, kann das unerwartetem Code die Tür öffnen. Deshalb bieten die meisten Bibliotheken einen eingeschränkten Modus, meist als sicheres Laden bezeichnet.

Eine verbreitete YAML Bibliothek für Python empfiehlt zum Beispiel die Funktion safe_load, die nur Grundtypen erzeugt. Bibliotheken in anderen Sprachen haben einen ähnlichen sicheren Modus. Die Regel bleibt einfach: Laden Sie externe Daten immer im sicheren Modus.

• Öffnen Sie YAML von Nutzern oder Dritten nur mit sicherem Laden.
• Speichern Sie Passwörter und API Schlüssel nicht im Klartext in YAML; nutzen Sie stattdessen Umgebungsvariablen oder einen Secrets Manager.
• Riesige Ketten aus Ankern und Aliasen können den Speicher sprengen; setzen Sie Größenlimits.
• Prüfen Sie Konfigurationsdateien auf Geheimnisse, bevor Sie sie in die Versionskontrolle aufnehmen.

Kurz gesagt ist YAML sicher, aber der Code, der es liest, bleibt nur mit den richtigen Einstellungen sicher. Die Verantwortung liegt darin, wie Sie den Parser aufrufen, und nicht in der Datei.

Wie validieren Sie eine YAML Datei und finden Fehler?

Am günstigsten fangen Sie YAML Fehler im Editor ab und nicht in der Produktion. Dafür empfehlen wir eine Prüfung in drei Schichten: Editor, Linter und Schema.

• Editor: ein Editor mit YAML Erweiterung hebt die Einrückung hervor, markiert Tabs und zeigt Syntaxfehler sofort.
• Linter: er meldet doppelte Schlüssel, Zeilenlänge, uneinheitliche Einrückung und Leerzeichen am Zeilenende.
• Schemaprüfung: sie kontrolliert, ob die Datei die erwarteten Felder und korrekte Typen enthält. JSON Schema funktioniert auch für YAML.
• Prüfung im Werkzeug: Compose, Kubernetes und CI Dienste liefern meist eigene Befehle zur Validierung.

Bei der Fehlersuche springen Sie zunächst zu Zeile und Spalte aus der Fehlermeldung. Dann vergleichen Sie die Ausrichtung der Zeilen direkt darüber und darunter. YAML Fehler beginnen nämlich oft eine Zeile vor der gemeldeten. Danach setzen Sie verdächtige Werte in Anführungszeichen, um Typprobleme auszuschließen.

Noch ein Tipp: Die Datei in JSON umzuwandeln ist sehr lehrreich. So sehen Sie mit expliziten Klammern, wie der Parser Ihre Struktur tatsächlich verstanden hat.

Wie helfen KI Werkzeuge beim Schreiben von YAML?

Coding Assistenten schreiben YAML recht zuverlässig, denn diese Dateien wiederholen bekannte Muster. Konkret lässt sich das Gerüst einer Compose Datei oder eines CI Workflows aus einer kurzen Beschreibung erstellen. Wie Sie diesen Ablauf mit einem Assistenten im Terminal steuern, zeigt unser Leitfaden Was ist Claude Code.

Trotzdem raten wir davon ab, erzeugtes YAML blind zu übernehmen. Assistenten schlagen manchmal einen veralteten Feldnamen, einen nicht mehr unterstützten Schlüssel oder eine falsche Einrückung vor. Zudem übersehen sie gelegentlich Typfallen wie das Norwegen Problem. Deshalb durchlaufen auch erzeugte Dateien dieselben Prüfungen mit Linter und Schema.

Unsere eigene Routine sieht so aus. Der Assistent schreibt den ersten Entwurf, eine Person aus dem Team liest die Datei Zeile für Zeile, und dann läuft die automatische Validierung. So gewinnen Sie Tempo, ohne die Kontrolle zu verlieren.

Welche Checkliste hilft Ihnen beim Schreiben von YAML?

Wir haben geklärt, was YAML ist, wie es funktioniert und wo es bricht. Jetzt machen wir daraus eine kurze Liste für jeden Tag. Unser Team prüft diese Punkte einzeln, bevor wir eine neue Konfigurationsdatei freigeben.

1. Die Einrückung nutzt nur Leerzeichen, keine Tabs.
2. Die ganze Datei nutzt eine einzige Einrückungsbreite.
3. Schlüssel derselben Ebene beginnen in derselben Spalte.
4. Nach jedem Doppelpunkt steht ein Leerzeichen.
5. Ländercodes, Versionen, Postleitzahlen, Ports und IDs stehen in Anführungszeichen.
6. Textwerte mit Raute oder Doppelpunkt stehen in Anführungszeichen.
7. Die Datei enthält keine doppelten Schlüssel.
8. Befehlsblöcke nutzen Literal Blöcke.
9. Geheimnisse stehen nirgends im Klartext.
10. Die Datei besteht Linter und Schemaprüfung.

Diese Liste spart somit selbst kleinen Teams viel Zeit. Möchten Sie Konfigurationsdateien, CI Pipelines oder Deployment Abläufe neu aufsetzen, arbeiten wir gern im Rahmen unserer individuellen Softwareentwicklung mit Ihnen zusammen. Wenn Sie verstehen möchten, wie der Datenaustausch auf API Seite funktioniert, ist unser Beitrag Was ist eine API ein guter nächster Schritt.

Wo sollten Sie anfangen, YAML zu lernen?

Am schnellsten lernen Sie YAML, wenn Sie eine kleine Datei schreiben, sie in JSON umwandeln und das Ergebnis betrachten. Probieren Sie zuerst ein Mapping, dann eine Liste und danach eine verschachtelte Struktur. Prüfen Sie bei jedem Schritt die Ausgabe des Parsers. So sehen Sie mit eigenen Augen, wann die Einrückung die Bedeutung ändert.

Als Nächstes lesen Sie die Beispieldateien der Werkzeuge, die Sie nutzen. Die offiziellen Dokumentationen von Compose, Kubernetes und CI Diensten enthalten viele Beispiele. Sie zeigen den korrekten Einsatz der Sprache und des Schemas, das das jeweilige Werkzeug erwartet. Danach vergleichen Sie die Dateien in Ihrem Projekt mit diesen Beispielen.

Schließlich überfliegen Sie die Kernteile der Spezifikation. Sie müssen nicht alles lesen; Skalartypen, Blockstile und Einrückungsregeln genügen. Möchten Sie strukturierte Daten auf Webseiten üben, hilft Ihnen unser Schema Generator beim Arbeiten mit JSON-LD. Zusammengefasst ist die Antwort auf die Frage, was ist YAML, kurz; die Sprache gut zu beherrschen, braucht dennoch regelmäßige Übung.