Action Runs und Polycrate API: Jede Automatisierung mit Audit-Log

TL;DR

• Polycrate erfasst jede polycrate run-Ausführung automatisch als „Action Run“ – inklusive Block, Action, Exit-Code, Zeitpunkt, Dauer, CLI-Version, Hostname und OS-User.
• Über eine einfache Konfiguration in ~/.polycrate/polycrate.yml sendet die Polycrate CLI diese Action Runs an die Polycrate API – ohne zusätzliches Logging- oder Audit-Tooling.
• In der Polycrate API (Weboberfläche und API) sehen Sie zentral: Wer hat wann welche Action auf welchem Workspace ausgeführt, können Deployments über Workspaces hinweg nachvollziehen und einzelne Action Runs gezielt erneut triggern. PolyHub ist der Marketplace für Blöcke; Action Runs und Audit-Daten liegen in der API.
• Das Fail-Safe-Design sorgt dafür, dass API-Probleme niemals die eigentliche Automatisierung blockieren – die Infrastruktur-Änderung läuft immer durch, das Audit-Log ist „best effort“.
• ayedo verbindet diese API-Funktionen mit praxiserprobten Platform Engineering-Ansätzen, um Automatisierung, Compliance und Kollaboration in Teams jeder Größe zusammenzubringen.

Warum Action Runs für Compliance so wichtig sind

„Wer hat am Freitag Abend die Production-Datenbank neu gestartet?“
„Wann ist Version 1.4.3 wirklich in Produktion angekommen?“
„Welche Änderungen wurden vor dem Incident gestern Nacht ausgeführt?“

Diese Fragen kennen nicht nur DevOps-Teams. Auch:

• Linux- und Windows-Admins
• Compliance-Verantwortliche
• Enterprise-Architekten

müssen sie regelmäßig beantworten – oft unter Zeitdruck, häufig gegenüber Revision, Datenschutz oder Geschäftsführung.

Mit plain Ansible ist das möglich, aber selten bequem:

• Sie brauchen zusätzliche Tools wie AWX/Tower oder selbstgebaute Logging-Pipelines.
• Sie müssen Playbook-Ausgaben einsammeln, normalisieren und irgendwo speichern.
• Sie haben keinen einheitlichen Blick über alle Entwickler-Laptops, Bastel-Skripte und Cronjobs hinweg.

Polycrate geht hier einen anderen Weg: Jede polycrate run-Ausführung ist automatisch ein „Action Run“, der – sofern konfiguriert – an die Polycrate API gemeldet und dort (Weboberfläche/API) sichtbar wird. Ohne extra Setup, ohne eigenes Logging-Backend.

Gleichzeitig bleibt das, was Polycrate stark macht, unverändert:

• Ansible und Ihre Toolchain laufen konsequent im Container – keine lokalen Python-/Ansible-Dependencies, weniger Supply-Chain-Risiko.
• Ihre Automatisierung ist als Blöcke versionierbar und über OCI-Registries sowie den PolyHub teilbar.
• Workspace-Verschlüsselung mit age sorgt dafür, dass Secrets trotz zentraler Audit-Logs geschützt bleiben.

In diesem Beitrag schauen wir uns Action Runs im Detail an – von der Konfiguration über die geloggten Felder bis zum Remote-Re-Triggering.

Was sind Action Runs?

Ein Action Run ist der technische Datensatz zu einer konkreten Ausführung von:

polycrate run BLOCK ACTION

Immer wenn Sie eine Action starten – egal ob von Ihrem Laptop, einem CI-Runner oder einem Bastel-VM – erstellt die Polycrate CLI intern ein Action-Run-Objekt. Dieses enthält u.a.:

• Block-Name (im Workspace)
• Action-Name
• Exit-Code
• Start-Zeitpunkt
• End-Zeitpunkt
• Dauer
• CLI-Version
• Hostname
• Betriebssystem-Benutzer

Optional sendet die CLI dieses Objekt an die Polycrate API, die es speichert und in der Weboberfläche bzw. über die API bereitstellt.

