Polycrate: Deployment-Automation für Kubernetes und Cloud-Migration

TL;DR

• Polycrate ist ein Ansible-basiertes Framework für Deployment-Automation, das alle notwendigen Tools containerisiert und so reproduzierbare Deployments über unterschiedliche Umgebungen hinweg ermöglicht – von Bare Metal bis Kubernetes.
• Kernkonzepte wie Blocks, Workspace und Actions erlauben es, komplexe Cloud-Migrationen und Day‑2‑Operations modular, versionierbar und auditierbar abzubilden.
• Für Cloud-Migrationen stellt der PolyHub kostenlose Blocks bereit, um Managed Services von Hyperscalern wie AWS RDS, ElastiCache oder S3 auf Kubernetes-native Alternativen wie CloudNativePG, Redis oder MinIO zu migrieren – ein praktischer Hebel für Data-Act-konformes Cloud-Switching.
• Polycrate unterstützt die Umsetzung von Anforderungen aus Data Act, NIS‑2, DORA und dem Cyber Resilience Act, indem es reproduzierbare, dokumentierte und provider-unabhängige Deployments ermöglicht.
• ayedo nutzt Polycrate und den PolyHub, um Unternehmen bei Cloud-Migration, Kubernetes-Plattformaufbau und Compliance-orientierter Infrastrukturautomatisierung pragmatisch zu unterstützen.

---

Polycrate als Framework für Deployment-Automation

Polycrate adressiert ein alltägliches, aber strukturelles Problem in modernen Infrastrukturen: Die eigentliche Komplexität liegt selten im einzelnen Tool, sondern in der Integration und im Betrieb ganzer Toolchains – über mehrere Provider, Regionen und Umgebungen hinweg.

Statt jede Umgebung mit einem neuen Set an Shell-Skripten, Playbooks und Ad-hoc-Workarounds aufzubauen, bietet Polycrate einen einheitlichen Rahmen, um:

• Tools und Abhängigkeiten zu kapseln,
• Installationslogik zu standardisieren,
• wiederverwendbare Workflows für Deployment und Wartung bereitzustellen.

Technisch besteht Polycrate aus einer CLI, die alle Aktionen in einem Docker-Container ausführt. Dieser Container bringt eine vollständige Cloud-native Toolchain mit – darunter Ansible, kubectl, Helm, Terraform und weitere Werkzeuge für Migration, Backup und Automatisierung. Das minimiert lokale Abhängigkeiten und sorgt für reproduzierbare Ergebnisse: Wer einen Workspace auscheckt und Polycrate ausführt, erhält dasselbe Verhalten – unabhängig von der lokalen Maschine.

Blocks, Workspace, Actions: Drei Bausteine für Ordnung

Polycrate strukturiert Infrastruktur in drei Kernkonzepte, die zusammen eine klare Abstraktionsebene schaffen.

Blocks: Modularisierte Infrastruktur-Bausteine

Ein Block kapselt ein konkretes System oder eine Funktion, beispielsweise:

• einen Kubernetes-Cluster (etwa k3s auf Bare Metal),
• eine Datenbank (CloudNativePG),
• einen Redis-Cluster,
• ein MinIO-Deployment,
• Observability-Stacks oder Security-Komponenten.

In einem Block steckt alles, was für dieses System nötig ist: benötigte Tools, Ansible-Playbooks, Standardkonfigurationen, Dokumentation. Blocks sind versionierbar und damit als wiederverwendbare, portable Bausteine nutzbar – sowohl innerhalb eines Unternehmens als auch über den PolyHub.

Workspace: Gemeinsamer Kontext für komplexe Szenarien

Ein Workspace bündelt mehrere Blocks in einem konsistenten Kontext. Typische Beispiele:

• Ein „Landing Zone“-Workspace für die initiale Bereitstellung einer souveränen Kubernetes-Plattform.
• Ein Migrations-Workspace für die Ablösung von AWS RDS, ElastiCache und S3 durch CloudNativePG, Redis und MinIO.
• Ein Betriebs-Workspace für Day‑2‑Operations (Backups, Upgrades, Compliance-Checks).

Der Workspace definiert, wie Blocks zusammenspielen, welche Konfigurationen geteilt werden (z. B. Kubeconfigs, Secrets, Netzwerkeinstellungen) und welche Workflows auf Organisationsebene relevant sind.

Actions: Bedienbare Workflows statt Skript-Sammlung

