Begriff
YAML (YAML Ain't Markup Language)
Warum wichtig?
Dieser Begriff ist ein Knoten im SengakujiWorks-Wissensnetz. Nutze Level 0 für die erste Einordnung, Level 1 für Praxis, Level 2 für technische Struktur und Level 3 für Grenzen, Fallstricke und Expertenkontext.
Computer mögen JSON (viele Klammern, schwer zu lesen).
Menschen mögen Listen und Einrückungen.
YAML ist ein Datenformat, das für Menschen gemacht ist.
Keine geschweiften Klammern {}. Keine Anführungszeichen (meistens).
Stattdessen: Einrückung (Indentation).
Es wird fast überall in der modernen IT für Konfigurationen genutzt (Kubernetes, Docker Compose, Ansible, GitHub Actions).
Oft scherzhaft: "Yet Another Markup Language" (aber offiziell heißt es "YAML Ain't Markup Language").
Merksatz: Ein menschenlesbares Format zur Datenserialisierung, das auf Einrückungen basiert und häufig für Konfigurationsdateien in DevOps-Tools verwendet wird.
Vergleich JSON vs. YAML:
JSON:
{
"server": {
"port": 80,
"admin": ["max", "moritz"]
}
}
YAML:
server:
port: 80
admin:
- max
- moritz
Regel Nr. 1: Niemals Tabs benutzen! Immer Leerzeichen (Spaces). Meistens 2 pro Ebene.
1. Das Norwegen-Problem (Typisierung)
YAML versucht schlau zu sein und Typen zu raten (Auto-Typing). Ländercodes:
US-> String "US".DE-> String "DE".NO-> Boolean False! (Weil "NO" als "No" interpretiert wird). Lösung: Strings immer in Quotes setzen:'NO'. (In YAML 1.2 wurde das behoben, aber viele Tools nutzen noch parser für 1.1).
2. Anchors & Aliases
Ein mächtiges Feature, das JSON fehlt. Man kann Werte wiederverwenden (DRY - Don't Repeat Yourself).
defaults: &base_settings
timeout: 30
retries: 5
production:
<<: *base_settings # Erbt alles von defaults
host: prod.com
Sehr nützlich in CI/CD Pipelines (GitLab CI), um riesige Dateien klein zu halten.
3. Multi-Document Support
Man kann mehrere YAML-Dateien in eine einzige Datei packen, getrennt durch ---.
Kubernetes liebt das.
deployment.yaml --- service.yaml alles in einer Datei.
1. Die "Billion Laughs" Attacke (YAML Edition)
Genau wie XML ist auch YAML anfällig für Ressourcen-Angriffe.
Durch die Verwendung von Aliases (*) und Anchors (&) kann man eine kleine Datei bauen, die beim Entpacken (Parsen) im Speicher explodiert.
a: &a ["lol","lol","lol","lol","lol"]
b: &b [*a,*a,*a,*a,*a]
c: &c [*b,*b,*b,*b,*b]
Ein paar Zeilen Text können so Gigabytes an RAM verbrauchen. Sicherheits-Tipp: Nutze in Web-Services immer Parser, die die Anzahl der Aliases oder die Tiefe der Verschachtelung begrenzen.
2. Custom Tags (!!str, !!int)
YAML ist eigentlich "Typed". Wenn du port: 80 schreibst, erkennt der Parser automatisch !!int.
Du kannst das erzwingen oder sogar eigene Typen definieren:
created: !!timestamp 2024-01-01
command: !!python/object/apply:os.system ["ls"]
Der zweite Fall (!!python/...) ist brandgefährlich! Er erlaubt es, beim bloßen Laden der YAML-Datei Befehle auf dem Server auszuführen. Deshalb: Niemals yaml.load() auf User-Daten anwenden, sondern immer yaml.safe_load().
3. Indentation & Flow Style
YAML hat zwei Gesichter:
- Block Style: Die klassische Einrückung mit Zeilenumbrüchen (sehr lesbar).
- Flow Style: Nutzt Klammern wie JSON:
port: 80, users: [max, moritz]. Da Flow-Style gültiges YAML ist, kannst du JSON-Teile mitten in deine YAML-Datei kopieren und es funktioniert. Das ist nützlich, wenn man sehr kompakte Listen braucht, die in einer Zeile bleiben sollen.
Quick-Check
Superset von JSON?
Ja! Jedes gültige JSON ist auch gültiges YAML. Du kannst{ "foo": "bar" }einfach in eine YAML-Datei schreiben. (Umgekehrt nicht).Kommentare?
Ja, mit#. JSON kann offiziell keine Kommentare. Das ist einer der Hauptgründe, warum Configs YAML nutzen (man kann erklären, warum eine Einstellung so ist).Sicherheitsrisiko?
Ja, in manchen Sprachen (Python/Ruby) war der Standard-YAML-Parser unsicher (yaml.load()), weil er Code ausführen konnte (Objekt-Deserialisierung). Nutze immersafe_load().