Wichtig:
Diese Erfassung ist vollständig unabhängig von Ihrem Ansible-Playbook. Egal ob Sie Linux-Server patchen, Windows-Dienste verwalten oder einen Kubernetes-Cluster bespielen – der Action Run beschreibt die Ausführung der Polycrate-Action, nicht die fachliche Domäne.

So entsteht automatisch ein auditierbarer Verlauf aller Infrastruktur-Änderungen, ohne dass Sie Logging in jedem Playbook einzeln implementieren müssen.

Polycrate API konfigurieren: ~/.polycrate/polycrate.yml

Damit Action Runs in der Polycrate API ankommen, konfigurieren Sie die CLI einmalig pro Benutzer in ~/.polycrate/polycrate.yml.

Ein typisches Setup sieht so aus:

# ~/.polycrate/polycrate.yml
api:
  url: "https://api.polycrate.io"        # oder Ihr Self-Hosted-Endpunkt
  api_key: "pc_live_XXXXXXXXXXXXXXXX"    # Ihr persönlicher oder robotischer API-Key
  submit_action_runs: true               # Action Runs an die API senden

Ein paar Punkte dazu:

• api.url zeigt auf die Polycrate API-Instanz (SaaS oder Self-Hosted).
• api.api_key ist Ihr Authentifizierungs-Token. Bewahren Sie ihn wie ein Passwort auf.
• api.submit_action_runs: true aktiviert das Senden von Action Runs. Ohne diesen Schalter wird lokal weiterhin alles ausgeführt, aber nichts an die API geschickt.
• In der Polycrate CLI gibt es keinen Schalter cli.telemetry und es werden keine anonymen Nutzungs-Telemetriedaten an ayedo übermittelt.
• Die Struktur der Konfigurationsdatei finden Sie detailliert in der Konfiguration und der Polycrate API-Dokumentation.

Für Compliance-Verantwortliche ist wichtig:
Der API-Key ist personenbezogen oder klar einem technischen Benutzer zugeordnet. Damit ist später im Audit-Log eindeutig nachvollziehbar, wer die Automatisierung gestartet hat – unabhängig davon, von welchem Endgerät aus.

Was genau wird geloggt?

Action Runs sind bewusst schlank, aber aussagekräftig. Typische Felder sind:

• Workspace
  • Name des Workspaces
  • Organisation (sofern im Workspace hinterlegt)
• Block
  • Name der Block-Instanz im Workspace
  • Referenz (from:), inkl. genauer Block-Version
• Action
  • Name der Action (z.B. restart, deploy, patch)
• Ausführung
  • Startzeitpunkt (started_at)
  • Endzeitpunkt (finished_at)
  • Dauer in Millisekunden
  • Exit-Code
  • Status (erfolgreich, fehlgeschlagen, abgebrochen)
• Umgebung
  • CLI-Version (z.B. polycrate 0.18.3)
  • Hostname (z.B. laptop-max, gitlab-runner-42)
  • Betriebssystem-Benutzer (z.B. max, gitlab-runner)

Aus Sicht von Compliance, insbesondere mit Blick auf die DSGVO, die seit dem 25.05.2018 in Kraft ist, sind zwei Aspekte wichtig:

1. Zurechenbarkeit:
   Durch Hostname und OS-User in Kombination mit dem API-Key lässt sich jede risikoreiche Änderung einer Person oder einem Service-Account zuordnen.
2. Nachvollziehbarkeit:
   Startzeit, Ende, Erfolg/Misserfolg und konkrete Action machen jede Automatisierungsschritte im Nachhinein prüfbar – ohne Logfiles aus zehn Systemen zusammensuchen zu müssen.

Was nicht mitgeschickt wird:

• Inhalt Ihrer Secrets (liegen verschlüsselt im Workspace, siehe unten).
• Vollständige Playbook-Ausgaben (nur Metadaten, kein Task-Log).
• Ziel-Host-spezifische Details wie IP-Adressen oder Konfigurationen, außer Sie modellieren diese bewusst als Block-Konfiguration.

Damit bleibt der Audit-Trail aussagekräftig, ohne mehr personenbezogene oder sensible Daten zu transportieren als nötig.

