Kubernetes-Apps aus dem PolyHub: Von der Idee zum Deployment in Minuten

TL;DR

• PolyHub funktioniert wie ein App-Store für Infrastruktur: Fertige ayedo-Blöcke für Kubernetes-Apps (nginx, cert-manager, external-dns und viele mehr) lassen sich direkt aus der Registry cargo.ayedo.cloud in deinen Workspace ziehen und ohne lokales Ansible-Setup nutzen.
• In diesem Beitrag baust du einen vollständigen Ingress-Stack (nginx + cert-manager + external-dns) allein durch Konfiguration deiner workspace.poly und das Ausführen weniger polycrate-Befehle – inklusive sauberem Kubeconfig-Handling und versionierten Blöcken.
• Du lernst, wie ein offizieller ayedo-Kubernetes-Block aufgebaut ist (block.poly + Ansible-Playbook), warum Version-Pinning (:0.2.2 statt :latest) in Produktion Pflicht ist und wie du das umfangreiche Ökosystem auf PolyHub für deine eigenen Workspaces nutzt.
• Polycrate löst das klassische Ansible-Dependency-Problem, indem alle Playbooks in einem vordefinierten Container mit vollständiger Toolchain (kubectl, Helm, Python, Collections) laufen – identisch auf jeder Workstation, ohne Python-Chaos und ohne manuelles Setup.
• ayedo liefert mit Polycrate und den offiziellen Blöcken auf PolyHub eine getestete, wiederverwendbare Grundlage für Kubernetes-Lösungen, die du direkt übernehmen und an deine Umgebung anpassen kannst.

PolyHub als App-Store für Kubernetes-Infrastruktur

Wenn du schon einmal einen Ingress-Stack mit plain Ansible oder Helm von Hand aufgebaut hast, kennst du das Muster:

• Werte und CRDs für ingress-nginx zusammensuchen
• cert-manager mit den richtigen Issuern konfigurieren
• external-dns an deinen DNS-Provider anbinden
• Alles sauber versionieren und dokumentieren

Mit Polycrate und PolyHub drehst du das Prinzip um: Statt alles selbst zu modellieren, startest du mit fertigen, getesteten Bausteinen.

PolyHub unter https://hub.polycrate.io ist eine Registry von Polycrate-Blöcken, die als OCI-Images in cargo.ayedo.cloud liegen – ähnlich wie Container-Images auf Docker Hub, aber speziell für Automatisierung. Für Kubernetes findest du dort u. a.:

• cargo.ayedo.cloud/ayedo/k8s/nginx:* – Ingress-Controller
• cargo.ayedo.cloud/ayedo/k8s/cert-manager:* – TLS-Automatisierung
• cargo.ayedo.cloud/ayedo/k8s/external-dns:* – DNS-Automatisierung

Die Kernideen dahinter:

• Sharable Automation: Was einmal als Block gebaut ist, kann in beliebigen Workspaces wiederverwendet und über eine OCI-Registry geteilt werden.
• Guardrails statt Wildwuchs: Statt lose verstreuter Playbooks kapselst du Logik in klar definierte Blöcke mit Konfigurationsoberfläche.
• Containerisierte Ausführung: Alle Ansible-Playbooks laufen in einem Polycrate-Container – keine lokale Ansible-Installation, keine Python-Versionkonflikte, keine manuell installierten Collections.

In diesem Beitrag nutzen wir genau diese Bausteine und bauen dir einen produktionsnahen Ingress-Stack für einen Beispiel-Cluster.

Workspace vorbereiten: Kubeconfig und Blocks deklarieren

Wir starten mit einem Workspace acme-corp-automation. Er ist die logische Einheit für deine Automatisierung – egal ob du Linux-Server, Windows-Hosts oder Kubernetes-Cluster verwaltest.

Eine minimale workspace.poly könnte so beginnen:

name: acme-corp-automation
organization: acme

config: {}
blocks: []
workflows: []