Actions sind benutzerfreundliche Kommandos, die aus Blocks heraus bereitgestellt werden, etwa:

• install für die Erstinstallation einer Komponente,
• upgrade für kontrollierte Updates,
• backup und restore für Datensicherung,
• migrate für Cloud-Migrationen.

Statt sich durch diverse Skripte und Playbooks zu arbeiten, erhalten Verantwortliche eine klar strukturierte Oberfläche: „Welche Aktionen kann ich auf diesem System sinnvoll ausführen?“ Das reduziert die Abhängigkeit von Einzelpersonen und verbessert Auditierbarkeit und Dokumentation.

---

Polycrate als Enabler für Cloud-Migration

Cloud-Migration bedeutet heute meist: Heraus aus proprietären Services der Hyperscaler, hinein in standardisierte, Kubernetes-native Architekturen. Genau hier setzt Polycrate an.

PolyHub: Kostenlose Bausteine für Hyperscaler-Alternativen

Der PolyHub bietet kuratierte, kostenlose Blocks für typische Infrastrukturkomponenten. Statt jeden Migrationspfad neu zu erfinden, können Sie erprobte Patterns wiederverwenden.

Beispiele für gängige Migrationen:

• AWS RDS → CloudNativePG
  Polycrate-Blocks stellen CloudNativePG als Kubernetes-Operator bereit, inklusive Konfiguration für Hochverfügbarkeit, Backups und Monitoring. Aus einem Block wird so eine „RDS-ähnliche“ Datenbank-Plattform in Ihrem Cluster.

• AWS ElastiCache → Redis auf Kubernetes
  Ein Redis-Block übernimmt die Installation eines hochverfügbaren Redis-Clusters, inklusive Sentinel/Fencing-Mechanismen und optionaler Persistenz. Für Applikationen bleibt Redis Redis – nur der Betriebsmodus wird souverän.

• AWS S3 → MinIO
  Ein MinIO-Block stellt S3-kompatiblen Objektspeicher in Ihrem eigenen Cluster oder auf Bare Metal bereit. Applikationen, die heute S3 sprechen, können in der Regel ohne Code-Anpassung auf MinIO umgestellt werden.

Durch diese vorgefertigten Blocks erhalten Sie eine konkrete Migrationserzählung: von Managed Services des Hyperscalers hin zu Kubernetes-nativen Diensten, die Sie selbst – oder gemeinsam mit einem Partner – betreiben.

Data-Act-konformes Cloud-Switching mit Polycrate

Der Data Act schreibt ab dem 12. September 2025 verbindliche Regeln für Cloud-Switching und Interoperabilität fest. Unternehmen erhalten ein Recht auf Portabilität, aber sie müssen es auch technisch einlösen können.

Polycrate adressiert drei zentrale Anforderungen:

1. Offene, maschinenlesbare Formate
   Workspaces, Blocks und Konfigurationen liegen in offenen, textbasierten Formaten vor. Sie sind versionierbar, auditierbar und an andere Provider oder Dienstleister übergebbar.

2. Funktionale Äquivalenz durch Standardkomponenten
   Statt proprietären Datenbank- oder Cache-Diensten setzen Sie CloudNativePG, Redis oder MinIO ein – Technologien, die sich auf jeder Infrastruktur betreiben lassen, die Kubernetes unterstützt.

3. Dokumentierte Switching-Prozesse
   Durch klar definierte Actions (z. B. migrate-rds-to-cloudnativepg) werden Wechselprozesse explizit dokumentiert. Diese Actions können wiederum Bestandteil Ihrer internen Richtlinien und Compliance-Dokumentation werden.

So wird Polycrate zum operativen Gegenstück der rechtlichen Portabilitätsansprüche aus dem Data Act.

---

Polycrate für Kubernetes: Vom k3s-Cluster zu Day‑2‑Operations

Kubernetes ist heute der de-facto Standard für eine cloud-agnostische Plattform. Polycrate nutzt Kubernetes konsequent als Zielumgebung – unabhängig davon, ob der Cluster auf einem Hyperscaler, bei einem europäischen Provider oder im eigenen Rechenzentrum läuft.

k3s-Installation und Cluster-Bootstrap

Viele Organisationen starten mit k3s, um einen schlanken, produktionsfähigen Kubernetes-Cluster auf Bare Metal oder VMs zu betreiben. Polycrate-Blocks für k3s können:

• Hosts vorbereiten (Netzwerk, Kernel-Parameter, Container-Laufzeit),
• einen initialen Control-Plane-Knoten und Worker-Knoten provisionieren,
• Kubeconfigs und Zertifikate sicher im Workspace verwalten,
• Basiskomponenten wie CNI, Ingress, Storage-Class installieren.

Die k3s-Infrastruktur wird damit zu einem Teil derselben Automatisierungslogik wie Ihre Applikationen. Änderungen am Cluster sind nachvollziehbar und wiederholbar – ein entscheidender Punkt für Auditierbarkeit und Disaster Recovery.

Managed Apps und Day‑2‑Operations

Sobald der Cluster steht, beginnt der eigentliche Betrieb: Upgrades, Skalierung, Backups, Monitoring, Security. Polycrate-Blocks übernehmen diese Aufgaben für eine wachsende Zahl von „Managed Apps“, etwa:

• Datenbanken (CloudNativePG, MySQL),
• Caches (Redis),
• Objektspeicher (MinIO),
• Observability-Stacks (z. B. Prometheus-/VictoriaMetrics-basierte Lösungen),
• Ingress- und API-Gateways,
• Registries wie Harbor für Container-Images.

Day‑2‑Operations werden in Actions gegossen, die etwa folgende Aufgaben bündeln:

• Rolling Updates mit vorherigen Checks und Rollback-Strategien,
• regelmäßige Backups und Test-Restores,
• Rotation von Zertifikaten und Secrets,
• Skalierungsanpassungen basierend auf Messdaten,
• Security-Hardening und Compliance-Checks.

Für Verantwortliche entsteht damit ein klarer, bedienbarer Satz an Wartungsroutinen, der den Wildwuchs individueller Admin-Skripte ersetzt.

---

Compliance, Souveränität und Reproduzierbarkeit

Regulierungen wie die NIS‑2-Richtlinie, die Digital Operational Resilience Act (DORA), der Data Act und der kommende Cyber Resilience Act verschieben den Fokus weg von reiner Funktionalität hin zu belastbarer, nachvollziehbarer Resilienz.

Reproduzierbare Deployments als Antwort auf NIS‑2 und DORA

Die NIS‑2-Richtlinie ist bis zum 17. Oktober 2024 in nationales Recht umzusetzen und verlangt unter anderem wirksame technische und organisatorische Maßnahmen zur Sicherstellung der Betriebsresilienz. DORA gilt ab dem 17. Januar 2025 direkt für Finanzunternehmen und ihre IT-Dienstleister und fokussiert insbesondere auf IKT-Risikomanagement und Betriebsstabilität.

Polycrate unterstützt diese Anforderungen operativ, indem:

• Deployments deterministisch ablaufen, weil alle Schritte im Workspace definiert und versioniert sind.
• Änderungen an Infrastruktur und Applikationen nachvollziehbar und rückverfolgbar werden (Wer hat wann welche Action mit welcher Version ausgeführt?).
• Disaster-Recovery-Szenarien testbar sind, da komplette Umgebungen aus dem Workspace neu aufgebaut werden können.

Was früher eine Sammlung von „Best Effort“-Skripten war, wird damit zu einem kontrollierten, wiederholbaren Prozess – eine Grundvoraussetzung für Audits und externe Prüfungen.

Cloud-Souveränität und Provider-Unabhängigkeit

Der europäische Diskurs zur „Cloud-Souveränität“ spiegelt sich in Initiativen und Leitplanken wie dem Cloud Sovereignty Framework wider. Im Kern geht es darum, technologische Handlungsfähigkeit zu behalten, selbst wenn einzelne Provider ausfallen, Preise anziehen oder regulatorische Rahmenbedingungen sich ändern.

Polycrate adressiert diese Zielsetzung durch:

• konsequenten Einsatz offener Standards (Ansible, Kubernetes, OCI-Images),
• portierbare Workspaces, die auf verschiedene Provider angewendet werden können,
• polyglotte Toolchains, die nicht an einen einzelnen Hyperscaler gebunden sind.

Damit wird es realistisch, Workloads von einem Hyperscaler zu einem europäischen Provider oder ins eigene Rechenzentrum zu verlagern, ohne die Automatisierung neu zu erfinden.

Cyber Resilience Act: Secure-by-Design über den Lebenszyklus

