railyard.yml: die Konfiguration deiner App als eine Datei in git

Config-as-Code wird meist als größeres Versprechen verkauft, als es am ersten Tag mechanisch tatsächlich leistet. Hier lohnt es sich, präzise zu sein, denn dieses spezifische Feature zu überverkaufen wäre genau die Art von Sache, die dieser Blog zu vermeiden versucht: railyard.yml sind heute drei unkomplizierte Kommandos, keine vollständige Plan/Apply/Drift-Pipeline — und genau zu wissen, wo diese Grenze liegt, ist nützlicher als eine vagere, großartiger klingende Beschreibung.

Die drei Kommandos

railyard manifest:pull my-app --out railyard.yml
railyard manifest:apply my-app railyard.yml
railyard manifest:validate railyard.yml

• manifest:pull gibt die aktuelle Konfiguration einer App als railyard.yml-Datei aus — mit --secrets enthält sie auch Variablenwerte, nicht nur Namen. So bekommst du einen Ausgangspunkt: Du ziehst, was bereits läuft, statt die Datei von einer leeren Seite aus zu schreiben.
• manifest:apply wendet eine Datei direkt auf eine App an.
• manifest:validate prüft eine lokale Datei — ./railyard.yml, wenn du keine benennst — gegen das Schema, ganz ohne beteiligte App und ohne dass irgendetwas angewendet wird. Unbekannte Keys bekommen einen echten Vorschlag (contaner_port → „meintest du container_port?”), nicht nur eine generische Parse-Fehlermeldung. Es gibt den Exit-Code 0 zurück und druckt „is valid”, wenn nichts falsch ist, oder Exit-Code 1 und listet jedes gefundene Problem auf.

Wofür diese Kombination tatsächlich gut ist

validate in der CI vor einem Deploy laufen zu lassen, fängt einen verschriebenen Key oder einen fehlerhaften Wert ab, bevor er je eine echte App erreicht — billige Versicherung, die ein Kommando in einer Pipeline kostet. pull dann apply ist, wie Konfiguration zwischen Environments bewegt wird, ohne sich für jede einzeln durchs Dashboard zu klicken: Staging-Config ziehen, anpassen, was tatsächlich anders sein soll, auf Produktion anwenden.

Die REST-API unterstützt dasselbe direkt — GET /api/applications/:id/manifest gibt dieselbe Datei zurück (?secrets=true für Werte), für alles, das darum herum skripten will, über die CLI hinaus.

Was es noch nicht ist

Es gibt keinen plan-Schritt, der einen Diff zeigt, bevor angewendet wird — apply wendet einfach an. Es gibt keine Drift-Erkennung, die dir sagt, dass Produktion stillschweigend von der Datei in git abgewichen ist. Wenn das für die Arbeitsweise deines Teams heute wichtig ist, behandle railyard.yml als Config-Snapshot und Transportmechanismus, nicht als Garantie, dass git und Realität ohne dein eigenes Nachprüfen synchron bleiben.

Das hier klar zu sagen, ist der Punkt: Ein Config-as-Code-Feature ist erst wirklich nützlich, wenn man genau weiß, was es für einen prüft und was es weiterhin dir überlässt zu merken.

Vollständige Kommandoreferenz: CLI.