Das Feld config auf Workspace-Ebene ist für Workspace-/Toolchain-Einstellungen gedacht (z. B. Container-Image unter config.image) – nicht als freie Sammelstelle für beliebige Automatisierungsvariablen; die gehören in Block-config oder secrets.poly. Siehe Konfiguration. Das leere config: {} steht hier nur als Platzhalter, bis du z. B. ein Image setzt.

Wichtig für Kubernetes: Die Kubeconfig deines Clusters liegt in Polycrate immer als Secret-Datei im Workspace:

artifacts/secrets/kubeconfig.yml

Diese Datei wird von Polycrate als Secret behandelt und kann mit der eingebauten Workspace-Verschlüsselung geschützt werden, siehe Workspace-Verschlüsselung.

Zum Aktivieren der Verschlüsselung genügt auf der CLI:

polycrate workspace encrypt

Du brauchst keinen externen Vault – Polycrate nutzt intern age und integriert das in deine Workflow-Ausführung, was Compliance-Anforderungen oft deutlich vereinfacht.

Einen Kubernetes-Block aus PolyHub pullen

Die offiziellen ayedo-Blöcke für Kubernetes-Apps liegen als OCI-Images auf cargo.ayedo.cloud. Du kannst dir jeden Block in deinen Workspace ziehen:

polycrate blocks pull cargo.ayedo.cloud/ayedo/k8s/nginx:0.2.2

Damit passiert Folgendes:

• Polycrate lädt den Block nginx in Version 0.2.2 aus der Registry.
• Der Block landet im Workspace-Cache; du kannst ihn von dort referenzieren.
• Es ist kein lokales Ansible, kein kubectl und kein Helm notwendig – das alles kommt aus dem Polycrate-Container.

Wichtig: Die Versionsangabe :0.2.2 ist kein Detail – sie ist ein Best Practice. In Produktion solltest du niemals :latest verwenden, siehe auch die Best Practices in der Dokumentation.

Jetzt binden wir den Block in unseren Workspace ein.

Block in workspace.poly einbinden und konfigurieren

In workspace.poly deklarierst du, welche Block-Instanzen du verwenden willst. Für unseren Ingress-Stack fügen wir drei Blöcke hinzu:

name: acme-corp-automation
organization: acme

blocks:
  - name: k8s-nginx
    from: cargo.ayedo.cloud/ayedo/k8s/nginx:0.2.2
    config:
      namespace: "ingress-nginx"
      ingress_class: "nginx"

  - name: k8s-cert-manager
    from: cargo.ayedo.cloud/ayedo/k8s/cert-manager:0.3.0
    config:
      namespace: "cert-manager"
      email: "admin@acme-corp.com"

  - name: k8s-external-dns
    from: cargo.ayedo.cloud/ayedo/k8s/external-dns:0.4.1
    config:
      namespace: "external-dns"
      provider: "route53"
      domain_filter: "acme-corp.com"

workflows: []

Ein paar wichtige Punkte:

• from: referenziert immer den vollständigen Block-Namen inklusive Version (:0.2.2).
• name: ist der Instanzname im Workspace – so sprichst du den Block später an (polycrate run k8s-nginx deploy).
• config: enthält Block-spezifische Werte. Diese landen später als block.config.* in deinem Ansible-Playbook.

Das Schöne: Du musst die interne Logik dieser Blöcke nicht kennen, um sie zu nutzen. Sie sind wie fachlich sinnvolle Bausteine in einem Baukasten – sauber gekapselt und versioniert.

Wie ein ayedo-Kubernetes-Block aufgebaut ist

Schauen wir uns trotzdem einmal an, wie so ein ayedo-Block innen aussieht. Stell dir vor, du würdest cargo.ayedo.cloud/ayedo/k8s/nginx:0.2.2 lokal entwickeln. Im Block-Verzeichnis läge eine block.poly:

name: k8s-nginx
version: 0.2.2
kind: generic

config:
  namespace: "ingress-nginx"
  ingress_class: "nginx"

actions:
  - name: deploy
    playbook: deploy.yml

  - name: delete
    playbook: delete.yml

Wichtige Details:

• Kubeconfig: Du brauchst kein kubeconfig_path in der block.poly. Polycrate übernimmt die Kubeconfig aus artifacts/secrets/kubeconfig.yml, setzt im Action-Container KUBECONFIG auf den korrekten Pfad – kubectl, Helm und Ansible-Module (z. B. community.kubernetes.helm) nutzen sie damit ohne zusätzliche Block-Konfiguration. In .poly-Dateien gibt es außerdem kein Jinja wie {{ workspace.secrets[...] }}.
• actions definieren, welche Befehle du über polycrate run ausführen kannst (deploy, delete, …).
• Die Version 0.2.2 ist fest in der block.poly kodiert und wird auch in der Registry verwendet.

Dazu gehört ein Ansible-Playbook, z. B. deploy.yml:

- name: Deploy ingress-nginx via Helm
  hosts: localhost
  gather_facts: false

  tasks:
    - name: Install ingress-nginx Helm chart
      community.kubernetes.helm:
        name: ingress-nginx
        chart_ref: ingress-nginx/ingress-nginx
        release_namespace: "{{ block.config.namespace }}"
        create_namespace: true
        values:
          controller:
            ingressClassResource:
              name: "{{ block.config.ingress_class }}"

Dazu ein paar Erklärungen:

• hosts: localhost ist hier korrekt, weil das Playbook nur gegen die Kubernetes-API spricht. Es verändert keine lokalen Pakete – es läuft im Polycrate-Container und steuert von dort den Cluster.
• Das Modul community.kubernetes.helm kommt aus einer Ansible Collection, die im Polycrate-Container bereits installiert ist. Du musst dich um diese Dependency nicht kümmern. KUBECONFIG ist im Container bereits gesetzt – ein explizites kubeconfig: im Task ist nicht nötig.
• block.config.* sind die Werte aus deiner workspace.poly-Konfiguration für diese Block-Instanz (hier u. a. namespace, ingress_class). Du steuerst den Deploy also komplett aus dem Workspace.

Mit plain Ansible müsstest du für so ein Setup:

• Ein Python-Umfeld mit passenden Versionen aufsetzen
• kubectl, helm, Ansible plus Collections installieren
• Kubeconfig-Zugriff selbst verdrahten (Polycrate erledigt das über KUBECONFIG)
• Deine Playbooks und Rollen in einem freien Verzeichnisbaum organisieren

Mit Polycrate bekommst du eine klar strukturierte Block-Definition, eine standardisierte Ausführungsumgebung im Container und eine konsistente Art, Konfiguration aus dem Workspace in die Playbooks zu reichen. Siehe dazu auch die Ansible-Integration in der Dokumentation.

Den kompletten Ingress-Stack als Workflow ausführen

Ein großer Vorteil der Block-Struktur ist, dass du aus mehreren Blöcken einen reproduzierbaren Workflow bauen kannst. In unserem Beispiel:

• k8s-nginx – Ingress-Controller
• k8s-cert-manager – TLS-Zertifikate
• k8s-external-dns – DNS-Einträge für deine Ingresses

Diesen Stack definieren wir als Workflow in workspace.poly:

name: acme-corp-automation
organization: acme

blocks:
  - name: k8s-nginx
    from: cargo.ayedo.cloud/ayedo/k8s/nginx:0.2.2
    config:
      namespace: "ingress-nginx"
      ingress_class: "nginx"

  - name: k8s-cert-manager
    from: cargo.ayedo.cloud/ayedo/k8s/cert-manager:0.3.0
    config:
      namespace: "cert-manager"
      email: "admin@acme-corp.com"

  - name: k8s-external-dns
    from: cargo.ayedo.cloud/ayedo/k8s/external-dns:0.4.1
    config:
      namespace: "external-dns"
      provider: "route53"
      domain_filter: "acme-corp.com"

workflows:
  - name: k8s-ingress-stack
    actions:
      - block: k8s-nginx
        action: deploy
      - block: k8s-cert-manager
        action: deploy
      - block: k8s-external-dns
        action: deploy

Damit kannst du den kompletten Stack ausrollen mit:

polycrate workflows run k8s-ingress-stack

Was hier passiert:

• Polycrate startet für jede Action einen Container, in dem Ansible mit der jeweiligen Block-Konfiguration ausgeführt wird.
• Deine Kubeconfig wird aus artifacts/secrets/kubeconfig.yml in den Container gepiped, ohne dass sie unverschlüsselt im Repository liegen muss.
• Jeder Block nutzt seine eigene, getestete Logik, aber alle folgen denselben UX-Guidelines (einheitliche Actions wie deploy, delete, upgrade).

Mit plain Ansible würdest du an dieser Stelle typischerweise:

• Eine Ordnerstruktur wie playbooks/k8s/nginx.yml, playbooks/k8s/cert-manager.yml, playbooks/k8s/external-dns.yml anlegen
• Dir selbst merken (oder dokumentieren), in welcher Reihenfolge du diese Playbooks aufrufen musst
• Auf jedem Entwickler-Laptop eine funktionierende Ansible-Umgebung voraussetzen

Mit Polycrate werden diese Playbooks in wiederverwendbare Bausteine verpackt und über Workflows orchestriert. Das verhindert den Playbook-Wildwuchs, den viele Teams aus gewachsenen Umgebungen kennen, und ist im Detail in den Best Practices beschrieben.

Versions-Pinning: Warum :latest in Produktion tabu ist

Ein zentrales Prinzip in produktiven Kubernetes-Lösungen ist Reproduzierbarkeit. Genau deshalb ist :latest beim Container-Image keine gute Idee – und bei Polycrate-Blöcken ebenso wenig.

Die Registry-URL eines Blocks enthält immer die Version:

cargo.ayedo.cloud/ayedo/k8s/nginx:0.2.2

Best Practices dazu:

• Immer explizit pinnen: Nutze grundsätzlich eine konkrete Version (:0.2.2) in workspace.poly.
• Upgrade bewusst planen: Wenn du ein Update testen willst, leg einen separaten Workspace oder Branch mit neuer Version an (z. B. :0.2.3) und teste den Workflow dort.
• Releases dokumentieren: Die Kombination aus Workspace-Commit und Block-Versionen ergibt einen klar definierten Stand deiner Infrastruktur-Automatisierung.

So kannst du sicherstellen, dass ein Rollout heute, morgen und in drei Monaten das gleiche Verhalten zeigt – unabhängig davon, ob es inzwischen neue Block-Versionen auf PolyHub gibt.

Das Ökosystem-Argument: Nicht jedes Rad neu erfinden

Der eigentliche Mehrwert von PolyHub liegt im Ökosystem:

• Dutzende getestete Blöcke für Kubernetes (Ingress, Monitoring, Logging, Storage, Security, …)
• Weitere Blöcke für Linux-Server, Windows-Hosts, Cloud-APIs und mehr
• Einheitliche UX: Jeder Block bringt klare Actions mit (deploy, configure, backup, …)

Für dich als Platform Engineer oder Kubernetes-Verantwortlicher bedeutet das:

• Du kannst mit einem kompletten Ingress-Stack starten, ohne selbst Helm-Charts und Ansible-Playbooks zu designen.
• Du kannst dich auf deine Policies, Namenskonventionen und Integrationen konzentrieren – nicht auf das Verdrahten einzelner YAML-Fragmente.
• Du profitierst von der Arbeit anderer Teams, ohne Code zu kopieren. Polycrate-Blöcke werden über eine Registry geteilt, sauber versioniert und können auch in privaten Registern gehostet werden, siehe Registry-Dokumentation und PolyHub.

Wenn du später individuelle Anforderungen hast, kannst du jederzeit eigene Blöcke bauen, die auf den offiziellen ayedo-Blöcken aufsetzen oder sie um zusätzliche Actions erweitern. Die Block-Dokumentation zeigt dir die Details.

Häufige Fragen

Wie unterscheidet sich ein Polycrate-Block von einem Helm-Chart?

Ein Helm-Chart beschreibt in erster Linie Kubernetes-Ressourcen. Ein Polycrate-Block dagegen:

• Kapselt Automatisierung (Ansible-Playbooks), nicht nur Manifeste.
• Kann Helm nutzen, aber auch andere Module (z. B. kubernetes.core.k8s, ansible.builtin.uri, Cloud-Collections).
• Bringt eine definierte Konfiguration (block.config.*), Actions und eine standardisierte Ausführungsumgebung im Container mit.

Du kannst also komplexere Workflows abbilden: Cluster-Setup, Zertifikatsrotation, DNS-Management, API-Calls gegen externe Systeme – alles in einem konsistenten Modell. Für viele Teams ist das der nächste Schritt nach „nur Helm“.

Muss ich lokal Ansible, Helm oder kubectl installieren, um PolyHub-Blöcke zu nutzen?

Nein. Genau das ist einer der Kernvorteile:

• Polycrate startet für jede Action einen Container mit einer vordefinierten Toolchain (Ansible, Collections, kubectl, Helm, Python, …).
• Deine Workspace-Dateien (inklusive verschlüsselter Secrets) werden in diesen Container gemountet.
• Du brauchst lokal nur Polycrate selbst und Zugang zur Registry.

Das löst das klassische Dependency-Problem: Kein Python-2-vs-3-Chaos, keine verschiedenen Ansible-Versionen je Entwickler-Laptop, weniger Supply-Chain-Risiken durch wild installierte Tools.

Mehr Details findest du in der CLI-Referenz.

Wie passt das in unser Compliance-Setup (z. B. DSGVO, Audit-Trails)?

Polycrate hilft an mehreren Stellen:

• Workspace-Verschlüsselung: Sensible Dateien wie Kubeconfigs oder API-Tokens liegen im Workspace verschlüsselt (via polycrate workspace encrypt), siehe Workspace-Verschlüsselung.
• Nachvollziehbare Versionen: Die Kombination aus Git-Commit und Block-Versionen in workspace.poly ergibt einen klaren Audit-Trail: Du kannst jederzeit rekonstruieren, welche Automatisierung wann ausgeführt wurde.
• Guardrails durch Blöcke: Statt „jeder schreibt Playbooks, wie er möchte“ definierst du standardisierte Blöcke mit klaren Parametern – das reduziert Fehlkonfigurationen und erleichtert Reviews.

Weitere Fragen? Siehe unsere FAQ

Von der Theorie zur Umsetzung

In diesem Beitrag hast du gesehen, wie du mit PolyHub und Polycrate in kurzer Zeit einen kompletten Kubernetes-Ingress-Stack aus fertigen Bausteinen aufbauen kannst:

• Du hast gelernt, wie du ayedo-Blöcke für Kubernetes-Apps aus der Registry cargo.ayedo.cloud pullst und in deiner workspace.poly deklarierst.
• Du kennst die Anatomie eines Blocks mit block.poly, config-Parametern und Ansible-Playbooks, die im Polycrate-Container gegen dein Cluster laufen.
• Du weißt, warum konsequentes Versions-Pinning (statt :latest) und das Nutzen des Ökosystems auf PolyHub entscheidend für reproduzierbare Kubernetes-Lösungen sind.

Für ayedo ist genau diese Kombination aus wiederverwendbaren Blöcken, containerisierter Ausführung und klaren Guardrails der Kern von moderner Platform Automation. Wir entwickeln und pflegen die offiziellen ayedo-Blöcke auf PolyHub, damit du dich auf deine fachlichen Anforderungen konzentrieren kannst – nicht auf das erneute Erfinden derselben Infrastruktur-Bausteine.

Ob du „nur“ einen Ingress-Controller bereitstellen, einen kompletten Cluster-Stack aufbauen oder Polycrate in ein größeres Platform- oder Compliance-Programm integrieren willst: Unsere Expertise und unsere Open-Source-Werkzeuge sind darauf ausgelegt, dich dabei technisch sauber zu unterstützen.

Wenn du den nächsten Schritt gehen willst, schnapp dir einen Workspace, richte deine kubeconfig.yml als Secret ein und starte mit den Kubernetes-Blöcken auf PolyHub. Den Rest übernimmt Polycrate – reproduzierbar, versioniert und teamtauglich.

PolyHub erkunden