Polycrate API für Teams: Zentrales Monitoring und Remote-Triggering

TL;DR

• Die Polycrate API macht aus einzelnen Workspaces eine Team-Plattform: alle Workspaces, Action Runs und SSH-Sessions zentral einsehbar – ideal für Betrieb, Compliance und Audits.
• Remote-Triggering über die API ersetzt lokale CLI-Installationen in CI/CD-Pipelines und auf Jump Hosts: Build-Agents reden per HTTP mit Polycrate, der Rest läuft in standardisierten Containern.
• Workspace-Validierung und zentrales Encryption Key Management werden zu wiederverwendbaren Services für Ihr gesamtes Team; HTTP-Endpoint-Monitoring der Plattform läuft über API und Polycrate Operator (nicht über einen Block in workspace.poly).
• Das Web-Dashboard der Polycrate API gibt Team-Leads und Compliance-Verantwortlichen einen sauberen Überblick: wer hat was, wann, wo ausgelöst – inklusive Reporting-Funktionen.
• ayedo stellt mit der Polycrate API ein Enterprise-Feature bereit, das sich nahtlos in Ihre Platform Engineering-Initiativen integrieren lässt – inklusive Unterstützung durch unsere Beratung.

Polycrate API als Team-Plattform statt Einzel-CLI

Mit plain Ansible sieht Automatisierung oft so aus:

• Jede Person hat eine eigene lokale Installation (oft mit unterschiedlichen Python-Versionen).
• Playbooks liegen verteilt in Git-Repos, Skript-Ordnern und Home-Verzeichnissen.
• CI/CD-Pipelines installieren Ansible pro Build-Agent neu oder verwenden selbstgebaute Images.
• Audits werden zum manuellen Log-Sammelprojekt.

Ansible ist ein exzellentes Automatisierungswerkzeug – aber es bringt von Haus aus keine zentrale Plattform für Teams mit. Genau hier setzt Polycrate an: Ansible läuft immer in einem Container mit definierter Toolchain, und mit der Polycrate API wird daraus eine Enterprise-Plattform.

Die Polycrate API bietet Ihnen:

• Zentrale Sicht auf alle Workspaces Ihres Teams
• Historie aller Action Runs (inkl. Exit-Status, Logs, Artefakte)
• Übersicht aller SSH-Sessions, die über Polycrate aufgebaut wurden
• Einheitliche, auditierbare Schnittstelle für externe Systeme (z. B. CI/CD)

Mehr technische Details finden Sie in der API-Dokumentation.

Architektur: Workspaces, Blöcke und API im Zusammenspiel

Polycrate strukturiert Automatisierung über Workspaces und Blöcke. Die API kennt diese Struktur und macht sie für Teams nutzbar.

Ein typischer Workspace könnte so aussehen:

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

blocks:
  - name: linux-patch
    from: linux-patch
    config:
      target_hosts: "all"

  - name: windows-patching
    from: cargo.ayedo.cloud/ayedo/infra/windows-patching:0.4.2
    config:
      maintenance_window: "Sun 02:00-04:00"

Die API weiß:

• Welche Blöcke in welchem Workspace instanziiert sind.
• Welche Block-Versionen verwendet werden (immer gepinnt, niemals :latest).
• Welche Konfiguration pro Block gesetzt ist.

Ein Block, den Sie lokal entwickeln, sieht z. B. so aus:

# blocks/linux-patch/block.poly
name: linux-patch
version: 0.1.0
kind: generic

config:
  target_hosts: "all"

actions:
  - name: patch
    description: "Security-Patches auf Linux-Servern"
    playbook: patch.yml

Das entsprechende Inventory liegt – wie von Polycrate vorgegeben – im Workspace-Root:

# inventory.yml
all:
  hosts:
    server01.acme-corp.com:
      ansible_user: ubuntu
    server02.acme-corp.com:
      ansible_user: ubuntu

Wichtig: Polycrate führt alle Playbooks in einem Container aus. Das eliminiert das klassische Dependency-Problem (unterschiedliche Ansible- oder Python-Versionen, fehlende Tools) und schafft reproduzierbare Ergebnisse – egal ob Sie lokal arbeiten oder die Polycrate API triggert.

Remote-Triggering: CI/CD ohne lokale Polycrate-Installation

In vielen Teams sieht eine CI/CD-Integration mit plain Ansible heute so aus:

# Build-Agent (z. B. GitLab Runner)
pip install ansible==9.4.0
ansible-playbook -i inventory.yml deploy.yml

