Polycrate vs. plain Ansible: Was du gewinnst – und warum es sich lohnt

TL;DR

• Plain Ansible ist ein starkes Werkzeug für Ad-hoc-Automatisierung, schnelle Skripte und einfache Setups – aber Teams stoßen schnell an Grenzen bei Dependencies, Struktur und Sharing.
• Polycrate baut auf Ansible auf, kapselt es sauber im Container und bringt ein Block-/Workspace-Modell mit, das Dependency-Chaos, Playbook-Wildwuchs und Secret-Handling systematisch adressiert.
• Statt „ansible irgendwo installiert“ bekommst du mit Polycrate eine reproduzierbare, containerisierte Toolchain, Sharable Automation via OCI-Registry, Workspace-Verschlüsselung und Guardrails für größere Teams.
• Es gibt valide Szenarien, in denen plain Ansible die bessere Wahl ist – etwa für sehr kleine Umgebungen, temporäre Skripte oder eingeschränkte Umgebungen ohne Container.
• ayedo unterstützt dich dabei, den passenden Mix aus Ansible und Polycrate zu finden – von ersten Tests bis hin zu durchgängigem Platform Engineering mit automatisierter Compliance und Betriebssicherheit.

Polycrate und Ansible im direkten Vergleich

Ansible ist seit Jahren ein De-facto-Standard für Automatisierung – von Linux-Servern über Windows-Hosts bis zu Netzwerkkomponenten und IoT. Polycrate setzt genau dort an: Es ersetzt Ansible nicht, sondern strukturiert und operationalisiert es.

Eine grobe Einordnung:

Im Kern: Ansible ist die Engine, Polycrate ist das Operations-Framework darum herum.

Dependency-Management: Von „pip install ansible“ zu polycrate run

Der klassische Weg mit plain Ansible

Viele Teams starten so:

sudo apt-get install ansible

# oder
python3 -m venv .venv
source .venv/bin/activate
pip install ansible==9.5.1
pip install -r requirements.txt

Dazu kommen:

• unterschiedliche Python-Versionen (2.7 vs. 3.x, unterschiedliche Minor-Releases),
• manuelle Abhängigkeiten für Collections (z. B. azure.azcollection, community.general),
• individuelle ansible.cfg, SSH-Setups, PATH-Issues pro Arbeitsplatz.

Auf Teamebene bedeutet das:

• Onboarding ist mühsam („Welche Ansible-Version nutzt ihr?“),
• Fehler, die nur auf bestimmten Laptops auftreten,
• Supply-Chain-Risiken durch unkontrolliertes pip install aus dem Internet.

Polycrate: Ansible im Container, Toolchain inklusive

Mit Polycrate läuft Ansible immer in einem Container. Du brauchst lokal nur Polycrate und einen Container-Runtime (Docker, Podman):

polycrate run linux-patch patch

Was hier passiert:

• Polycrate startet einen definierten Container mit einer vordefinierten Toolchain (Ansible, Python, ggf. kubectl, helm, etc.).
• Das Ansible-Playbook wird immer in derselben Umgebung ausgeführt – auf jedem Entwickler-Laptop identisch.
• Es gibt kein pip install auf der Workstation, keine Python-Version-Konflikte, kein manuelles Setup.

Das löst das klassische Dependency-Problem:

• Kein lokales Ansible installieren,
• Kein Python-Versions-Chaos,
• Keine individuellen „Snowflake“-Workstations.

Details zur Integration findest du in der Ansible-Integration in Polycrate und den Best Practices.

Sharing: Git-Repos vs. Blöcke in der OCI-Registry

Wie Sharing mit plain Ansible typischerweise aussieht

Standard ist:

• Ein Git-Repo mit Playbooks und Rollen,
• evtl. ein internes Galaxy-ähnliches Repository,
• Dokumentation, welche Variablen wie gesetzt werden („Bitte lies README.md“).

Willst du ein Playbook aus einem anderen Team nutzen, musst du:

• das Git-Repo klonen,
• Abhängigkeiten installieren,
• ansible.cfg verstehen,
• Variablenstruktur und Konventionen lernen.

Das funktioniert, wird aber mit wachsender Organisation unübersichtlich.

Polycrate: Sharable Automation mit Blöcken

In Polycrate packst du Automatisierung in Blöcke. Jeder Block ist:

• versioniert,
• portabel,
• via OCI-Registry teilbar (z. B. cargo.ayedo.cloud oder eigene Registry),
• wiederverwendbar konfigurierbar über workspace.poly.

Ein Beispiel für einen lokalen Block blocks/linux-patch/block.poly:

name: linux-patch
version: 0.1.0
kind: generic

config:
  target_hosts: all
  maintenance_window: "sunday-2200"

actions:
  - name: patch
    description: "Führt ein dist-upgrade auf Linux-Servern durch"
    playbook: patch.yml

Ausschnitt aus workspace.poly, der den Block instanziiert:

name: acme-corp-automation
organization: acme

blocks:
  - name: linux-patch
    from: linux-patch
    config:
      target_hosts: all
      maintenance_window: "sunday-2200"

Ein anderer Workspace – vielleicht von einem anderen Team – könnte denselben Block über eine Registry referenzieren:

name: acme-ops
organization: acme

blocks:
  - name: linux-patch-prod
    from: cargo.ayedo.cloud/acme/linux/linux-patch:0.1.0
    config:
      target_hosts: prod-linux
      maintenance_window: "saturday-2300"

Mit polycrate run linux-patch-prod patch nutzen sie deine Automatisierung, ohne:

• dein Git-Layout zu kennen,
• deine ansible.cfg zu übernehmen,
• deine Collections-Installationsroutinen zu wiederholen.

Das ist „Sharable Automation“: Was du baust, können andere sofort nutzen – versioniert und reproduzierbar. Mehr dazu in der PolyHub-Dokumentation und direkt in PolyHub unter hub.polycrate.io.

Secrets und Compliance: Ansible Vault vs. Workspace-Verschlüsselung

Ansible Vault in der Praxis

Ansible Vault ist bewährt, aber aufwendig im Umgang:

• Du musst entscheiden: Ganze Datei verschlüsseln oder nur einzelne Variablen?
• Passwörter oder Vault-IDs müssen sicher verteilt und verwaltet werden.
• Integration in CI/CD ist möglich, aber meist speziell „hingebogen“.

Compliance-seitig (z. B. im Kontext der DSGVO, die am 25.05.2018 in Kraft trat) stellst du Fragen wie:

• Wo liegen meine Secrets im Git-Repo?
• Wer hat Zugriff auf Vault-Keys?
• Wie dokumentiere ich, dass Secrets verschlüsselt sind?

Polycrate: Workspace-Verschlüsselung mit age

Polycrate geht einen anderen Weg: Der gesamte Workspace (oder ausgewählte Teile, insbesondere artifacts/secrets/) kann mit age verschlüsselt werden. Du brauchst keinen separaten Vault-Dienst.

Typisches Vorgehen:

# Workspace initialisieren (wenn noch nicht geschehen)
polycrate workspace init

# Secrets hinzufügen, z.B. SSH-Keys, API-Tokens
mkdir -p artifacts/secrets
echo "super-secret-password" > artifacts/secrets/db-password.txt

# Workspace verschlüsseln
polycrate workspace encrypt

Polycrate kümmert sich darum, dass:

• Secrets nicht im Klartext im Git-Repo landen,
• Zugriffe über das CLI geregelt sind,
• Actions beim Ausführen transparent auf die entschlüsselten Inhalte zugreifen.

Vorteile gegenüber Vault:

• Keine zusätzliche Server-Komponente (kein HashiCorp Vault o. Ä.),
• Einfache Bedienung für Admins und Engineers,
• Direkte Integration in das Workspace-Modell.

