Enterprise-Automatisierung: Blöcke bauen, versionieren und im Team teilen

TL;DR

• In vielen Enterprise-Organisationen baut jedes Team seine eigene Ansible-Welt – ohne klare Versionierung, ohne zentrale Wiederverwendung, ohne Governance. Das skaliert organisatorisch nicht.
• Polycrate macht aus Ansible-Playbooks wiederverwendbare, versionierte Blöcke, die in einer internen OCI-Registry (z. B. Harbor oder registry.acme-corp.com) veröffentlicht und von beliebigen Teams genutzt werden können.
• Das Block-Modell schafft Guardrails: Klare Schnittstellen, Semantic Versioning, CHANGELOG.poly und einfache Actions statt Playbook-Wildwuchs – inklusive Compliance-Mechanismen, damit nur freigegebene Block-Versionen in Produktion verwendet werden.
• Durch die containerisierte Ausführung von Polycrate entfallen lokale Ansible-Setups und Python- bzw. Dependency-Chaos. Jede Entwickler-Workstation arbeitet mit derselben Toolchain; Blöcke lassen sich sicher teilen und in der Registry versionieren.
• ayedo unterstützt Sie mit Platform Engineering, Polycrate-Expertise und einem Enterprise-Platform Workshop dabei, ein unternehmensweites Automatisierungs-Ökosystem aufzubauen, das Teams befähigt und Compliance-Anforderungen erfüllt.

Warum Enterprise-Sharing mit plain Ansible selten funktioniert

Wenn Sie heute in ein größeres Unternehmen schauen, sehen Sie oft das gleiche Muster:

• Das Linux-Team hat ein eigenes Ansible-Repo.
• Das Windows-Team hat ein anderes.
• Das Netzwerk-Team nutzt wieder etwas Eigenes – oder gar kein Ansible.
• Fachbereiche lassen sich von einzelnen Engineers Ad-hoc-Playbooks bauen.

Alle lösen ähnliche Probleme, aber mit verschiedenen Verzeichnisstrukturen, Rollen, Modulen und Abhängigkeiten. Wissen steckt in Köpfen und Git-Repos, nicht in einem konsistenten Automatisierungs-Produkt.

Typische Symptome:

• Kein einheitlicher Standard: Verzeichnisstruktur, Variablennamen, Inventories, Rollen – alles anders.
• Kein echtes Versioning auf Baustein-Ebene: Es gibt vielleicht Git-Tags fürs Gesamt-Repo, aber kein klares „VPN-Block 1.2.0 vs. 2.0.0“.
• Dependency-Probleme: Unterschiedliche Python-Versionen, Module, Ansible-Versionen auf jedem Admin-Laptop.
• Schlechtes Sharing: „Kannst du mir dein Playbook schicken?“ ist kein nachhaltiger Verteilmechanismus.

Mit plain Ansible müssten Sie für Enterprise-Sharing:

• ein zentrales Git-Monorepo durchsetzen,
• Konventionen für Ordnerstruktur, Rollen und Wiederverwendung definieren,
• disziplinierte Versionierung auf Rollen- oder Collection-Ebene etablieren,
• allen Teams eine konsistente Toolchain (Python, Ansible, Module) bereitstellen.

Ansible ist ein exzellentes Werkzeug – aber es bringt diese Enterprise-Governance und das Sharing-Modell nicht von Haus aus mit. Genau hier setzt Polycrate an.

Polycrate-Blöcke als Bausteine Ihrer Plattform

Polycrate verpackt Ansible-Playbooks, Konfiguration und Toolchain in klar definierte Blöcke. Ein Block ist:

• eine klar abgegrenzte Funktion (z. B. „VPN anlegen“, „AD-Benutzer verwalten“, „Linux patchen“),
• mit einer stabilen Schnittstelle (config-Parameter im Block),
• mit versionierter Implementierung (Semantic Versioning wie 1.0.0, 1.1.0, 2.0.0),
• verteilt über eine OCI-Registry (Harbor, registry.acme-corp.com oder PolyHub).