Der Cyber Resilience Act wurde 2024 verabschiedet; die meisten materiellen Pflichten werden voraussichtlich ab 2027 greifen. Er fordert unter anderem Security-by-Design und kontinuierliche Wartung über den gesamten Produktlebenszyklus.

Mit Polycrate können Sie:

• Sicherheitsrelevante Konfigurationen (z. B. Härtung von Clustern, Aktivierung von Verschlüsselung, Logging) als wiederholbare Actions abbilden.
• Patches und Sicherheitsupdates standardisiert ausrollen – nicht nur einmalig, sondern als etablierte Routine.
• Nachweisen, dass Wartungs- und Updatepflichten tatsächlich erfüllt wurden.

Compliance wird so zu einer Frage guter Automatisierung, nicht heroischer Einzelleistungen.

---

Praktisches Beispiel: Migration von AWS RDS zu CloudNativePG

Wie sieht eine konkrete Migration mit Polycrate aus? Nehmen wir den häufigen Fall: Eine Applikation nutzt AWS RDS (PostgreSQL), soll aber in eine Kubernetes-native, souveräne Plattform mit CloudNativePG überführt werden.

1. Analyse und Vorbereitung

Im ersten Schritt wird der Ist-Zustand systematisch erfasst:

• Welche RDS-Instanzen existieren (Region, Größe, Engine-Version)?
• Welche Applikationen greifen zu, mit welchen Latenz- und Verfügbarkeitsanforderungen?
• Wie sehen Backup- und Retention-Policies aktuell aus?

Ein spezieller Polycrate-Block für AWS-Inventarisierung kann diese Informationen strukturieren und als Artefakte im Workspace ablegen. So entsteht eine konsistente Datengrundlage für die Migrationsplanung.

2. Zielumgebung: Kubernetes-Cluster mit CloudNativePG

Im nächsten Schritt wird die Zielumgebung vorbereitet:

• Ein vorhandener oder neu aufzubauender Kubernetes-Cluster (etwa k3s) wird mittels Polycrate-Block installiert und konfiguriert.
• Ein CloudNativePG-Block wird hinzugefügt, der:
  • den Operator deployt,
  • Standard-Cluster-Konfigurationen bereitstellt,
  • Policies für Backups, PITR (Point-in-Time-Recovery) und Ressourcenlimits definiert.

Der Vorteil: Alle notwendigen Komponenten – vom Cluster bis zur Datenbank – sind in einem Workspace modelliert. Änderungen und Erweiterungen bleiben konsistent.

3. Datenmigration planen und durchführen

Die konkrete Datenmigration von RDS nach CloudNativePG erfordert in der Praxis mehrere Bausteine:

• Export und Import von Daten (z. B. per logical dump oder Streaming-Replikation).
• Übernahme von Benutzer- und Berechtigungsstrukturen.
• Synchronisation von Änderungen während einer Übergangsphase, falls ein Zero- oder Near-Zero-Downtime-Cutover erforderlich ist.

Polycrate-Blocks können diese Schritte als Actions bündeln, etwa:

• prepare-migration zur Erstellung der Ziel-Instanz und der Basisdaten.
• sync für inkrementelle Replikation bis kurz vor dem Cutover.
• cutover für das gezielte Umschalten der Applikationen auf den neuen Endpoint.

Wichtig ist dabei: Die Migrationslogik liegt nicht in einzelnen Skripten auf Admin-Rechnern, sondern im Workspace. Sie ist prüfbar, dokumentierbar und wiederholbar – eine wesentliche Voraussetzung für regulatorische Anforderungen, insbesondere in regulierten Branchen.

4. Applikationen umstellen und validieren

Nach dem Daten-Cutover werden die Applikationen umgestellt:

• Konfigurationen (z. B. Connection Strings) werden aktualisiert.
• Health-Checks und Smoke-Tests stellen sicher, dass Latenz, Durchsatz und Fehlerverhalten im erwarteten Rahmen liegen.
• Alte RDS-Instanzen werden erst nach definierter Beobachtungsphase deaktiviert, um einen sicheren Fallback zu gewährleisten.

Auch diese Schritte können in Actions gegossen werden, beispielsweise validate-migration oder decommission-rds. Das schafft Transparenz gegenüber internen Gremien, Audits und – wo nötig – Aufsichtsbehörden.

5. Betrieb und kontinuierliche Verbesserung

Nach erfolgreicher Migration beginnt der reguläre Betrieb unter Kubernetes:

• CloudNativePG-Cluster werden über Polycrate-Actions gewartet und aktualisiert.
• Backups, Monitoring und Security-Hardening laufen als wiederkehrende Workflows.
• Die Erfahrungen aus dieser ersten Migration lassen sich für weitere Systeme (z. B. ElastiCache zu Redis, S3 zu MinIO) wiederverwenden, da der Workspace als Blaupause dient.

So wird aus einer einmaligen Migration ein skalierbarer Migrations- und Betriebsansatz.

---

Häufige Fragen

Wie unterscheidet sich Polycrate von „klassischen“ Ansible-Playbooks?

Ansible bleibt der Kern der Automatisierung, aber Polycrate ergänzt eine Orchestrierungsebene darüber. Statt lose verteilter Playbooks, Inventories und Skripte erhalten Sie:

• klar definierte Blocks für einzelne Systeme,
• einen Workspace als gemeinsamen Kontext,
• Actions als benutzerfreundliche Workflows.

Das reduziert Wildwuchs, erhöht Wiederverwendbarkeit und erleichtert es, komplexe Szenarien wie Cloud-Migrationen oder Compliance-getriebene Veränderungen konsistent abzubilden.

Ist Polycrate nur für Kubernetes geeignet?

Nein. Polycrate eignet sich zwar besonders gut für Kubernetes-zentrierte Architekturen, lässt sich aber ebenso für klassische Linux-Hosts, Virtualisierungsumgebungen oder hybride Szenarien einsetzen. Durch den Ansible-basierten Ansatz können auch klassische Systeme (z. B. vorhandene Datenbankserver, Legacy-Applikationen) in dieselben Workflows eingebunden werden, die Ihre Kubernetes-Plattform aufbauen und betreiben. Das ist insbesondere für schrittweise Migrationen und Parallelbetrieb entscheidend.

Wie unterstützt ayedo bei NIS‑2-, DORA- und Data-Act-Anforderungen?

ayedo kombiniert technische Expertise in Cloud-native Technologien mit einem klaren Verständnis der europäischen Regulierungslandschaft. Konkret bedeutet das:

• Design von Polycrate-Workspaces, die Reproduzierbarkeit, Auditierbarkeit und Provider-Unabhängigkeit in den Mittelpunkt stellen.
• Bereitstellung und Pflege von PolyHub-Blocks für zentrale Infrastrukturkomponenten (z. B. CloudNativePG, Redis, MinIO, Observability-Stacks), abgestimmt auf Anforderungen aus NIS‑2, DORA und Data Act.
• Gemeinsame Entwicklung von standardisierten Migrations- und Betriebs-Workflows, die sich in Ihre internen Prozesse und Kontrollsysteme integrieren lassen.

Weitere Fragen? Siehe unsere FAQ

---

Von der Theorie zur Umsetzung

Polycrate liefert einen strukturierten, offenen Rahmen für Deployment-Automation, Cloud-Migration und Betrieb. Der PolyHub ergänzt diesen Rahmen um konkrete, produktionsreife Bausteine für typische Infrastrukturkomponenten – von Datenbanken über Caches und Objektspeicher bis zu Registries wie Harbor. Zusammen entsteht ein Werkzeugkasten, mit dem sich sowohl technische als auch regulatorische Anforderungen greifbar umsetzen lassen.

ayedo nutzt Polycrate in Kundenprojekten als zentrales Enabling-Werkzeug: Wir entwerfen Workspaces, die Ihre bestehende Infrastruktur abbilden, entwickeln Migrationspfade von Hyperscalern hin zu souveränen Kubernetes-Plattformen und bringen die notwendigen Blocks aus dem PolyHub ein – oder entwickeln neue, falls Ihre Anforderungen darüber hinausgehen. Dabei behalten wir die regulatorischen Leitplanken aus Data Act, NIS‑2, DORA und dem Cyber Resilience Act von Beginn an im Blick.

Wenn Sie Cloud-Migration nicht als einmaliges Risiko, sondern als strategische Investition in Resilienz, Souveränität und Compliance verstehen möchten, ist Polycrate in Kombination mit dem PolyHub ein starker Ausgangspunkt. Der nächste Schritt ist, Ihren konkreten Anwendungsfall in einen Workspace zu übersetzen und erste Migrations- oder Betriebs-Workflows als Actions greifbar zu machen – gern gemeinsam mit uns und dem Polycrate PolyHub.