Details findest du in der Dokumentation zur Workspace-Verschlüsselung.

Struktur und Guardrails: Vom Playbook-Wildwuchs zum Block-Modell

Plain Ansible: Frei, aber schnell unübersichtlich

Mit Ansible kannst du deine Struktur komplett frei wählen:

• playbooks/, roles/, group_vars/, host_vars/, inventories/ …
• Projekt A nutzt eine andere Struktur als Projekt B,
• Konventionen existieren – werden aber nicht erzwungen.

In kleinen Teams ist das oft okay. In größeren Umgebungen wird es schnell chaotisch:

• Du findest nicht sofort heraus, wo eine Variable herkommt,
• Änderungen an globalen Variablen haben unerwartete Seiteneffekte,
• Es entstehen leicht „Einmal-Playbooks“, die niemand mehr versteht.

Polycrate: Block/Action/Workspace als Strukturrahmen

Polycrate gibt dir ein klares Framework:

• Workspace: Oberste Ebene (workspace.poly), zentrale Konfiguration, Inventories, Secrets.
• Block: Fachlich abgegrenzte Einheit (z. B. Linux-Patching, AD-Benutzerverwaltung, Kubernetes-Deployment).
• Action: Konkrete Operation innerhalb eines Blocks (z. B. patch, dry-run, rollback).

Dieser Rahmen verhindert Playbook-Wildwuchs und schafft Guardrails. Jede Action wird exakt so aufgerufen:

polycrate run linux-patch patch

Keine langen ansible-playbook-Kommandos mit zig Parametern – gut verständlich auch für Kolleg:innen, die nicht täglich Ansible schreiben.

Beispiel: Linux-Patching mit Ansible vs. Polycrate

Plain Ansible Playbook patch.yml:

- name: Linux-Systeme patchen
  hosts: all
  become: true

  tasks:
    - name: Paketliste aktualisieren
      ansible.builtin.apt:
        update_cache: yes

    - name: Dist-Upgrade durchführen
      ansible.builtin.apt:
        upgrade: dist
        autoremove: yes
        autoclean: yes

Inventory als YAML (inventory.yml):

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

Aufruf mit plain Ansible:

ANSIBLE_INVENTORY=inventory.yml ansible-playbook patch.yml

Jetzt dasselbe mit Polycrate. Wir nutzen denselben Inhalt von patch.yml, aber parametrisieren hosts:

- name: Linux-Systeme patchen (Polycrate)
  hosts: "{{ block.config.target_hosts }}"
  become: true

  tasks:
    - name: Paketliste aktualisieren
      ansible.builtin.apt:
        update_cache: yes

    - name: Dist-Upgrade durchführen
      ansible.builtin.apt:
        upgrade: dist
        autoremove: yes
        autoclean: yes

Unser Block blocks/linux-patch/block.poly:

name: linux-patch
version: 0.1.0
kind: generic

config:
  target_hosts: all
  maintenance_window: "sunday-2200"

actions:
  - name: patch
    description: "Führt ein dist-upgrade auf den definierten Hosts durch"
    playbook: patch.yml

Und workspace.poly im Root-Verzeichnis:

name: acme-corp-automation
organization: acme

config:
  environment: "prod"

blocks:
  - name: linux-patch
    from: linux-patch
    config:
      target_hosts: all
      maintenance_window: "sunday-2200"

Aufruf:

polycrate run linux-patch patch

Wichtige Punkte:

• Das Inventory (inventory.yml) liegt im Workspace-Root – Polycrate setzt ANSIBLE_INVENTORY automatisch.
• Die Variablen block.config.* kommen aus workspace.poly und werden mit der Block-Config „deep-merged“. Du hast ein zentrales Konfigurationsmodell statt verstreuter group_vars und host_vars.
• Die Guardrails des Block-Modells sorgen dafür, dass deine Automatisierung modular, nachvollziehbar und testbar bleibt.

Mehr zur Workspace- und Block-Struktur findest du in den Docs zu Workspaces, Blöcken und Actions.