Für Enterprise-Architekten und Platform-Teams ergibt sich damit ein Modell, das sie aus der Container-Welt kennen: Ein Team baut Images (hier: Blöcke), andere Teams konsumieren sie.

Platform-Team als Block-Produzent, Domänen-Teams als Konsumenten

In einem reifen Setup sieht das so aus:

• Ein Platform- oder Networking-Team entwickelt und pflegt einen „VPN-Block“.
• Dieser Block wird in die unternehmensweite OCI-Registry (registry.acme-corp.com) veröffentlicht.
• Applikations-Teams binden den Block einfach über from: in ihrem workspace.poly ein und führen ihn per polycrate run aus.
• Semantic Versioning und ein gepflegter CHANGELOG.poly kommunizieren klar, was sich zwischen Versionen ändert – inklusive Breaking Changes.

Polycrate löst dabei gleich mehrere Kernprobleme:

1. Dependency-Problem eliminiert:
   Ansible läuft ausschließlich im Polycrate-Container. Python-Version, Ansible-Version, ansible-galaxy-Collections – alles ist Teil der Container-Toolchain und damit für alle Teams identisch. Kein „läuft bei mir nicht wegen Python 3.11“.

2. Sharable Automation per Registry:
   Blöcke werden über eine OCI-Registry versioniert und geteilt – wie Container-Images. Was das Platform-Team baut, kann das App-Team in Sekunden nutzen. Mehr dazu in der Registry-Dokumentation und den Best Practices.

3. Guardrails statt Playbook-Wildwuchs:
   Das Block-Modell gibt Ihrer Ansible-Automatisierung Struktur. Anstatt „irgendein Playbook aus dem Repo aufrufen“ gibt es klar definierte Actions (create, update, delete) mit dokumentierten Parametern.

Enterprise: Audit-Trail über die Polycrate API (Action Runs)

Für Governance und Nachvollziehbarkeit ist die Polycrate API relevant: Ist die CLI mit der API verbunden (api.enabled und API-Key in ~/.polycrate/polycrate.yml), werden Ausführungen von polycrate run … als Action Runs an die API übermittelt (konfigurierbar über submit_action_runs bzw. --api-submit-action-runs, standardmäßig typischerweise aktiv). So entsteht ein zentraler Work-Trail pro Workspace: wer hat welche Action auf welchem Block ausgeführt, wann, mit welchem Exit-Code und Kontext – statt nur verteilter Laptop-Logs. In der API/Web-Oberfläche lassen sich Action-Runs und Historie auswerten – ein Baustein für Auditierbarkeit neben Git und CHANGELOG.poly. Siehe Polycrate API und Audit & Compliance.

Praxisbeispiel: VPN-Block des Networking-Teams

Angenommen, Ihr Networking-Team betreibt zentral eine Firewall-/VPN-Appliance mit HTTP-API. Es soll einen Block bereitstellen, mit dem Fachbereiche selbstständig Site-to-Site-VPNs anlegen können – natürlich kontrolliert und dokumentiert.

Der Block: vpn-site2site

Der Block wird nach dem Push unter einem Registry-Pfad wie blocks/registry.acme-corp.com/acme/networking/vpn-site2site/ gepflegt (nach polycrate pull). Die block.poly könnte so aussehen:

name: registry.acme-corp.com/acme/networking/vpn-site2site
version: 1.0.0
kind: generic

config:
  vpn_name: ""
  peer_cidr: ""
  appliance_api_url: ""
  appliance_api_token: ""

actions:
  - name: create
    description: "Erstellt ein Site-to-Site-VPN auf der zentralen Appliance"
    playbook: create.yml

  - name: delete
    description: "Entfernt ein Site-to-Site-VPN von der zentralen Appliance"
    playbook: delete.yml

Wichtig aus Enterprise-Sicht:

• Die Schnittstelle ist klar: Wer den Block nutzt, muss vpn_name, peer_cidr, appliance_api_url und appliance_api_token liefern.
• Alles Weitere – API-Details, Fehlerbehandlung, Logging – bleibt Sache des Networking-Teams.

