Was sind HCL und HOCON? Konfigurationssprachen erklärt

HCL steht für HashiCorp Configuration Language. Es ist eine domänenspezifische Konfigurationssprache, die HashiCorp 2014 entwickelt hat, zunächst zur Unterstützung von Terraform. HCL-Dateien nutzen die Endung `.hcl` (oder `.tf` speziell für Terraform) und sind darauf ausgelegt, für Menschen lesbar, für Maschinen parsebar und JSON-kompatibel zu sein – jedes gültige JSON-Dokument ist auch gültiges HCL.

HCL ist keine Programmiersprache. Es kann nicht rechnen, keine Funktionen definieren und den Programmfluss nicht steuern wie Python oder JavaScript. Es ist eine deklarative Konfigurationssprache: Du beschreibst den gewünschten Zustand der Infrastruktur, und das Werkzeug, das HCL liest (Terraform, Packer, Vault, Consul, Nomad), entscheidet, wie dieser erreicht wird. Diese Einschränkung ist gewollt – sie macht HCL-Konfigurationen vorhersehbar und prüfbar.

Grundlagen der HCL-Syntax

HCL nutzt eine blockbasierte Struktur mit Attributen, verschachtelten Blöcken und Ausdrücken. Attribute sind Schlüssel-Wert-Paare; Blöcke gruppieren zusammengehörige Attribute und können verschachtelt werden. Kommentare nutzen `#` oder `//` für eine Zeile und `/* */` für mehrere.

# Einzeiliger Kommentar
resource "aws_instance" "web" {
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "t3.micro"

  tags = {
    Name        = "web-server"
    Environment = "production"
  }

  # Verschachtelter Block
  root_block_device {
    volume_size = 20
    encrypted   = true
  }
}

Wo HCL verwendet wird

• Terraform – der wichtigste HCL-Nutzer; jede `.tf`-Datei ist HCL und beschreibt Cloud- und On-Premises-Infrastruktur.
• Packer – HCL2 (die Version 2 der Sprache) definiert Machine-Image-Builds für AWS-AMIs, GCP-Images und weitere.
• Vault – HCL wird für Richtliniendateien verwendet, die Zugriffskontrollregeln in HashiCorp Vault definieren.
• Consul – Konfigurationsdateien des Service Mesh, Health Checks und Servicedefinitionen nutzen HCL.
• Nomad – Job-Spezifikationen für die Workload-Orchestrierung sind in HCL geschrieben.

HOCON steht für Human-Optimized Config Object Notation. Es wurde 2011 von Typesafe (heute Lightbend) als Konfigurationsformat der Typesafe-Config-Bibliothek geschaffen, die Akka, Play Framework, Lagom und andere JVM-Frameworks antreibt. HOCON-Dateien nutzen die Endung `.conf` und sind eine strikte Obermenge von JSON – jede gültige JSON-Datei ist gültiges HOCON.

HOCON ist für die Laufzeitkonfiguration von Anwendungen gedacht, nicht für die Definition von Infrastruktur. Sein herausragendes Merkmal sind Substitutionen – die Möglichkeit, über die Substitutionssyntax andere Konfigurationswerte in derselben Datei zu referenzieren, indem andere Konfigurationswerte oder Umgebungsvariablen per Pfad angesprochen werden. Das macht HOCON besonders geeignet für geschichtete Konfiguration: Eine Basiskonfiguration definiert Standardwerte, eine umgebungsspezifische Datei überschreibt einzelne Werte, und Substitutionen greifen auf Umgebungsvariablen oder andere Quellen zurück.

Grundlagen der HOCON-Syntax

# Konfiguration der Anwendung
app {
  name = "my-service"
  version = "1.0.0"

  server {
    host = "0.0.0.0"
    port = 8080
    # Substitution aus einer Umgebungsvariable
    port = ${?APP_PORT}
  }

  database {
    url = "jdbc:postgresql://localhost:5432/mydb"
    # Substitution aus einem anderen Konfigurationswert
    connection-pool = ${app.server.port}
  }
}

# Listen
allowed-origins = ["https://example.com", "https://api.example.com"]

HOCON-Funktionen jenseits von JSON

• Kommentare – einzeilige Kommentare mit `#` und `//`; JSON unterstützt keine Kommentare.
• Substitutionen – `${path.to.value}` referenziert andere Schlüssel; `${?ENV_VAR}` schlägt still fehl, wenn die Variable nicht definiert ist.
• include-Direktiven – include "other.conf" führt externe Konfigurationsdateien beim Parsen zusammen.
• Objektzusammenführung – doppelte Schlüssel führen ihre Werte zusammen, statt sie zu überschreiben; ermöglicht geschichtete Konfiguration.
• Flexibilität bei Schlüssel-Wert – unterstützt key = value, key : value und key value (durch Leerzeichen getrennt) gleichermaßen.
• Zeichenketten ohne Anführungszeichen – einfache Zeichenkettenwerte brauchen keine Anführungszeichen, sofern sie keine Sonderzeichen enthalten.

HCL und HOCON lösen ähnliche Probleme aus unterschiedlichen Blickwinkeln. Beide sind für komplexe Konfigurationen lesbarer als JSON, beide unterstützen Kommentare und beide haben eine JSON-Kompatibilitätsschicht. Ihre Designziele, Hauptanwendungsfälle und Ökosystem-Integrationen unterscheiden sich jedoch so deutlich, dass du selten zwischen ihnen wählst – das Werkzeug, das du nutzt, entscheidet für dich.