Workspace-Verschlüsselung und Container-Execution als Compliance-Bausteine

Aus Compliance-Sicht ist es entscheidend, dass:

• Secrets nicht im Klartext auf Laptops oder CI-Runners herumliegen.
• Werkzeuge und Libraries reproduzierbar und vertrauenswürdig sind.

Polycrate adressiert beides:

1. Workspace-Verschlüsselung mit age
   Ihre sensiblen Dateien (API-Keys, SSH-Keys, Kubeconfigs) liegen unter artifacts/secrets/ im Workspace und sind per polycrate workspace encrypt verschlüsselt. Details dazu in der Dokumentation zur Workspace-Verschlüsselung.

2. Containerisierte Ausführung
   Ansible und die gesamte Toolchain laufen in einem definierten Container. Kein „Python 2.7 vs. 3.x“-Chaos, keine wilden pip install-Orgien pro Laptop, weniger Angriffspunkte. Mehr dazu in der Ansible-Integration.

Für Sie bedeutet das:
Der Audit-Trail über Action Runs kommt oben drauf, ohne dass Sie zusätzliche Sicherungsmechanismen erfinden müssen. Polycrate bringt die Basis mit – inklusive klarer Best Practices, siehe Best Practices.

Action Runs in der Polycrate API: Wer, was, wann, wo?

Sobald submit_action_runs aktiviert ist, landen Ihre Action Runs in der Polycrate API (Orchestrierungs- und Management-Layer für Workspaces, Runs und Berechtigungen). Im UI der API bzw. über die API können Sie pro Workspace und Organisation z.B. folgende Fragen beantworten. PolyHub bleibt der Marketplace für Blöcke – getrennt von Action Runs und Audit-Daten.

• Wer hat am Freitag um 21:17 Uhr die Action db-maintenance.restart im Workspace acme-prod ausgeführt?
• Wie viele fehlgeschlagene deploy-Runs gab es im letzten Monat?
• Auf welchem Workspace wurde der Block cargo.ayedo.cloud/ayedo/infra/nginx:0.3.1 zuletzt in Produktion ausgerollt?

Die API aggregiert Action Runs über:

• unterschiedliche Workspaces (Dev, Test, Prod),
• verschiedene Teams und Standorte,
• Laptop-, CI- und Edge-Umgebungen hinweg.

Damit sehen nicht nur Platform-Teams, sondern auch Compliance- und Security-Verantwortliche auf einen Blick, welche Automatisierungen wo stattgefunden haben – ohne auf proprietäre CI-Logs, Chat-Verläufe oder manuelle Change-Excel-Listen angewiesen zu sein.

Für strukturierte Teams können Action Runs außerdem ein zentrales Element eines Platform Engineering-Ansatzes sein: Die Plattform stellt Standard-Blöcke bereit, und über die Action-Runs-Historie wird sichtbar, wie diese Bausteine wirklich im Alltag genutzt werden.

Action Run erneut triggern: Operations-Feature mit Mehrwert

Ein weiterer Vorteil der Polycrate API: Sie können einen bestehenden Action Run remote erneut auslösen.

Typische Anwendungsfälle:

• Ein Deployment ist an einem transienten Fehler gescheitert (z.B. Timeout gegen eine Registry) – statt das Kommando neu zusammenzusuchen, lösen Sie in der Polycrate API „erneut ausführen“ aus.
• Ein standardisierter Wartungslauf (z.B. Windows-Patching oder Linux-Kernel-Update) soll in identischer Form wiederholt werden – mit denselben Parametern, aber neuem Zeitpunkt.
• Ein Incident-Runbook wurde manuell getriggert, soll aber automatisiert z.B. jeden Sonntag wiederholt werden – als Brücke, bis das sauber in einen Workflow überführt ist.

Technisch nutzt die API dabei:

• den gespeicherten Action-Run-Datensatz (Block, Action, Workspace-Kontext),
• und triggert auf einem angebundenen Runner (z.B. CI oder MCP) erneut polycrate run BLOCK ACTION.

Die Details zur API-Nutzung und den entsprechenden Endpunkten finden Sie in der Polycrate API-Dokumentation.

