Warum Polycrate?¶

Einfache Actions statt Tool-Chaos¶

Komplexe Playbooks und Deployments stecken in Blocks. Nutzer führen nur Actions aus — ohne Ansible/Helm-Details kennen zu müssen:

# block.poly
name: nginx
actions:
  - name: install
    playbook: install.yml
  - name: uninstall
    playbook: uninstall.yml
  - name: status
    playbook: status.yml

polycrate run nginx install
polycrate run nginx status

Toolchain im Container¶

Ansible, kubectl, Helm, Python u. a. liegen im Polycrate-Image. Kein Versions-Patchwork auf dem Laptop nötig, um mit Blocks zu starten.

Eine `workspace.poly`¶

Der Workspace beschreibt Blöcke und Config zentral in YAML. Keine eigene DSL.

# workspace.poly
name: my-workspace
organization: acme

blocks:
  - name: cluster
    from: registry.acme.corp/infra/k8s:1.0.0

  - name: myapp
    from: registry.acme.corp/apps/myapp:1.0.0
    config:
      replicas: 2

Kubeconfig und Inventory liegen typischerweise einmal pro Workspace (artifacts/secrets/kubeconfig.yml, inventory.yml) — nicht über Block-zu-Block-from:-Ketten. → Empfehlungen

Teamfähig¶

Gleiche Actions für Ops und weniger technische Kollegen (install, restart, Log-Actions). Implementierung bleibt im Playbook.

Bestehender Code bleibt nutzbar¶

Polycrate führt aus — bestehende Ansible-/Python-/Script-Logik wird zum Block, ohne Rewrite.

Ansible-Integration¶

Inventory, SSH-Keys und Kubeconfig werden für Runs konsistent eingehängt. Details: Ansible, SSH.

OCI-Registry für Blocks¶

Blocks sind OCI-Images. Push/Pull gegen Harbor, Docker Hub oder jede kompatible Registry — immer mit vollem Pfad:

polycrate blocks pull registry.acme.corp/blocks/k8s/cluster:0.0.1
polycrate blocks push registry.acme.corp/infra/my-block

→ Registry

Git¶

Ein Workspace enthält Config, Blocks und Secrets-Artefakte und lässt sich wie jedes Repo versionieren. → Git