HCL beschreibt, welche Infrastruktur existieren soll. HOCON beschreibt, wie sich eine Anwendung verhalten soll. Diese Zweckdifferenz prägt jede Designentscheidung in beiden Sprachen.

Der zentrale konzeptionelle Unterschied

HCL ist imperativ bezüglich der Struktur – Blöcke haben Typen und Bezeichner (`resource "aws_instance" "web"`), die semantische Bedeutung tragen und vom Werkzeug interpretiert werden. Du deklarierst Entitäten eines bestimmten Typs mit bestimmten Eigenschaften. HOCON ist rein ein Datenformat – es definiert eine hierarchische Schlüssel-Wert-Struktur, die Anwendungen beim Start lesen. Es kennt keine typisierten Blöcke; alles ist ein Schlüssel, der auf einen Wert, ein Objekt oder eine Liste zeigt.

HCL-Dateien werden meist im Rahmen eines Terraform-Projekts bearbeitet, doch dieselben Prinzipien gelten für Packer, Vault und Nomad. Formatierung und Struktur sind wichtig, weil HashiCorp-Werkzeuge HCL zur Plan- oder Validate-Zeit streng prüfen und fehlerhafte HCL-Blöcke Fehler erzeugen, die ohne konsistente Einrückung schwer nachzuvollziehen sind.

In JVM-Projekten liegen HOCON-Konfigurationsdateien typischerweise unter `src/main/resources/application.conf`. Akka-Anwendungen nutzen HOCON für die Konfiguration des Aktorsystems, Dispatcher-Einstellungen und Erweiterungen. Play Framework nutzt es für Routen, Datenbankverbindungen und Anwendungseinstellungen. Das Format ist nachsichtig – Zeichenketten ohne Anführungszeichen, flexible Zuweisungsoperatoren, Kommentare –, aber eine auf Leerzeichen achtende Formatierung macht Dateien lesbarer und leichter zu pflegen.

HOCON-Dateien formatieren

Der HOCON-Formatierer von Aback Tools formatiert HOCON-Konfigurationsdateien mit konsistenter 4-Leerzeichen-Einrückung, korrekten Schlüssel-Wert-Abständen, sauberer Substitutionsbehandlung und Typesafe-Config-Konventionen. Das ist besonders nützlich beim Bearbeiten großer Akka- oder Play-Konfigurationsdateien, deren Formatierung durch mehrere Beitragende uneinheitlich geworden ist.

HOCON in YAML umwandeln

Wenn ein Werkzeug in deiner Pipeline YAML erwartet, deine Anwendungskonfiguration aber HOCON ist, übersetzt der HOCON-zu-YAML-Konverter die HOCON-Schlüssel-Wert-Struktur in ein YAML-Äquivalent. Beachte, dass HOCON-spezifische Funktionen – Substitutionen, include-Direktiven und zusammengeführte Schlüssel – vor der Konvertierung aufgelöst werden; die YAML-Ausgabe zeigt also die endgültige zusammengeführte Konfiguration und nicht die rohe HOCON-Templatesyntax.

HCL und HOCON existieren neben einer breiteren Landschaft von Konfigurationsformaten. Die Wahl des richtigen ist selten frei – das Tooling, das du nutzt, gibt das Format vor. Zu verstehen, wo jedes Format passt, hilft dir aber, über Konfigurationsportabilität und Tooling-Kompromisse nachzudenken.

Wie die wichtigsten Konfigurationsformate abschneiden

HCL und YAML gemeinsam in Terraform-Workflows

In der Praxis nutzt ein Terraform-Projekt HCL für alle Infrastrukturdefinitionen, während die CI/CD-Pipeline, die Terraform ausführt, oft in YAML konfiguriert ist (GitHub Actions, GitLab CI, CircleCI). Beides koexistiert ohne Konflikt – HCL ist die Eingabe von Terraform, YAML die Eingabe der Pipeline. Wenn du mit beidem arbeitest, gilt dieselbe Formatierungsdisziplin. Für YAML-Fehler in deinen CI-Dateien greift die Vorgehensweise aus So erkennst und behebst du YAML-Fehler direkt.

HOCON, TOML und YAML für Anwendungskonfiguration

Für Nicht-JVM-Anwendungen sind TOML und YAML häufiger als HOCON. TOML ist der Standard für Rust (Cargo.toml), Python-Packaging (pyproject.toml) und Hugo-Statikseiten. YAML dominiert Kubernetes, Ansible, Docker Compose und die meisten Cloud-Native-Werkzeuge. HOCON ist die richtige Wahl speziell dann, wenn deine Laufzeit ein JVM-Framework ist, das Typesafe Config mitbringt – du bekommst HOCON-Funktionen kostenlos, und gegen das Framework für ein anderes Format zu kämpfen, schafft mehr Probleme als es löst.

Verwandte Beiträge zu Formaten

Wenn du Konfigurationsformate für ein neues Projekt bewertest, behandeln die Begleitbeiträge dieser Reihe die nächsten Alternativen. So erstellst du eine INI-Datei deckt das einfachste Konfigurationsformat ab. So kommentierst du YAML richtig behandelt YAML-Syntaxdetails. Und Was prüft terraform validate tatsächlich? zeigt, wie HCL-Fehler speziell in einem Terraform-Workflow auftreten.