Wichtig:
Das Re-Triggering verdoppelt nicht kritiklos jede Änderung. Ihre Ansible-Playbooks bleiben idempotent (Stärke von Ansible) und prüfen selbst, ob eine Änderung notwendig ist. Polycrate sorgt nur dafür, dass Sie die identische Automatisierung noch einmal anstoßen können – nachvollziehbar und auditierbar.

Fail-Safe by Design: Action läuft immer durch

Ein typisches Compliance-Bauchgefühl: „Wenn wir Logging verpflichtend machen, legt uns im Zweifel der Logging-Server lahm.“

Polycrate löst dieses Dilemma explizit:

• Die eigentliche Action (Ansible-Play) läuft immer lokal im Container durch.
• Die Übermittlung des Action Runs an die API ist „best effort“:
  • Ist die API nicht erreichbar, wird die Ausführung nicht abgebrochen.
  • Ist der API-Key ungültig, wird der Run weiter ausgeführt – Sie sehen den Fehler in der CLI-Ausgabe, aber Ihre Infrastruktur bleibt bedienbar.
  • Netzwerk-Timeouts oder TLS-Probleme blockieren die Automation nicht.

Damit können Sie Action Runs auch in sensiblen Umgebungen aktivieren, in denen eine temporäre API-Unerreichbarkeit nicht zu einem Stopp von Wartungsfenstern oder Incident-Runbooks führen darf.

Praxisbeispiel: Production-Datenbank-Neustart mit Audit-Log

Schauen wir uns ein konkretes Beispiel an: Ein Block, der die Production-Datenbank neu startet.

Workspace-Setup

# workspace.poly
name: acme-corp-automation
organization: acme

blocks:
  - name: db-maintenance
    from: db-maintenance
    config:
      env: production
      db_host: db-prod01.acme-corp.com
      db_service_name: "postgresql"

Der Workspace folgt den üblichen Regeln, siehe Workspaces. Die Block-Konfiguration hält nur die nötigsten produktionsspezifischen Werte.

Ein einfaches Inventory für Ansible könnte so aussehen:

# inventory.yml (Workspace-Root)
all:
  hosts:
    db-prod01.acme-corp.com:
      ansible_user: "ubuntu"
      ansible_ssh_private_key_file: "{{ workspace.secrets['prod-db.key'] }}"

Das Inventory liegt im Workspace-Root, Polycrate setzt ANSIBLE_INVENTORY automatisch. Secrets werden über die Workspace-Verschlüsselung geschützt.

Block-Definition

# blocks/db-maintenance/block.poly
name: db-maintenance
version: 0.1.0
kind: generic

config:
  env: "{{ block.config.env }}"
  db_host: "{{ block.config.db_host }}"
  db_service_name: "{{ block.config.db_service_name }}"

actions:
  - name: restart
    description: "Restart des Datenbankdienstes auf dem Ziel-Host"
    playbook: restart-db.yml

Die Werte kommen aus der Block-Instanz in workspace.poly und stehen in Templates und Playbooks als block.config zur Verfügung; Querzugriffe auf andere Blöcke über workspace.blocks.* sind nicht vorgesehen. Details zur Vererbung.

Die Action restart verweist auf ein Ansible-Playbook im gleichen Verzeichnis.

Ansible-Playbook

# blocks/db-maintenance/restart-db.yml
- name: Restart Datenbankdienst
  hosts: all
  become: true
  gather_facts: false

  vars:
    db_service_name: "{{ block.config.db_service_name }}"

  tasks:
    - name: Sicherstellen, dass der DB-Host erreichbar ist
      ansible.builtin.ping:

    - name: Datenbankdienst neu starten
      ansible.builtin.service:
        name: "{{ db_service_name }}"
        state: restarted

    - name: Status des Datenbankdienstes prüfen
      ansible.builtin.service_facts:

    - name: Sicherstellen, dass der Dienst läuft
      ansible.builtin.assert:
        that:
          - ansible_facts.services[db_service_name].state == "running"
        fail_msg: "Datenbankdienst {{ db_service_name }} läuft nicht"
        success_msg: "Datenbankdienst {{ db_service_name }} läuft"