Konfigurationsmanagement: Hardcoded Variablen vs. Deep-Merge

In plain Ansible siehst du häufig:

• hartkodierte Variablen im Playbook,
• Variablen in vars/, group_vars/, host_vars/,
• Überschreibungen über -e auf der CLI.

Das ist flexibel, aber:

• die Quelle einer Variable ist manchmal schwer nachzuvollziehen,
• du musst Konventionen strikt durchsetzen, sonst herrscht Wildwuchs.

Polycrate ergänzt hier:

• workspace.config für globale Defaults,
• block.config pro Block-Instanz,
• zusätzliche Parameter pro Action (z. B. interaktive Eingaben oder Pipeline-Parameter),
• ein definiertes Deep-Merge-Verhalten dieser Ebenen.

Damit lassen sich Umgebungen sauber trennen:

• workspace.config.environment = "prod" vs. "dev",
• unterschiedliche target_hosts pro Block-Instanz,
• dennoch dieselben Blöcke und Playbooks.

Du behältst alle Stärken von Ansible (Idempotenz, große Modulauswahl), bekommst aber ein klar definiertes Konfigurationsmodell auf Workspace-Ebene dazu.

Ökosystem: Ansible Galaxy vs. PolyHub

Ansible Galaxy ist ein riesiger Pool an Rollen und Collections. Viele davon kannst du direkt in Polycrate-Blöcken nutzen:

• collections: in requirements.yml,
• roles: in deinen Playbooks.

Polycrate ergänzt dieses Ökosystem:

• Mit PolyHub gibt es kuratierte, versionierte Blöcke für Infrastruktur, Monitoring, Security, Storage und mehr.
• Offizielle ayedo-Blöcke kapseln häufige Aufgaben (z. B. Kubernetes-Basisdeployments, Monitoring-Stacks, Security-Scans) in wiederverwendbare Bausteine.
• Eigene Unternehmens-Blöcke können in einer privaten Registry bereitgestellt werden.

So kombinierst du:

• das breite Ökosystem von Ansible Galaxy,
• mit dem strukturierten Block-Ansatz und Sharing-Modell von Polycrate.

Wann plain Ansible die bessere Wahl ist

Polycrate ist kein Allheilmittel und nicht für jede Situation die richtige Wahl. Szenarien, in denen plain Ansible oft völlig ausreichend oder sogar besser geeignet ist:

• Sehr kleine Umgebungen: Zwei, drei Server, ein Admin, wenig Team-Kollaboration. Hier kann ein handgebautes Playbook mit ansible-playbook völlig reichen.
• Kurzlebige Skripte und Prototypen: Schnell mal ein Task ausprobieren, eine einmalige Migration, ein ad-hoc API-Call – hier ist ein einzelnes Playbook ohne Workspace schneller erstellt.
• Stark eingeschränkte Umgebungen: Wenn weder Docker noch Podman nutzbar sind und du auf bestehenden System-Paketen aufsetzen musst.
• Bestehende, gut gepflegte Ansible-Landschaften: Wenn du bereits ein sauber strukturiertes Ansible-Projekt mit konsistenten Konventionen, CI/CD-Integration und Secret-Handling hast, kann der Mehrwert von Polycrate geringer sein – oder sich vor allem im Sharing und in der einheitlichen Developer-Toolchain zeigen.

Wichtig: Polycrate setzt auf Ansible auf. Du musst nicht „umsteigen“, sondern kannst Schritt für Schritt:

• bestehende Playbooks als Blöcke kapseln,
• neue Automatisierung gleich im Block-Modell aufbauen,
• für komplexere Themen (Kollaboration, Compliance, Reproduzierbarkeit) auf Polycrate setzen,
• einfache Einmal-Automatisierungen weiterhin mit plain Ansible laufen lassen.

Häufige Fragen

Kann ich meine bestehenden Ansible-Playbooks in Polycrate weiterverwenden?

