IaC-Workflow

So übernehmen, validieren, prüfen und wenden Sie ein SteadyCron-YAML-Manifest an — vom ersten Export bis zur CI/CD-Automatisierung.

Die SteadyCron-CLI verwandelt Ihr Konto in eine Textdatei, die Sie versionieren, in PRs reviewen und aus CI heraus deployen können. Diese Seite erklärt jeden Befehl im Workflow.

Voraussetzungen {#prerequisites}

CLI installieren

Option 1 — .NET Global Tool (empfohlen)

Erfordert die .NET 10 Runtime.

dotnet tool install -g steadycron
steadycron --version

Später aktualisieren mit dotnet tool update -g steadycron.

Option 2 — Self-contained Binary

Keine Runtime erforderlich. Laden Sie das einzelne Binary von der Releases-Seite herunter:

# Linux x64
curl -Lo steadycron https://github.com/steadycron/cli/releases/latest/download/steadycron-linux-x64
chmod +x steadycron && sudo mv steadycron /usr/local/bin/

Binaries für Linux arm64, macOS und Windows sind auf der gleichen Releases-Seite verfügbar.

Authentifizieren

Erstellen Sie einen API-Schlüssel unter Einstellungen → API-Schlüssel im Dashboard. Schreibende Befehle (apply, sync, jobs create usw.) erfordern einen Full-Access-Key; export, validate und plan funktionieren mit einem Read-only-Key.

Schlüssel in der Umgebung setzen:

export STEADYCRON_API_KEY=sc_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Oder in der Konfigurationsdatei speichern, damit er sitzungsübergreifend erhalten bleibt:

steadycron config set --api-key sc_...

Verbindung überprüfen:

steadycron config show --check

Befehle auf einen Blick

Befehl	Was er tut
`steadycron export`	Aktuellen Kontozustand in ein Manifest exportieren
`steadycron validate`	Manifest auf Schema-Fehler prüfen
`steadycron plan`	Vorschau der Änderungen — ohne Schreibzugriff
`steadycron sync`	Änderungen anwenden (anlegen + aktualisieren; keine Löschungen)
`steadycron apply`	Änderungen anwenden; mit `--prune` auch löschen

Schritt 1 — Exportieren (ein bestehendes Konto übernehmen)

Wenn Sie bereits Jobs im Dashboard haben, überträgt export diese vollständig in ein Manifest, damit Sie sie als Code verwalten können, ohne dabei etwas zu verlieren:

export STEADYCRON_API_KEY=sc_...
steadycron export --namespace production > manifests/production.yaml

Die exportierte Datei ist commit-sicher. API-Schlüssel, Webhook-URLs und andere Secrets werden durch ${VAR_NAME}-Platzhalter ersetzt — die eigentlichen Werte übergeben Sie zur Anwendungszeit über Umgebungsvariablen. Template-Variablen ({{var}}) in HTTP-Job-Feldern werden unverändert übernommen.

Prüfen Sie die Datei, fügen Sie fehlenden Jobs id-Werte hinzu und committen Sie.

Schritt 2 — Validieren

Prüfen Sie ein Manifest auf Schema-Fehler, bevor Sie es anwenden:

steadycron validate manifests/production.yaml

Beendet sich mit 0 bei Erfolg, mit 1 und einer Fehlerliste bei Problemen. Binden Sie dies als Pre-Flight-Check in CI für jeden PR ein.

Schritt 3 — Plan

plan zeigt Ihnen genau, was sich ändern würde — ähnlich wie terraform plan — ohne etwas zu schreiben:

steadycron plan manifests/production.yaml

Beispielausgabe:

  ~ weekly-digest       update  retries: 2 → 3
  + invoice-reminder    create  kind: http  schedule: 0 17 * * 5
  - old-report          (not in manifest — would be deleted with --prune)

  1 to create · 1 to update · 1 pending deletion

Verwenden Sie dies in Ihrer PR-Pipeline, um den Plan-Diff als Kommentar zu jedem Pull Request hinzuzufügen. Weitere Details finden Sie unter CI/CD-Einrichtung — dort ist die GitHub Action beschrieben, die dies automatisch erledigt.

Schritt 4 — sync / apply

sync legt neue Jobs an und aktualisiert geänderte. Jobs, die in Ihrem Konto existieren, aber nicht im Manifest, werden nicht gelöscht:

steadycron sync manifests/production.yaml

Um auch nicht verwaltete Jobs zu entfernen (solche im Namespace, aber nicht in der Datei), verwenden Sie apply --prune:

steadycron apply --prune manifests/production.yaml

apply ist transaktional: Schlägt eine Operation fehl, wird der Rest des Batches nicht angewendet und der Fehler wird mit der betroffenen Ressource gemeldet.

Dry-Run

Übergeben Sie --dry-run an jeden sync- oder apply-Aufruf, um die geplanten Aktionen auszugeben, ohne Änderungen vorzunehmen — entspricht plan, ist aber beim Scripting nützlicher:

steadycron apply --prune --dry-run manifests/production.yaml

Namespaces & Eigenverantwortung {#namespaces}

Ein Namespace begrenzt, welche Ressourcen die CLI verwaltet. Ohne Namespace arbeitet die CLI im Standard-Namespace und kann --prune nicht sicher verwenden (es würde jeden Job löschen, der nicht im Manifest steht, einschließlich über das Dashboard erstellter Jobs).

Benennen Sie Namespaces nach Umgebungen oder Teams:

# manifests/production.yaml
namespace: production
jobs: [...]

# manifests/staging.yaml
namespace: staging
jobs: [...]

Das Dashboard zeigt den Namespace jedes Jobs. Ressourcen, die über das Dashboard erstellt wurden (ohne Namespace), befinden sich im Standard-Namespace und werden von einem namespaced apply --prune nicht berührt.

Mehrere Namespaces in einem Monorepo

Verwenden Sie eine Manifest-Datei pro Namespace:

manifests/
  production.yaml    # namespace: production
  staging.yaml       # namespace: staging
  workers.yaml       # namespace: workers-team

Wenden Sie jede Datei unabhängig an:

steadycron apply --prune manifests/production.yaml
steadycron apply --prune manifests/staging.yaml

Stabile Identität und sichere Umbenennung

Jede Ressource in einem Manifest hat ein id-Feld. Dies ist der stabile interne Schlüssel — er ändert sich nie, auch wenn Sie den name des Jobs umbenennen.

jobs:
  - id: nightly-backup         # ← für immer stabil
    name: Nightly database backup (prod)   # ← frei umbenennbar
    kind: heartbeat
    schedule: "0 2 * * *"

Warum das bei Heartbeats wichtig ist: Jeder Heartbeat-Check hat eine eindeutige Ping-URL, die an seine interne ID gebunden ist. Wenn Sie einen Heartbeat-Job umbenennen, bleibt die Ping-URL erhalten — Sie müssen Ihre Skripte, CI-Pipelines oder Monitoring-Integrationen nicht anpassen.

Haben zwei Einträge dieselbe id, lehnt validate das Manifest ab.

Secrets & Variablen {#secrets}

Secrets dürfen niemals als Klartext im Manifest erscheinen. SteadyCron bietet zwei Mechanismen:

1. `${ENV_VAR_NAME}` — CLI-Umgebungssubstitution

Die CLI liest diese zur Anwendungszeit aus der Prozessumgebung und ersetzt sie, bevor das Manifest an die API gesendet wird. Funktioniert in jedem Feld.

channels:
  - id: ops-slack
    name: Slack #ops
    kind: slack
    config:
      webhook_url: ${SLACK_WEBHOOK_URL}   # ← CLI liest aus der Umgebung zur Anwendungszeit

jobs:
  - id: invoice-job
    kind: http
    url: https://${API_HOST}/jobs/invoices
    headers:
      Authorization: Bearer ${INVOICE_API_KEY}

Legen Sie diese in CI als Repository-Secrets fest und übergeben Sie sie an den Job:

# GitHub Actions
env:
  STEADYCRON_API_KEY: ${{ secrets.STEADYCRON_API_KEY }}
  SLACK_WEBHOOK_URL:  ${{ secrets.SLACK_WEBHOOK_URL }}
  INVOICE_API_KEY:    ${{ secrets.INVOICE_API_KEY }}

2. `{{template_var}}` — serverseitige Substitution

Template-Variablen werden vom SteadyCron-Server zur Ausführungszeit aufgelöst, nicht zur Anwendungszeit. Sie funktionieren nur in HTTP-Job-Feldern (url, headers, body) und sind nützlich für Werte, die pro Ausführung variieren oder serverseitig berechnet werden.

jobs:
  - id: data-export
    kind: http
    url: https://api.myapp.com/export/{{date}}
    body: '{"run_id": "{{uuid}}"}'

steadycron export gibt beide Arten von Platzhaltern automatisch aus — das exportierte Manifest ist ohne manuelle Bereinigung commit-sicher.