Kevin Kulik
Menü
← Zurück zu Projekten

infrastruktur · cli

rostr

Ein Inventar, mehrere Standardartefakte, keine neue Abhängigkeit im Betrieb.

rostr hält Serverwissen in einer versionierten YAML-Inventarschicht und erzeugt daraus SSH-Konfiguration, Ansible-Inventar und eine einfache Hostliste. Das Werkzeug verkürzt Wege, ersetzt aber weder SSH noch Ansible.

reale Befehlsfolge · Hostzahlen weggelassen
$ rostr validate
✓ Inventory is valid

$ rostr sync
✓ SSH config updated
✓ Ansible inventory updated
✓ hosts.txt updated
Der Generator schreibt normale Dateien. Keine der Ausgaben braucht einen laufenden rostr-Prozess.

Kontext

Drei Kopien desselben Wissens

Vor rostr lebten Serverdaten gleichzeitig in SSH-Konfigurationen, Ansible-Inventories und persönlicher Erinnerung. Neue Hosts, geänderte Benutzer oder ein anderer Betriebszustand mussten an mehreren Stellen nachgezogen werden. Die Abweichung war selten sofort sichtbar.

Constraint

Die Abkürzung darf kein Lock-in werden

Das CLI durfte den Zugriff vereinfachen, aber keine proprietäre Laufzeit zwischen Operator und Infrastruktur schieben. Inventar bleibt YAML, Automation bleibt normales Ansible, Stacks bleiben Docker Compose. Generierte Dateien sind Output, nicht die nächste manuell gepflegte Quelle.

Architektur

Eine lesbare Quelle, deterministische Ableitungen

Beim Sync liest rostr die Inventargruppen, wendet Defaults an, prüft Felder und erzeugt drei operative Sichten. Tags und Betriebssysteme werden zusätzlich zu Ansible-Gruppen. Ziele können ausdrücklich von der Ansible-Verwaltung ausgeschlossen werden.

01versioniertes YAML-InventarGruppen · Hosts · Defaults · Tags · Verwaltungsstatus
rostr synclesen · normalisieren · validieren · deterministisch schreiben
  1. 02SSH configdirekter Zugriff und Jump-Aliase
  2. 03Ansible inventoryGruppen nach Bereich, Tag und OS
  3. 04hosts.txtkleine menschenlesbare Übersicht
Öffentlich abstrahiert. Die Beziehungen und Dateitypen entsprechen dem aktuellen Code; echte Hosts, Adressen und Zugriffspfade sind nicht dargestellt.

Entscheidungen

Was absichtlich so gebaut ist

  1. 01

    Standardformate bleiben eigenständig

    SSH, Ansible und Compose sollen direkt benutzbar bleiben. rostr ist Helfer und Kontrollfläche, keine zwingende Laufzeitschicht.

    Trade-off: Einige Funktionen bleiben bewusst weniger elegant, weil das Standardwerkzeug die letzte Autorität behält.

  2. 02

    Generiertes wird nie von Hand editiert

    Änderungen gehören ins Inventar. Ein erneuter Sync darf jede Ausgabe vollständig ersetzen.

    Trade-off: Lokale Sonderfälle müssen als Inventardaten oder explizite Generatorlogik modelliert werden.

  3. 03

    Inventarziel ist nicht automatisch Ansible-Ziel

    Ein expliziter Verwaltungsstatus hält Systeme aus dem generierten Ansible-Inventar, wenn Playbooks dort keinen Auftrag haben.

    Trade-off: Die zusätzliche Grenze muss beim Erfassen eines Hosts bewusst gesetzt und geprüft werden.

  4. 04

    Fork statt vollständigem Neubau

    Die brauchbare Inventar- und CLI-Basis kam aus dem MIT-lizenzierten Upstream. Der private Fork erweitert sie zum eigenen Infrastruktur-Kontroll-Repo.

    Trade-off: Upstream-Herkunft und eigener Betriebsumfang müssen getrennt und ehrlich beschrieben bleiben.

Implementierungsartefakte

Kleine Ausschnitte, die das Verhalten belegen

inventory/groups/example.yaml
group:
  name: Production
  code: production
servers:
  - hostname: app-primary
    ip: 192.0.2.10
    os: ubuntu-24.04
    tags: [web, docker]
    ansible_managed: true
    active: true
Illustrativer, anonymisierter Auszug mit realen Feldnamen. Die Adresse stammt aus dem Dokumentationsbereich und gehört zu keinem echten System.
generated/ssh_config
# Auto-generated by rostr
Host app-primary
    HostName 192.0.2.10
    User deploy
Die generierte SSH-Datei ist gewöhnliche OpenSSH-Konfiguration und bleibt ohne das CLI nutzbar.
aktueller Repo-Schnitt · sensible Inhalte ausgelassen
rostr/
├─ src/rostr/   CLI
├─ inventory/   source
├─ ansible/     standalone
├─ stacks/      standalone
└─ generated/   output only

Stand und Learnings

Weniger Drift, mehr sichtbare Grenzen

Was sich geändert hat

Eine Änderung am Inventar kann die operativen Sichten gemeinsam erneuern. Derselbe Repo-Kontext trägt außerdem die eigenständig ausführbaren Ansible-Playbooks, die unter anderem beim Dedicated-Server-Rebuild im Juni 2026 eingesetzt wurden.

Drift ist ein Architekturproblem.

Was unperfekt bleibt

  • Eine einzige Quelle kann weiterhin veralten. Generation entfernt Duplikation, nicht die Pflicht zur Pflege.
  • Der private Fork ist vom Inventar-CLI zu einem breiteren Kontroll-Repo gewachsen. Diese zusätzliche Fläche verlangt mehr Disziplin bei Zuständigkeiten und Tests.
  • Lokale SSH-Agent- und Include-Konfiguration bleibt Voraussetzung für bestimmte Komfortpfade. Die erzeugten Standarddateien bleiben trotzdem separat prüfbar.