YAML erklärt: Die Config-Sprache, die aussieht wie ein Gedicht

In einem Satz

YAML ist eine menschenfreundliche Art, strukturierte Daten zu schreiben, die die geschweiften Klammern und Anführungszeichen seiner Cousins gegen die sauberen Einrückungen einer gut organisierten Einkaufsliste eintauscht.

Das Problem, das es löst

Am Anfang war das Chaos. Dann kamen die Konfigurationsdateien. Frühe Formate wie .ini waren einfach, konnten aber keine komplexen, verschachtelten Daten verarbeiten. Dann kam XML, mächtig und strukturiert, aber so wortreich und tag-lastig, dass es sich beim Lesen anfühlte, als würde man IKEA-Möbel mit einer Anleitung in Juristendeutsch zusammenbauen. Menschen hassten es, es zu schreiben.

Als Nächstes kam JSON (JavaScript Object Notation) und war eine riesige Verbesserung. Es war leichtgewichtig, ließ sich direkt auf Datenstrukturen in den meisten Programmiersprachen abbilden und war viel augenfreundlicher als XML. Aber für Dateien, die Menschen sehr oft schreiben und bearbeiten mussten – wie DevOps-Skripte, Anwendungseinstellungen und Internationalisierungstexte – fühlte sich die Syntax von JSON immer noch wie eine lästige Pflicht an. All die geschweiften Klammern, Kommas und Anführungszeichen waren visuelles Rauschen und man konnte sie leicht versemmeln.

Bühne frei für YAML. Der Name ist ein rekursives Akronym, das seinen Geist perfekt einfängt: „YAML Ain't Markup Language.“ Es wurde von Grund auf für ein Hauptpublikum entwickelt: den Menschen, der auf den Bildschirm starrt. Es nahm die gleichen grundlegenden Datenstrukturen wie JSON (Schlüssel-Wert-Paare, Listen und einfache Werte) und fragte: „Was ist die absolut minimale Syntax, die wir benötigen, um dies darzustellen?“

Die Antwort war Einrückung. Durch die Verwendung von Leerzeichen zur Kennzeichnung der Struktur schuf YAML ein Format, das oft sauber genug ist, um sich selbst zu dokumentieren. Es wurde für die Welt der Konfiguration geschaffen, in der Klarheit und einfache Bearbeitung wichtiger sind als die maschinelle Optimierung einer high-throughput API.

Wie es unter der Haube funktioniert

Die „Magie“ von YAML ist nur ein einfacher, konsistenter Satz von Regeln, um eingerückten Text in strukturierte Daten umzuwandeln. Es ist ein Superset von JSON, was bedeutet, dass man oft valides JSON in eine YAML-Datei einfügen kann und es einfach funktioniert. Aber die wahre Stärke liegt in seiner nativen, minimalistischen Syntax.

Die Bausteine: Skalare, Sequenzen und Mappings

Alle Daten in YAML lassen sich auf drei Dinge reduzieren:

Mappings (auch Dictionaries oder Objekte genannt): Das sind deine klassischen key: value-Paare. Der Schlüssel (key) ist ein String, und der Wert (value) kann alles sein: ein weiteres Mapping, eine Sequenz oder ein Skalar.
```
# Ein einfaches Mapping
character: "Bilbo Baggins"
race: "Hobbit"
age: 111
```
Sequenzen (auch Listen oder Arrays genannt): Das sind geordnete Listen von Elementen. Jedes Element wird durch einen Bindestrich und ein Leerzeichen (- ) gekennzeichnet.
```
# Eine Sequenz von Strings
fellowship_members:
  - Frodo Baggins
  - Samwise Gamgee
  - Gandalf
  - Legolas
  - Gimli
```
Skalare (auch einfache Werte genannt): Das ist nur ein einzelner Wert, wie ein String, eine Zahl oder ein Boolean. YAML ist ziemlich clever darin, den Typ zu erraten. 123 ist eine Zahl, true ist ein Boolean und Hello world ist ein String. Normalerweise brauchst du keine Anführungszeichen, aber du solltest sie verwenden, wenn dein String falsch interpretiert werden könnte (z. B. "true", "1.23").

Die Geheimzutat: Einrückung und Leerräume (Whitespace)

Das ist das wichtigste Konzept in YAML. Es gibt keine geschweiften Klammern {} oder eckigen Klammern [], um Verschachtelungen anzuzeigen. Stattdessen rückt man einfach ein. Die Regel ist einfach: Wenn eine Zeile stärker eingerückt ist als die Zeile darüber, wird sie zu einem Kind-Element dieser Zeile.

Kombinieren wir unsere Bausteine. Hier ist ein Charakterprofil mit einer Liste von Inventargegenständen.

# Eine verschachtelte Struktur
character:
  name: "Gollum"
  aliases:
    - "Sméagol"
    - "My Precious"
  possessions:
    - item: "The One Ring"
      description: "A plain gold ring, surprisingly heavy."
    - item: "A fish"
      description: "Juicy and sweet!"
  is_wretched: true

