YAML
A human-readable data serialization language commonly used for configuration files, CI/CD pipelines, and infrastructure-as-code.
Detailed Explanation
YAML (YAML Ain't Markup Language) is a data format designed to be easy for humans to read and write. It uses indentation (like Python) to define structure, making it more readable than JSON for configuration. YAML supports scalars, lists, mappings, and anchors (reusable values).
YAML is the standard for: GitHub Actions workflows, Docker Compose, Kubernetes manifests, Ansible playbooks, CI/CD configuration, and application config files. Despite its popularity, YAML has pitfalls: indentation sensitivity, implicit type conversion, and the "Norway problem" (the string "NO" can be interpreted as boolean false).
Why It Matters
YAML is the dominant configuration format in DevOps and CI/CD. Understanding its syntax and pitfalls is essential for working with modern infrastructure tools.
Real-World Example
A GitHub Actions workflow in YAML: `name: CI on: push jobs: build: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - run: npm test`
When to Use
For configuration files, CI/CD pipelines, Docker Compose, Kubernetes manifests, and infrastructure-as-code. Avoid for data exchange where JSON is more standard.
Advantages
- Human-readable and writable
- Supports comments (unlike JSON)
- Supports anchors for reusable values
- Industry standard for DevOps config
- More expressive than JSON for config
Disadvantages
- Indentation sensitivity causes errors
- Implicit type conversion (Norway problem)
- Complex parsing can be slow
- No strict schema validation
- Inconsistent implementations across parsers
Related Terms
Frequently Asked Questions
What is the difference between YAML and JSON?
YAML is more human-readable (indentation-based, supports comments). JSON is stricter and more universally supported. YAML is better for config files; JSON is better for data exchange and APIs.
Why does YAML have the Norway problem?
YAML 1.1 auto-converts certain strings to types: "yes" → true, "no" → false, "on" → true, "off" → false. So the string "NO" becomes boolean false. YAML 1.2 fixed this, but many parsers still use 1.1.
How do I avoid YAML indentation errors?
Use 2 spaces consistently (never tabs), validate YAML before committing, use an IDE plugin with linting, and keep indentation simple. Tools like yamllint catch issues early.
Can YAML reference other values?
Yes, using anchors and aliases: `default: &default { color: red }` then `custom: *default` copies the value. Also supports merge keys: `custom: { <<: *default, color: blue }` overrides specific fields.
Should I use YAML for my application config?
YAML is good for config files that humans edit (CI/CD, Docker, Kubernetes). For application config, also consider TOML (simpler) or environment variables (more portable). JSON is better for machine-generated config.