YAML Anchors und Aliases: DRY-Konfigurationsmuster

Das Wiederholen derselben Konfiguration in mehreren Abschnitten einer YAML-Datei verstößt gegen das DRY-Prinzip (Don't Repeat Yourself) und verursacht Wartungsprobleme. YAML-Anchors und Aliases lösen dies, indem Sie einen Wert einmal definieren und mehrfach referenzieren können.

Grundlegende Syntax

Anchor (&): Markiert einen Wert zur Wiederverwendung Alias (*): Referenziert einen verankerten Wert

# Einen Anchor definieren
defaults: &default_settings
  timeout: 30
  retries: 3
  log_level: info

# Aliases verwenden, um darauf zu verweisen
development:
  <<: *default_settings
  log_level: debug

production:
  <<: *default_settings
  retries: 5

Der << Merge-Key übernimmt alle Schlüssel-Wert-Paare aus dem referenzierten Anchor. Eigenschaften, die nach dem Merge definiert werden, überschreiben die Anchor-Werte.

Ergebnis nach Auflösung:

development:
  timeout: 30
  retries: 3
  log_level: debug  # überschrieben

production:
  timeout: 30
  retries: 5        # überschrieben
  log_level: info

Anchor-Typen

Skalare Anchors

Einen einzelnen Wert wiederverwenden:

max_connections: &max_conn 100

database:
  pool_size: *max_conn
cache:
  pool_size: *max_conn

Sequenz-Anchors

Ganze Listen wiederverwenden:

common_ports: &ports
  - 80
  - 443

web_server:
  ports: *ports
load_balancer:
  ports: *ports

Mapping-Anchors

Ganze Objekte wiederverwenden (das häufigste Muster):

logging: &log_config
  driver: json-file
  options:
    max-size: "10m"
    max-file: "3"

services:
  api:
    logging: *log_config
  worker:
    logging: *log_config

Der Merge-Key (`<<`)

Der Merge-Key hat ein spezifisches Verhalten:

Er kopiert alle Schlüssel-Wert-Paare aus dem referenzierten Mapping
Explizit gesetzte Schlüssel haben Vorrang vor zusammengeführten Schlüsseln
Mehrere Merges werden in Reihenfolge verarbeitet (der erste gewinnt bei Konflikten)

# Mehrere Merges
base: &base
  a: 1
  b: 2

extra: &extra
  b: 3
  c: 4

combined:
  <<: [*base, *extra]
  # Ergebnis: a=1, b=2 (base gewinnt), c=4

Praxisbeispiele

Docker Compose

x-common: &common
  restart: unless-stopped
  networks:
    - app-network
  logging:
    driver: json-file
    options:
      max-size: "10m"

services:
  api:
    <<: *common
    image: myapp/api:latest
    ports:
      - "8080:8080"
    environment:
      DATABASE_URL: postgres://db:5432/myapp

  worker:
    <<: *common
    image: myapp/worker:latest
    environment:
      QUEUE_URL: redis://cache:6379

  scheduler:
    <<: *common
    image: myapp/scheduler:latest

Docker Compose verwendet die x--Präfix-Konvention für Erweiterungsfelder, die Anchors enthalten. Weitere Muster finden Sie in unserem Leitfaden YAML für Docker Compose.

GitHub Actions

jobs:
  test:
    runs-on: ubuntu-latest
    env: &common_env
      NODE_VERSION: '20'
      CI: true
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: ${{ env.NODE_VERSION }}
      - run: npm test

  build:
    runs-on: ubuntu-latest
    needs: test
    env:
      <<: *common_env
      BUILD_TARGET: production
    steps:
      - uses: actions/checkout@v4
      - run: npm run build

Kubernetes

apiVersion: apps/v1
kind: Deployment
spec:
  template:
    spec:
      containers:
        - name: app
          resources: &resources
            requests:
              cpu: 100m
              memory: 128Mi
            limits:
              cpu: 500m
              memory: 512Mi
        - name: sidecar
          resources: *resources  # Gleiche Ressourcenlimits

Einschränkungen und Fallstricke

1. Keine dateiübergreifenden Referenzen

Anchors funktionieren nur innerhalb einer einzelnen YAML-Datei. Sie können keinen Anchor referenzieren, der in einer anderen Datei definiert ist. Für dateiübergreifende Wiederverwendung verwenden Sie Templating-Werkzeuge wie Helm, Jsonnet oder Kustomize.

2. Keine teilweisen Überschreibungen in Sequenzen

Sie können eine Liste nicht zusammenführen und teilweise überschreiben — Sie ersetzen die gesamte Liste:

base_ports: &ports
  - 80
  - 443

service:
  ports: *ports  # Sie erhalten genau [80, 443]
  # Port 8080 kann nicht über Merge hinzugefügt werden

Workaround: Die erweiterte Liste separat definieren.

3. Reihenfolge ist wichtig

Anchors müssen definiert werden, bevor sie referenziert werden:

# FALSCH - Alias vor Anchor
service:
  settings: *defaults

defaults: &defaults
  timeout: 30

# RICHTIG - Anchor vor Alias
defaults: &defaults
  timeout: 30

service:
  settings: *defaults

4. Nicht alle Werkzeuge unterstützen Merge-Keys

Der << Merge-Key ist nicht Teil der YAML-Kernspezifikation — er ist eine typspezifische Erweiterung. Die meisten populären YAML-Parser unterstützen ihn, aber einige strikte Parser möglicherweise nicht.

Validieren Sie Ihre YAML-Anchor-Nutzung mit unserem YAML Validator.

FAQ

Bleiben Anchors beim Konvertieren von YAML zu JSON erhalten?

Nein. Wenn YAML geparst wird, werden Anchors und Aliases in ihre Werte aufgelöst. Das resultierende JSON hat die Werte inline expandiert. Das bedeutet, eine Konvertierung zu JSON und zurück verliert die DRY-Struktur. Die Anchors existieren nur im YAML-Quellformat.

Kann ich Anchors mit komplexen verschachtelten Überschreibungen verwenden?

Der Merge-Key (<<) führt nur einen flachen Merge durch — er kopiert Schlüssel der obersten Ebene aus dem verankerten Mapping. Verschachtelte Objekte werden vollständig ersetzt, nicht tief zusammengeführt. Für tiefes Merge-Verhalten benötigen Sie eine werkzeugspezifische Lösung (Helms merge-Funktion, benutzerdefinierte YAML-Prozessoren).