Das Ansible-Playbook im Block

Das create.yml-Playbook ruft die API der Appliance aus dem Polycrate-Container heraus auf. Das ist ein zulässiger Fall für hosts: localhost, weil die Aktion bewusst im Container ausgeführt wird (HTTP-API-Call, kein SSH-Login auf Ziel-Hosts):

- name: Create site-to-site VPN
  hosts: localhost
  gather_facts: false

  vars:
    vpn_name: "{{ block.config.vpn_name }}"
    peer_cidr: "{{ block.config.peer_cidr }}"
    api_url: "{{ block.config.appliance_api_url }}"
    api_token: "{{ block.config.appliance_api_token }}"

  tasks:
    - name: Create VPN via appliance API
      ansible.builtin.uri:
        url: "{{ api_url }}/vpn"
        method: POST
        headers:
          Authorization: "Bearer {{ api_token }}"
          Content-Type: "application/json"
        body_format: json
        body:
          name: "{{ vpn_name }}"
          peer_cidr: "{{ peer_cidr }}"
      register: vpn_result

    - name: Print VPN ID
      ansible.builtin.debug:
        msg: "Created VPN {{ vpn_name }} with id {{ vpn_result.json.id }}"

Die Variablen stammen aus block.config.* – damit ist die Schnittstelle des Blocks stabil, selbst wenn sich intern etwas ändert (z. B. zusätzliche API-Parameter).

CHANGELOG.poly als Kommunikationsmedium

Damit andere Teams verstehen, welche Änderungen zwischen den Versionen passieren (und ob es Breaking Changes gibt), pflegt das Networking-Team eine CHANGELOG.poly im Block-Verzeichnis. Format und Felder entsprechen den Polycrate-Konventionen: Liste von Einträgen mit version, date, type (feat, fix, chore, breaking), message sowie description (mehrzeilig); optional author (z. B. Team oder Person). Breaking Changes werden über type: breaking und die Beschreibung kenntlich gemacht – nicht über ein frei erfundenes releases:/breaking_changes:-Schema.

# CHANGELOG.poly (vereinfachtes Beispiel)
- version: "1.0.0"
  date: "2025-03-10"
  type: feat
  author: "Networking Team <netzwerk@acme-corp.com>"
  message: "Initiales VPN-Site-to-Site-Modul"
  description: |
    - Site-to-Site-VPNs mit Name und peer_cidr anlegen und löschen
    - API-Integration mit zentraler Firewall-Appliance, Auth per Bearer Token

- version: "1.1.0"
  date: "2025-04-22"
  type: feat
  message: "Optionales local_cidr, besseres API-Logging"
  description: |
    - Optionales Feld local_cidr (kompatibel zu 1.0.0)
    - Verbessertes Fehler-Logging bei API-Fehlern

- version: "2.0.0"
  date: "2025-06-01"
  type: breaking
  message: "Umbenennung peer_cidr, mehrere Peer-Netze"
  description: |
    - **Breaking:** Feld peer_cidr in peer_network umbenannt – Migration der Workspace-Configs nötig
    - Unterstützung für mehrere Peer-Netze im VPN

Ausführliche Konventionen: Best Practices – Changelog führen und Versionierung / Change Types.

Mit Semantic Versioning ist klar:

• 1.1.0 ist kompatibel zu 1.0.0 (Minor-Upgrade, neue Option).
• 2.0.0 enthält Breaking Changes – Konsumenten müssen ihre Konfiguration anpassen.

Nutzung im App-Team-Workspace

Ein Applikations-Team möchte nun für seine CRM-Anwendung ein VPN in den Hosting-Provider aufbauen. Es nutzt dafür den vom Networking-Team bereitgestellten Block.

workspace.poly des App-Teams