Oder Sie bauen eigene Docker-Images mit Ansible und Tooling, die Sie in allen Pipelines pflegen müssen. Beides erzeugt Pflegeaufwand und Supply-Chain-Risiken.

Mit Polycrate reicht ein zentral betriebener Polycrate-API-Endpoint. Ihre Pipeline muss nur noch einen HTTP-Call ausführen, das eigentliche polycrate run läuft in der Plattform:

# Beispiel: Action lokal ausführen (nur zum Vergleich)
polycrate run linux-patch patch

In der CI/CD-Pipeline ruft Ihr Job stattdessen die API auf, z. B.:

curl -X POST \
  -H "Authorization: Bearer $POLYCRATE_TOKEN" \
  -H "Content-Type: application/json" \
  https://polycrate.example.com/api/v1/workspaces/acme-corp-automation/actions \
  -d '{
    "block": "linux-patch",
    "action": "patch",
    "reason": "Nightly patch run from CI",
    "parameters": {
      "extra_vars": {
        "patch_profile": "security-only"
      }
    }
  }'

Das ist eine vereinfachte Darstellung: Exakter Pfad, Authentifizierung und Request-Body richten sich nach Ihrer API-Version und der OpenAPI-Spezifikation Ihrer Instanz.

Die API:

• Validiert, ob der Workspace existiert.
• Prüft, ob der Block linux-patch und die Action patch definiert sind.
• Startet den Run in einem standardisierten Container.
• Liefert eine Run-ID zurück, über die Sie später Status und Logs abholen können.

Im Gegensatz zu einem direkt in der Pipeline ausgeführten ansible-playbook profitieren Sie von:

• Einheitlicher Toolchain im Container (kubectl, Helm, Python etc.) – kein individuelles Setup mehr.
• Zentralem Audit-Log: Jede Pipeline-Aktion taucht in der Polycrate API (Weboberfläche) auf.
• Sharable Automation: Das gleiche Block-Design kann von anderen Workspaces oder Teams via Registry geteilt und wiederverwendet werden.

Workspace-Validierung: registrierte Blöcke und kompatible Versionen

Wenn mehrere Teams denselben Block verwenden – z. B. einen offiziellen ayedo-Block aus dem PolyHub – wollen Sie sicherstellen, dass:

• Nur freigegebene Block-Versionen verwendet werden.
• Workspaces nicht versehentlich auf alte, unsichere Versionen zurückfallen.
• Neue Versionen kontrolliert ausgerollt werden.

Die Polycrate API kann Workspaces validieren:

• Sind alle from:-Referenzen auf bekannte Registries und Block-Namen gerichtet?
• Sind die verwendeten Versionen in Ihrem Unternehmen zugelassen?
• Passen API-Kompatibilität und Konfiguration zum definierten Block-Schema?

Diese Validierung lässt sich ebenfalls per Remote-Trigger auslösen – etwa als Quality-Gate in einer GitOps-Pipeline, bevor ein Merge in den main-Branch erfolgt. Details zu Best Practices für Blöcke und Versionierung finden Sie in den Polycrate-Best-Practices.

So wird die Polycrate API zum technischen Enforcer Ihrer Architektur- und Compliance-Vorgaben, ohne dass jedes Team eigene Validierungs-Skripte pflegen muss.

Integriertes HTTP-Endpoint-Monitoring (nicht über workspace.poly)

Das in der Polycrate API gebündelte Endpoint-Monitoring (Erreichbarkeit von URLs/Hosts per HTTP und ICMP, Agenten, Auswertung in der API) ist ein eigenes Subsystem: Es arbeitet mit Endpoint-Ressourcen in der API und Monitoring-Agenten – nicht mit einem Ansible-Block im workspace.poly, wie man ihn für polycrate run verwendet. In Kubernetes-Umgebungen spielt der Polycrate Operator eine zentrale Rolle (u. a. Endpoint-Discovery aus Ingress, Synchronisation mit der API). Details: Polycrate Operator und API-Dokumentation.

Unabhängig davon können Sie über Remote-Triggering weiterhin beliebige Actions ausführen – etwa den oben gezeigten Block linux-patch für Wartungsläufe. Das ist dasselbe Muster wie in den Abschnitten „Architektur“ und „Remote-Triggering“; es ersetzt nicht das integrierte Endpoint-Monitoring der Plattform.

Zentrales Encryption Key Management für Team-Workspaces

Polycrate bringt eingebaute Workspace-Verschlüsselung mit age mit. Sensible Dateien – etwa artifacts/secrets/kubeconfig.yml oder SSH-Schlüssel – können Sie so sicher im Git-Repo versionieren. Die Details dazu finden Sie in der Dokumentation zur Workspace-Verschlüsselung.