Schau dir die Struktur an. name, aliases, possessions und is_wretched sind alles Eigenschaften von character, weil sie darunter eingerückt sind. Die aliases-Sequenz ist ein Wert innerhalb des character-Mappings. Die possessions-Sequenz enthält zwei Mapping-Objekte, jedes mit einem item und einer description.

Die Tiefe der Einrückung spielt keine Rolle, solange sie innerhalb desselben Blocks konsistent ist. Zwei Leerzeichen sind der Community-Standard. Aber du musst Leerzeichen verwenden, keine Tabs. Tabs zu verwenden ist der todsichere Weg, sich unsichtbaren Schmerz zuzufügen.

Fortgeschrittene Tricks: Anker, Aliase und Tags

YAML hat einige Power-User-Features, die JSON fehlen, und die dafür gemacht sind, deine Dateien DRY (Don't Repeat Yourself) zu halten.

Anker (&) und Aliase (*): Wenn du einen Datenblock hast, den du wiederverwenden musst, kannst du ihm mit einem Anker (&anker_name) einen Namen geben und ihn dann an anderer Stelle mit einem Alias (*anker_name) referenzieren.

# Definiere ein Standard-Benutzerprofil mit einem Anker
default_user: &default_user_profile
  theme: "dark"
  notifications: "enabled"
  permissions: "read-only"

# Erstelle nun spezifische Benutzer, die die Standardwerte erben
users:
  - name: "Alice"
    # Verwende einen Alias, um das Standardprofil zu übernehmen
    <<: *default_user_profile
    # Und überschreibe einen bestimmten Key
    permissions: "admin"
  - name: "Bob"
    # Bob erhält das Standardprofil
    <<: *default_user_profile

Hier ist << ein spezieller Merge Key. Sowohl Alice als auch Bob erhalten das Standardprofil, aber Alices permissions-Key wird überschrieben. Das ist ein Lebensretter in komplexen Konfigurationen.

Tags (!!): YAML leitet normalerweise die Typen ab (Type Inference), aber mit Tags kannst du explizit sein. Das kann nützlich sein, um Mehrdeutigkeiten zu vermeiden. Zum Beispiel, wenn du den String "12.0" und nicht die Zahl 12.0 haben möchtest.
```
version: !!str 12.0 # Erzwingt, dass dies ein String ist
not_a_boolean: !!str "no" # Erzwingt, dass dies ein String ist
```

Geschichten aus der Praxis

Der Fall der verschwundenen Pipeline

Eine Junior-DevOps-Ingenieurin, nennen wir sie Chloe, sollte einen neuen Security Scan zur CI/CD-Pipeline ihres Unternehmens hinzufügen, die in einer gitlab-ci.yml-Datei definiert war. Sie fügte den neuen Job hinzu, pushte ihren Code und... nichts. Die Pipeline lief, aber ihr neuer Scan-Job war nirgends zu finden. Er schlug nicht fehl; er war einfach verschwunden. Zwei Stunden lang überprüfte Chloe ihre Skript-Syntax, die Runner-Konfiguration und die Phasendefinitionen. Schließlich bat sie entnervt einen Senior-Entwickler, einen Blick darauf zu werfen. Dessen Augen überflogen die Datei für etwa fünf Sekunden, bevor er auf eine einzige Zeile zeigte. Chloe hatte ihren neuen Job mit drei Leerzeichen eingerückt, anstatt der zwei, die überall sonst verwendet wurden. Der YAML-Parser sah dies als fehlerhaftes Kind-Element des vorherigen Jobs, nicht als neuen Top-Level-Job, und ignorierte es stillschweigend.

Lektion: In YAML ist Whitespace Syntax. Ein einziges falsch platziertes Leerzeichen kann die gesamte Bedeutung deiner Datei verändern. Verwende einen Linter oder einen strukturierten Editor, der den Datenbaum visualisiert, um solche Fehler sofort zu finden.

Die Config, die zu einem Wald wurde

Ein kleines Startup verwaltete seine Anwendungs-Environments (Development, Staging, Production) mit einer einzigen config.yml. Am Anfang war es einfach. Aber als sie weitere Environments hinzufügten (prod-us, prod-eu, dev-feature-x), explodierte die Datei. Riesige Konfigurationsblöcke für Datenbank-URLs, API-Keys und Feature-Flags wurden für jedes Environment kopiert und eingefügt, mit nur geringfügigen Änderungen. Die Datei wurde zu einem 500-Zeilen-Monster, und das Ändern eines einzigen gemeinsamen Wertes, wie z. B. einer Timeout-Einstellung, erforderte das Suchen und Ersetzen an fünf verschiedenen Stellen. Ein neuer Mitarbeiter, frisch von einem größeren Unternehmen, sah das und führte YAML-Anker ein. Er definierte einen &default_config-Block mit allen gemeinsamen Einstellungen. Danach hat die Konfiguration jedes Environments einfach den Standard per Alias eingebunden (<<: *default_config) und die wenigen abweichenden Werte überschrieben. Die 500-Zeilen-Datei schrumpfte auf unter 100 Zeilen.

Lektion: Wiederhole dich nicht (Don't Repeat Yourself). Wenn du merkst, dass du große Blöcke in einer YAML-Datei kopierst und einfügst, ist es Zeit, Anker und Aliase zu lernen und zu verwenden.

Das Norwegen-Problem

Ein Entwickler baute ein Feature, mit dem Benutzer ihr Land aus einem Dropdown-Menü auswählen konnten. Die Liste der Ländercodes wurde in einer einfachen YAML-Datei gespeichert: supported_countries: [ US, DE, UK, NO ]. Beim Testen beschwerten sich Benutzer aus Norwegen (NO), dass sie sich nicht registrieren konnten. Der Entwickler debuggte den Code stundenlang, verfolgte Variablen, konnte aber das Problem nicht finden. Der Wert NO wurde vom Frontend korrekt übergeben. Schließlich untersuchte er die Daten, die aus der YAML-Datei geladen wurden. Das supported_countries-Array in seinem Programm war ['US', 'DE', 'UK', false]. Der YAML-Parser hatte, einer älteren Version der Spezifikation folgend, das nicht in Anführungszeichen gesetzte NO als booleschen Wert für „false“ interpretiert.

Lektion: Im Zweifelsfall setze deine Strings in Anführungszeichen. Jeder Skalar, der wie eine Zahl ("1.0"), ein Boolean ("yes", "no", "on", "off") oder ein spezieller Wert aussehen könnte, sollte explizit in Anführungszeichen gesetzt werden, um eine Überraschung beim Parsen zu vermeiden.

Häufige Fehler und Fallen

Tabs statt Leerzeichen verwenden. Das ist die Kardinalsünde in YAML. Die Spezifikation verbietet Tabs. Da sie unsichtbar sind, können sie Parsing-Fehler verursachen, die wahnsinnig schwer zu finden sind. Konfiguriere deinen Editor so, dass er für YAML-Dateien Leerzeichen verwendet.
Inkonsistente Einrückung. Wenn ein Listenelement um zwei Leerzeichen und das nächste um vier eingerückt ist, wirst du eine harte Zeit haben. Die Struktur wird falsch geparst. Halte die Einrückungsebenen konsistent.
Vergessen, mehrdeutige Strings in Anführungszeichen zu setzen. Das „Norwegen-Problem“ ist ein Klassiker. Strings wie Yes, No, true, false, On, Off werden als Booleans geparst. Zahlen mit führenden Nullen oder Sonderzeichen könnten falsch geparst werden. Im Zweifelsfall, pack sie in "Anführungszeichen".
Verwirrung bei mehrzeiligen Strings. Den Unterschied zwischen | (literal style, erhält Zeilenumbrüche) und > (folded style, wandelt Zeilenumbrüche in Leerzeichen um) zu vergessen. Das kann dazu führen, dass dein sorgfältig formatierter Textblock oder dein Shell-Skript verstümmelt wird.
Unerwartete null-Werte. Ein Key, auf den nach dem Doppelpunkt nichts folgt (key: ), ist ein null-Wert. Das ist oft eine versehentliche Löschung und kann zu stillen Fehlern führen, wenn dein Code nicht auf null prüft.

Warum du es auf dem Schirm haben solltest

Wenn du 2024 Code schreibst, kommst du an YAML nicht vorbei. Es ist der unangefochtene König der Konfiguration.

DevOps & Infrastructure-as-Code: Kubernetes, Ansible, Docker Compose, GitHub Actions, AWS CloudFormation und unzählige andere Tools verwenden YAML als ihre primäre Definitionssprache.
Anwendungskonfiguration: Viele Frameworks (wie Symfony und Ruby on Rails) und Anwendungen verwenden YAML für Einstellungsdateien, weil es für Entwickler so einfach zu lesen und zu ändern ist.
Static Site Generators: Tools wie Jekyll und Hugo verwenden YAML für „Frontmatter“, um Metadaten für Posts und Seiten zu definieren.

YAML zu kennen bedeutet nicht nur, Konfigurationsdateien zu schreiben. Es geht darum, die Struktur der Systeme zu verstehen, mit denen du arbeitest. Einen subtilen Einrückungsfehler zu erkennen oder zu wissen, wann man einen Anker verwendet, kann den Unterschied zwischen einem schnellen Fix und einem ganzen Tag bedeuten, der mit Debugging verloren geht.

Tauche tiefer ein

YAML Spec 1.2.2: Die offizielle Quelle der Wahrheit. Sie ist dicht geschrieben, aber die ultimative Referenz.
Wikipedia: YAML: Ein großartiger Überblick über die Geschichte, die Features und die Versionen der Sprache.
Learn YAML in Y minutes: Ein fantastisches, einseitiges Cheatsheet mit Live-Beispielen, das 80 % von allem abdeckt, was du jemals brauchen wirst.
YAML Lint: Ein Online-Validator, der von unschätzbarem Wert ist, um diese nervigen Syntaxfehler zu finden und zu verstehen, was der Parser „sieht“.
GitHub Docs: Workflow syntax for GitHub Actions: Ein exzellentes Praxisbeispiel für ein komplexes System, das vollständig in YAML definiert ist. Wenn du es studierst, wirst du viele gängige Muster erkennen.