Im Root-Verzeichnis des Workspaces liegt die workspace.poly. Wichtig: In workspace.poly (und block.poly) gibt es keine Jinja- oder Env-Substitution – Zeilen wie {{ workspace.secrets[...] }} werden nicht ausgewertet. Sensible Block-Werte gehören in secrets.poly (Merge mit workspace.poly). Die config-Sektion auf Workspace-Ebene ist kein beliebiges Key-Value-Grab bag für Anwendungslogik; dokumentierte Felder wie environment oder optional image (Container-Image) beschreibt die Konfiguration.

name: acme-corp-automation
organization: acme

config:
  environment: production

blocks:
  - name: vpn-to-crm
    from: registry.acme-corp.com/acme/networking/vpn-site2site:1.0.0
    config:
      vpn_name: "vpn-crm-prod"
      peer_cidr: "10.50.0.0/16"
      appliance_api_url: "https://firewall-prod.acme-corp.com/api"
      appliance_api_token: ""

Das API-Token trägt das Team in secrets.poly nach (wird mit secrets.poly.age versioniert und über Workspace-Verschlüsselung geschützt), nicht in der öffentlichen workspace.poly:

# secrets.poly – sensible Overrides für die Block-Instanz
blocks:
  - name: vpn-to-crm
    config:
      appliance_api_token: "<Bearer-Token>"

Einige wichtige Punkte:

• from: enthält die vollständige Registry-Referenz mit expliziter Version :1.0.0 – kein :latest.
• Das App-Team entscheidet bewusst, welche Version es verwendet. Ein Update auf 1.1.0 oder 2.0.0 ist eine Änderung im Workspace und damit nachvollziehbar.
• Secrets in secrets.poly und Dateien unter artifacts/secrets/ werden mit Polycrate-integrierter Workspace-Verschlüsselung (age) gesichert – ein wichtiger Compliance-Aspekt, insbesondere seit Inkrafttreten der DSGVO am 25.05.2018. Siehe Workspace-Verschlüsselung.

Inventory: Für dieses Beispiel (hosts: localhost, reine API-Calls) ist kein inventory.yml nötig. Nutzen andere Blöcke im selben Workspace SSH-Ziele, liegt das Inventory wie üblich als inventory.yml im Workspace-Root, z. B.:

# inventory.yml (nur wenn SSH-Hosts angesprochen werden)
all:
  children:
    app_servers:
      hosts:
        app01.example.com:
          ansible_user: deploy

Das App-Team führt die Automation einfach aus:

polycrate run vpn-to-crm create

Damit startet Polycrate einen Container mit der vordefinierten Toolchain, lädt bei Bedarf inventory.yml, merged workspace.poly und secrets.poly zu block.config und führt das Playbook create.yml innerhalb des Containers aus.

Vergleich: Wie sähe das mit plain Ansible aus?

Ohne Polycrate müsste das Networking-Team:

• Ein Git-Repository mit Rollen/Playbooks bereitstellen.
• Dokumentieren, wie ansible-playbook mit welchen Variablen aufzurufen ist.
• Sicherstellen, dass alle Teams dieselben Python-/Ansible-/Collection-Versionen installiert haben.
• Versionierung über Git-Tags und manuelle Konventionen organisieren.

Das App-Team müsste:

• Das Repo clonen oder per Submodul einbinden.
• Lokale Variablen-Files anlegen.
• Sich einen eigenen Weg überlegen, wie „freigegebene“ Versionen identifiziert werden.

Mit Polycrate reicht:

• from: registry.acme-corp.com/acme/networking/vpn-site2site:1.0.0 in der workspace.poly.
• Ein polycrate run vpn-to-crm create.

Der Rest – Container-Toolchain, Ansible-Version, Module, Inventory-Handling – kommt aus Polycrate. Das reduziert Reibung und Fehlerquellen massiv.

Block-Lifecycle und Governance im Enterprise-Kontext

Für Enterprise-Architekten ist nicht nur die Technik wichtig, sondern vor allem der Lifecycle und die Governance.

Bauen → Testen → Taggen → Pushen → Pullen

Ein typischer Lifecycle im Networking-Team könnte so aussehen:

1. Bauen:
   Der Block wird lokal unter blocks/registry.acme-corp.com/acme/networking/vpn-site2site/ entwickelt (bzw. entsprechend nach Pull aus der Registry). Polycrate nutzt einen Container, in dem alle benötigten Tools (Ansible, ansible.builtin.uri, ggf. weitere Collections) definiert sind.

2. Testen:
   Tests laufen in einer Staging-Umgebung, z. B. über CI, die polycrate run vpn-site2site create mit Testparametern ausführt.

3. Taggen:
   Sobald eine Version stabil ist, wird in block.poly die version auf z. B. 1.1.0 gesetzt und in CHANGELOG.poly dokumentiert.

4. Pushen in die Registry:
   Der Block wird in die interne OCI-Registry (registry.acme-corp.com) hochgeladen. Wie genau der Push erfolgt, ist in der Registry-Dokumentation beschrieben.

5. Pullen durch andere Teams:
   Applikations- oder Infrastruktur-Teams referenzieren die freigegebene Version über from: registry.acme-corp.com/acme/networking/vpn-site2site:1.1.0 in ihrer workspace.poly.

So entsteht ein unternehmensweites Ökosystem:

• Das Networking-Team liefert VPN-Blöcke.
• Das Windows-Team liefert AD-/GPO-Blöcke.
• Das Linux-Team liefert Patch-Management-Blöcke.
• Das Platform-Team stellt generische Blöcke für Kubernetes, Monitoring oder Storage bereit – oder nutzt offizielle Blöcke aus PolyHub (hub.polycrate.io/) als Basis.

Governance: Welche Version darf in Produktion?

Compliance-Verantwortliche wollen sicherstellen, dass in Produktions-Workspaces nur freigegebene Block-Versionen genutzt werden. Typische Mechanismen:

• Whitelisting von Tags:
  Nur bestimmte Tags (z. B. 1.0.0, 1.1.0) werden im Registry-UI als „freigegeben für Prod“ markiert.

• Review-Prozesse auf Workspace-Ebene:
  Jede Änderung an workspace.poly (insbesondere from:-Zeilen) läuft über Code-Review. So sehen Reviewer sofort, wenn ein Block von 1.0.0 auf 2.0.0 umgestellt wird – inklusive Blick in CHANGELOG.poly.

• Policy as Code:
  Zusätzliche Checks in CI/CD-Pipelines stellen sicher, dass in produktiven Workspaces nur Tags aus einer genehmigten Liste genutzt werden.

Die integrierte Workspace-Verschlüsselung von Polycrate hilft zusätzlich: Secrets liegen per polycrate workspace encrypt verschlüsselt im Repo. Kein externer Vault ist zwingend nötig – ein Pluspunkt für Auditierbarkeit und Einfachheit, siehe auch die Dokumentation zur Workspace-Verschlüsselung.

Gute UX/DX: Actions statt CLI-Wirrwarr

Für die konsumierenden Teams reduziert sich die Komplexität:

• Niemand muss wissen, wie ansible-playbook im Detail aufzurufen ist.
• Es reicht, polycrate run BLOCK ACTION auszuführen – auch für Kolleg:innen, die nicht tief in Ansible stecken.
• Das verbessert die Developer Experience (DX) und macht Automatisierung auch für Abteilungsleiter-Teams nutzbar, die nur hin und wieder eine VPN-Verbindung oder ein AD-Konto anlegen lassen möchten.

Die Best Practices helfen dabei, Block-Schnittstellen konsistent zu gestalten und Naming-Patterns unternehmensweit zu etablieren.

Häufige Fragen

Brauchen wir Polycrate, wenn wir schon ein zentrales Ansible-Git-Repo haben?

Ein zentrales Git-Repo ist ein guter erster Schritt, löst aber drei Kernprobleme nicht vollständig:

1. Toolchain-Konsistenz:
   Git regelt nicht, welche Python-/Ansible-Version, Collections oder CLI-Tools auf den Developer-Workstations installiert sind. Polycrate kapselt diese Abhängigkeiten in Containern – jede:r arbeitet mit der gleichen Umgebung.