Ohne Polycrate API bedeutet das in der Praxis oft:

• Manuelles Verteilen von Age-Keys über Chat, E-Mail, Passwort-Manager.
• Unsicherheit, wer welche Schlüssel hat.
• Aufwändige Rotation, wenn Teammitglieder kommen oder gehen.

Die Polycrate API ergänzt dies um:

• Einen zentralen Schlüsselspeicher pro Organisation.
• Zugriffskontrolle: Welche Nutzer oder Service-Accounts dürfen welche Workspaces entschlüsseln?
• Integration mit der CLI: Die CLI kann beim Öffnen eines verschlüsselten Workspaces die entsprechenden Keys über die API beziehen – kein manuelles Copy & Paste mehr.

Die Verschlüsselung selbst definieren und initialisieren Sie weiterhin mit der CLI, z. B.:

# Workspace verschlüsseln (vereinfacht)
polycrate workspace encrypt --age-recipient age1...

Die Verwaltung der Keys – zu welchen Workspaces sie gehören, wer sie nutzen darf, wie Rotation organisiert wird – übernimmt die API. Für Compliance-Teams ist das ein zentraler Baustein: Schlüsselverwaltung wird nachvollziehbar, dokumentiert und revisionssicher.

Dashboard und Reporting: Was Team-Leads in der Polycrate API sehen

Die Polycrate-Weboberfläche auf Basis der API ist der Blick ins Innere Ihrer Automatisierungsplattform. Typische Sichten für Team-Leads und Compliance-Verantwortliche:

• Workspaces-Übersicht
  Liste aller registrierten Workspaces, inkl. Metadaten (Owner, letzte Aktivität, Anzahl Blöcke, Verschlüsselungsstatus).

• Action Runs
  Zeitliche Darstellung aller Runs – filterbar nach Workspace, Block, Action, Status oder auslösendem System (z. B. “GitLab CI”, “ServiceNow”, “manuell über CLI”). Aus jedem Eintrag können Sie Logs und relevante Artefakte öffnen.

• SSH-Sessions
  Transparenz über alle SSH-Verbindungen, die via Polycrate aufgebaut wurden – inklusive User, Ziel-Host, Zeitpunkt und optionalem Zweck-Tag. Für viele Compliance-Anforderungen (z. B. ISO 27001, SOC 2) ist das ein großer Schritt nach vorne.

• Compliance-Ansicht
  Übersicht, welche Workspaces validiert sind, wo veraltete Block-Versionen verwendet werden oder welche Workspaces nicht verschlüsselt sind. Das macht die Polycrate API zum praktischen Compliance-Backbone.

In vielen Platform Engineering-Initiativen ist genau diese Transparenz gefragt: Automatisierung soll skalieren, ohne dass Governance auf der Strecke bleibt. Die Polycrate API liefert die dafür nötigen Daten und Schnittstellen – und ayedo unterstützt Sie bei Bedarf mit unsere Beratung, diese Daten sinnvoll in Ihre Prozesse einzubetten.

Polycrate API als Compliance-Backbone

Regulatorische Anforderungen wie die DSGVO (in der EU seit dem 25.05.2018 verbindlich) oder branchenspezifische Normen verlangen nachvollziehbare Prozesse:

• Wer hat wann welche Infrastrukturänderung angestoßen?
• Wo liegen sensible Konfigurationsdaten – und sind sie verschlüsselt?
• Wie wird sichergestellt, dass nur freigegebene Automatisierungsbausteine verwendet werden?

Mit der Polycrate API konsolidieren Sie:

• Alle Action Runs (inkl. Context: Workspace, Block, Action, Auslöser).
• Alle SSH-Sessions.
• Den Verschlüsselungsstatus und die Key-Zuordnung von Workspaces.
• Den Versionsstand aller produktiv genutzten Blöcke.

Statt verstreuter Logfiles, unterschiedlichen Ansible-Versionen und individuell geschriebenen Auswertungs-Skripten haben Sie eine zentrale, dokumentierte API, die als Basis für Berichte, Dashboards und Audits dient. Für Enterprise-Architekten und Compliance-Verantwortliche ist das der Schritt von “Automatisierung funktioniert irgendwie” zu “Automatisierung ist ein klarer, kontrollierter Prozess”.

Weitere technische Details zur Polycrate API finden Sie in der offiziellen API-Dokumentation.

Häufige Fragen