Ja. Polycrate nutzt Ansible im Container. Du kannst:

1. dein bestehendes Playbook in ein Block-Verzeichnis legen,
2. eine block.poly anlegen, die auf dieses Playbook verweist,
3. den Block im workspace.poly referenzieren,
4. das Playbook mit polycrate run BLOCK ACTION ausführen.

Der Migrationsaufwand hängt davon ab, wie „wild“ deine bestehende Struktur ist. In vielen Fällen reicht es, hosts-Deklarationen leicht zu parametrisieren (z. B. hosts: "{{ block.config.target_hosts }}") und Inventory/Variablen ins Workspace-Modell zu überführen. Die Ansible-Integration in Polycrate zeigt dieses Vorgehen Schritt für Schritt.

Brauche ich Kubernetes- oder Container-Expertise, um Polycrate sinnvoll zu nutzen?

Du brauchst kein Kubernetes-Know-how, aber ein grundlegendes Verständnis von Containern hilft. Polycrate nutzt Container, um Ansible und die Toolchain reproduzierbar auszuführen. Für klassische Szenarien – Linux-/Windows-Server, AD, IoT/Edge – musst du keine Container-Images selbst bauen, sondern kannst auf die Standard-Toolchain setzen oder eine bereitgestellte Toolchain im Unternehmen verwenden. Wenn du bereits im Bereich Platform Engineering unterwegs bist, fügt sich Polycrate besonders gut in deine bestehende Container- und GitOps-Landschaft ein.

Ist Polycrate nur für große Unternehmen sinnvoll?

Nein. Polycrate adressiert zwar viele Probleme, die in größeren Organisationen besonders sichtbar werden (Dependency-Chaos, Sharing, Compliance, Multi-Team-Kollaboration), aber auch kleinere Teams profitieren von:

• leichteren Onboarding-Prozessen,
• sauberer Trennung von Blöcken,
• eingebauter Workspace-Verschlüsselung ohne zusätzlichen Vault-Stack.

Wenn du heute schon spürst, dass deine Ansible-Landschaft wächst und unübersichtlich wird, lohnt sich ein Blick auf Polycrate – bevor der Playbook-Wildwuchs richtig einsetzt.

Weitere Fragen? Siehe unsere FAQ

Von der Theorie zur Umsetzung

Plain Ansible und Polycrate sind keine Gegensätze, sondern zwei Ebenen derselben Idee: Skriptbare, deklarative Infrastruktur und Automatisierung. Ansible liefert die mächtige Engine, Polycrate kümmert sich um die operationalen Themen, die in der Praxis schnell weh tun: Dependencies, Sharing, Struktur, Secrets und Wiederverwendbarkeit.

In diesem Beitrag hast du gesehen:

• wo Polycrate ganz konkret Mehrwert liefert (Container-Toolchain, Guardrails, Workspace-Verschlüsselung, Block-Sharing),
• wann plain Ansible vollkommen ausreicht,
• wie ein einfacher Use Case – Linux-Patching – mit beiden Ansätzen aussieht,
• wie das Block-/Workspace-Modell eine Brücke schlägt zwischen einzelnen Playbooks und einem strukturierten Automatisierungs-Portfolio.

Als ayedo begleiten wir Teams von ersten Experimenten mit Polycrate bis hin zu durchgängigen Platform-Engineering-Setups, in denen Ansible, Polycrate, Monitoring, Security und Compliance sauber zusammenspielen. Ob du heute vor allem Ansible optimieren oder morgen eine komplette Polycrate-basierte Automatisierungsplattform aufbauen willst – wichtig ist, dass die nächsten Schritte pragmatisch, nachvollziehbar und für dein Team handhabbar sind.

Wenn du selbst erleben möchtest, wie sich polycrate run im Vergleich zu ansible-playbook in deinem Alltag anfühlt, ist jetzt ein guter Zeitpunkt, es auszuprobieren.

Übersicht und Anmeldung: Workshops.