2. Sharable Automation als Produkt:
   Git-Rollen sind nicht automatisch „produktfähige“ Bausteine. Polycrate-Blöcke definieren eine klare Schnittstelle, Actions und Versionen – inklusive Distribution über eine OCI-Registry.

3. Governance & Compliance:
   Git allein erzwingt keine Trennung zwischen freigegebenen und experimentellen Bausteinen. Über die Registry, Tags und CHANGELOG.poly können Sie sehr klar kommunizieren, was für Produktion geeignet ist – und was nicht.

Wie verhindern wir, dass nicht freigegebene Block-Versionen in Produktion landen?

Typischerweise kombinieren Unternehmen:

• Registry-Governance: Nur bestimmte Tags werden für Produktions-Namensräume freigegeben.
• Code-Review auf Workspace-Ebene: Jede Änderung der from:-Version in workspace.poly wird von Platform- oder Security-Teams geprüft.
• CI-Checks: Pipelines validieren, dass nur zulässige Tags verwendet werden, bevor Deployments durchgeführt werden.

Polycrate fügt sich hier gut in bestehende Prozesse ein – Versionen sind klar sichtbar, und Actions sind nachvollziehbar. In Kombination mit Platform Engineering entsteht eine robuste Governance-Schicht über Ihrer Automatisierung.

Wie fügt sich Polycrate in unsere bestehende Platform-Strategie ein?

Polycrate adressiert die Ebene „Automatisierungs-Bausteine“ in Ihrer Plattform:

• Das Platform-Team definiert, welche Blöcke es als interne Produkte anbietet (z. B. VPN, AD, Kubernetes-Namespaces, Monitoring).
• Fachbereiche und Anwendungs-Teams konsumieren diese Blöcke in ihren Workspaces.
• Über die Registry und Semantic Versioning entsteht ein kontrolliertes Ökosystem, das sich gut mit bestehenden CI/CD-Landschaften, GitOps-Ansätzen und zentralen Governance-Prozessen verzahnen lässt.

Wenn Sie bereits eine Platform-Initiative starten oder erweitern möchten, unterstützen wir Sie mit unsere Beratung dabei, Polycrate sinnvoll zu integrieren.

Weitere Fragen? Siehe unsere FAQ

Von der Theorie zur Umsetzung

Mit einem Block- und Registry-zentrierten Ansatz wird Ansible-Automatisierung von einem schwer greifbaren Sammelsurium aus Playbooks zu einem klar strukturierten Produktportfolio: Jedes Team weiß, welche Blöcke existieren, welche Versionen stabil sind und wie sie zu verwenden sind. Das reduziert Reibung, erhöht Wiederverwendung und macht Compliance-Anforderungen erfüllbar, statt sie als Bremsklotz zu erleben.

ayedo begleitet Unternehmen genau auf diesem Weg:

• Wir helfen Platform- und Architektur-Teams, eine tragfähige Block-Strategie zu entwickeln – vom ersten VPN- oder AD-Block bis hin zu einem kompletten Ökosystem.
• Gemeinsam definieren wir, wie Ihre interne Registry (registry.acme-corp.com oder Harbor) als Backbone für Automatisierung und Platform Engineering genutzt wird.
• Wir unterstützen beim Aufbau von Governance-Prozessen, in denen Semantic Versioning, CHANGELOG.poly, Workspace-Verschlüsselung und Registry-Publishing zusammenspielen.
• In praxisnahen Formaten arbeiten wir mit Ihren Networking-, Windows-, Linux- und Applikations-Teams daran, aus heutigen Playbooks wiederverwendbare Enterprise-Blöcke zu machen.

Wenn Sie einheitliche Automatisierung, klar definierte Bausteine und belastbare Compliance nicht länger dem Zufall überlassen möchten, ist jetzt ein guter Zeitpunkt, Ihre Plattform-Strategie zu schärfen.

Übersicht und Anmeldung: Workshops