Wichtig:
hosts: all bedeutet hier „alle Hosts aus inventory.yml“ – Polycrate führt das Playbook im Container aus, aber die Zielsysteme werden via SSH angesprochen.

Action ausführen

Der eigentliche Run ist trivial:

polycrate run db-maintenance restart

Was passiert dabei?

1. Polycrate startet einen Container mit der konfigurierten Toolchain (Ansible, Python, SSH).
2. Die CLI erstellt ein Action-Run-Objekt mit:
   • Workspace acme-corp-automation
   • Block db-maintenance
   • Action restart
   • Startzeit, CLI-Version, Hostname, OS-User
3. Das Playbook wird ausgeführt. Ansible sorgt für Idempotenz.
4. Nach Ende des Runs aktualisiert die CLI den Action Run mit:
   • Endzeit
   • Dauer
   • Exit-Code
5. Wenn submit_action_runs: true gesetzt ist, sendet die CLI den Action Run an die API.

Die Antwort auf die eingangs gestellte Frage:

„Wer hat am Freitag Abend die Production-Datenbank neu gestartet?“

finden Sie anschließend in der Polycrate API, indem Sie:

• Nach Workspace acme-corp-automation filtern,
• Block db-maintenance und Action restart auswählen,
• den Zeitraum („Freitag Abend“) setzen.

Mit plain Ansible müssten Sie dafür:

• entweder AWX/Tower einsetzen und konsequent nutzen,
• oder eigene Logging-Mechanismen bauen (z.B. Callbacks, Webhooks, Filebeat-Shipping),
• oder hoffen, dass jemand das Playbook mit --verbose ausgeführt und das Log aufgehoben hat.

Mit Polycrate ist diese Nachvollziehbarkeit Bestandteil des normalen Workflows.

Deployment-Tracking über Workspaces hinweg

Action Runs helfen nicht nur bei „Wer hat was wann gemacht?“, sondern auch bei Fragen wie:

• „Wann wurde Version 0.3.1 unseres Webserver-Blocks zuletzt in Produktion deployed?“
• „Wie lange dauern Deployments im Durchschnitt?“

Da die Block-Referenz (from: inkl. Version) und der Workspace in den Action Runs auftauchen, können Sie z.B.:

• Alle Action Runs für cargo.ayedo.cloud/ayedo/infra/nginx:0.3.1 im Workspace acme-prod anzeigen.
• Daraus automatisch eine Deployment-Historie generieren.
• Audit-sicher dokumentieren, wann welche Version in welche Umgebung ausgerollt wurde.

In Kombination mit dem PolyHub und der Registry-Integration ergibt sich so eine vollständige Kette:

• Ein Block wird gebaut, versioniert und in eine OCI-Registry gepusht.
• Workspaces verweisen explizit auf eine konkrete Version (niemals :latest).
• Jeder polycrate run mit diesem Block erzeugt Action Runs – über alle Workspaces hinweg.

Das Ergebnis ist ein jederzeit einsehbares Change-Log für Ihre Infrastruktur – ohne dass Sie dafür ein separates „Deployment-Tracking-Tool“ einführen müssen.

Vergleich zu plain Ansible: Wo Polycrate ansetzt

Ansible selbst ist ein exzellentes Automatisierungswerkzeug – auch ohne Polycrate. Aber sobald Sie Auditierbarkeit und Team-Kollaboration ernst nehmen, stoßen viele Teams auf wiederkehrende Probleme:

• Dependency-Sprawl: Unterschiedliche Ansible-Versionen, Python-Umgebungen und OS-Pakete auf Laptops und CI-Runners.
• Playbook-Wildwuchs: Kein konsistentes Block-Modell, schwer teilbare Automatisierungsbausteine.
• Logging-Fragmente: Teilweise Logging im CI, teilweise lokal, teilweise gar nicht.

Polycrate setzt genau hier an:

• Containerisierte CLI mit definierter Toolchain – keine lokalen Ansible-Installationen nötig.
• Block-Modell als Guardrail – wiederverwendbare, versionierbare Automatisierungs-Bausteine, geteilt über PolyHub, siehe PolyHub-Doku.
• Action Runs über die API – ein durchgängiger Audit-Trail, ohne dass Sie separate Logging-Pipelines aufbauen müssen.

Statt Ansible zu ersetzen, macht Polycrate es zur tragfähigen Grundlage Ihrer Automatisierung – technisch, organisatorisch und compliance-fähig.

Häufige Fragen

Werden durch Action Runs personenbezogene Daten im Sinne der DSGVO gespeichert?

Ja, potenziell – insbesondere über den Bezug zu einem persönlichen API-Key und den OS-Benutzernamen. Allerdings ist genau das für eine revisionssichere Nachvollziehbarkeit von Änderungen meist gewünscht.

Wichtig ist:

• API-Keys sollten gezielt Personen oder technischen Konten zugeordnet sein.
• Rollen- und Berechtigungskonzepte in Ihrer Organisation müssen diese Zuordnung berücksichtigen.
• Polycrate speichert standardmäßig keine Inhalte von Secrets oder Playbook-Outputs in Action Runs.

Die konkrete rechtliche Einordnung hängt von Ihrer Organisation ab. Technisch bietet Polycrate aber einen klar abgrenzbaren, nachvollziehbaren Datensatz, den Sie in Ihr Datenschutzkonzept integrieren können.

Brauche ich für Action Runs zwingend die SaaS-Variante der Polycrate API?

Nein. Die Polycrate API kann auch self-hosted betrieben werden. Damit behalten Sie sämtliche Action-Run-Daten in Ihrer eigenen Infrastruktur – ein Punkt, der insbesondere in regulierten Branchen und bei strenger Auslegung der DSGVO seit dem 25.05.2018 häufig gefordert wird.

Die CLI-Konfiguration (api.url, api.api_key, api.submit_action_runs) bleibt identisch, nur der Endpunkt ändert sich.

Verlangsamt das Senden von Action Runs meine Automatisierung?

In der Praxis kaum:

• Action Runs sind kleine JSON-Objekte, die per HTTP an die API geschickt werden.
• Der Overhead ist üblicherweise im Millisekunden-Bereich.
• Schlägt der API-Call fehl oder dauert zu lange, läuft die Action trotzdem durch (Fail-Safe-Design).

Sollten Sie extrem latenzkritische Szenarien haben (z.B. sehr kurz getaktete IoT/Edge-Workloads), können Sie submit_action_runs für diese Nutzer oder Workspaces gezielt deaktivieren oder über dedizierte Runner mit guter API-Konnektivität arbeiten.

Weitere Fragen? Siehe unsere FAQ

Ihre Infrastruktur, compliant

Action Runs und die Polycrate API schließen eine Lücke, die viele Teams bislang nur mit erheblichem Zusatzaufwand adressieren konnten: einen durchgängigen, zentralen Audit-Trail für Infrastruktur-Automatisierung – ohne eigene Logging-Stacks, ohne Zwang zu proprietären Tools.

Sie haben in diesem Beitrag gesehen:

• wie Sie die Polycrate API mit wenigen Zeilen in ~/.polycrate/polycrate.yml aktivieren,
• wie jede polycrate run-Ausführung automatisch als Action Run erfasst wird,
• welche Metadaten für Compliance, Revision und Sicherheit relevant sind,
• wie Re-Triggering von Action Runs den Alltag von Operations-Teams erleichtert,
• und warum das Fail-Safe-Design verhindert, dass Logging zum Single Point of Failure wird.

Als ayedo bringen wir diese technischen Bausteine zusammen mit erprobten Platform Engineering-Konzepten: Von der Einführung einer Block-basierten Automatisierungsplattform über die Integration in bestehende Governance-Strukturen bis hin zu Schulungen für Admins und Compliance-Teams.

Wenn Sie sehen möchten, wie sich Action Runs in Ihre bestehende Automatisierung integrieren lassen – ob auf Linux, Windows, IoT/Edge oder in hybriden Umgebungen – sind gute nächste Schritte:

• Polycrate API-Dokumentation
• Workshops zu Polycrate und Automatisierung