Benötige ich die Polycrate API, um Polycrate nutzen zu können?

Nein. Polycrate funktioniert auch ohne API rein über die CLI – inklusive Container-Ausführung, Workspaces, Blöcke, Workspace-Verschlüsselung und Registry-Integration. Die Polycrate API kommt ins Spiel, wenn Sie:

• Team- oder organisationsweit zentralisieren wollen,
• CI/CD-Pipelines ohne lokale CLI-Installation anbinden möchten,
• oder einheitliches Monitoring, Reporting und Compliance benötigen.

Kurz: Für Einzelanwender oder kleine Teams reicht die CLI. Für Enterprise-Szenarien spielt die API ihre Stärken aus.

Wie unterscheidet sich Polycrate von einem selbstgebauten Ansible-Runner-Service?

Viele Unternehmen bauen sich interne “Ansible-Runner” mit ein bisschen REST-API, ein paar Docker-Containern und einer Datenbank. Das kann funktionieren, bedeutet aber:

• Sie schreiben und warten selbst den Code.
• Sie definieren selbst, wie Workspaces, Inventories, Credentials und Logs gemanagt werden.
• Sie tragen die Verantwortung für Security und Updates.

Polycrate bringt diese Aspekte als Produkt mit:

• Standardisiertes Modell (Workspaces, Blöcke, Actions, Workflows).
• Containerisierte Ausführung mit definierter Toolchain.
• Registry-Integration für sharable Automation.
• Eingebaute Workspace-Verschlüsselung und zentrales Key Management.
• API und Web-UI, die genau auf diese Struktur abgestimmt sind.

Sie müssen keinen eigenen Orchestrator erfinden, sondern können auf eine dokumentierte, erprobte Plattform setzen.

Welche Rolle spielt ayedo bei Betrieb und Integration der Polycrate API?

ayedo entwickelt und betreibt Polycrate und unterstützt Sie:

• Bei Architektur und Einführung der Plattform in bestehenden Umgebungen.
• Bei der Integration in Ihre CI/CD-Landschaft und Ihre Compliance-Prozesse.
• Bei der Entwicklung eigener Blöcke und der Nutzung des PolyHub-Ökosystems.

Ob Sie einen dedizierten Enterprise-Betrieb wünschen oder Polycrate in eine bestehende Plattform integrieren wollen – wir bringen Erfahrung aus vielen Projekten mit und passen Lösungen an Ihre Umgebung an.

Weitere Fragen? Siehe unsere FAQ

Von der Theorie zur Umsetzung

Mit der Polycrate API wird aus einem starken Automatisierungswerkzeug eine zentrale Plattform für Teams und Unternehmen: Workspaces, Blöcke und Actions werden nicht mehr nur lokal über die CLI bedient, sondern stehen als klar definierte Services zur Verfügung – inklusive Remote-Triggering, Monitoring, Workspace-Validierung und Encryption Key Management.

In diesem Beitrag haben Sie gesehen, wie:

• Polycrate alle Ausführungen in standardisierten Containern bündelt und damit das klassische Dependency-Problem von plain Ansible löst.
• Die API als einheitliche Schnittstelle dient, um CI/CD-Pipelines, Monitoring-Jobs oder Self-Service-Portale anzubinden – ohne lokale Polycrate-Installation.
• Zentrale Funktionen wie Workspace-Validierung, Schlüsselverwaltung und – bei Kubernetes – Endpoint-Monitoring über API und Polycrate Operator Ihre Compliance-Anforderungen unterstützen und Audits deutlich vereinfachen.

Für viele Organisationen fügt sich die Polycrate API nahtlos in bestehende Platform Engineering-Initiativen ein: Sie erhalten eine wiederverwendbare Grundlage für Automatisierung, die von Linux- und Windows-Admins über IoT-Teams bis hin zu Compliance-Verantwortlichen gleichermaßen genutzt werden kann. Wenn Sie dabei Unterstützung bei Architektur, Integration oder Block-Design wünschen, steht Ihnen ayedo mit unsere Beratung zur Seite.

Wenn Sie die Polycrate API als Enterprise-Feature in Ihrer Umgebung evaluieren möchten, starten Sie am besten mit einem fokussierten Use Case – etwa der Ablösung lokaler ansible-playbook-Aufrufe in einer CI/CD-Pipeline durch Remote-Triggering über die API. Genau dort werden die Vorteile von Standardisierung, Nachvollziehbarkeit und zentralem Monitoring besonders schnell sichtbar.

Gute nächste Schritte:

• Polycrate API-Dokumentation
• Workshops