Viele Server, eine Wahrheit: Multi-Server-Management mit Polycrate-Inventories

TL;DR

• Ein einzelner Server ist mit Ansible schnell im Griff – aber sobald 10, 50 oder 200 Hosts dazukommen, wird das Inventory zum kritischen Skalierungsfaktor. Polycrate erzwingt ein zentrales, YAML-basiertes Inventory pro Workspace und verhindert damit Wildwuchs.
• Workspaces können Sie wie Umgebungen denken: Sie bündeln logisch zusammengehörige Infrastruktur. Haben Sie z. B. 100 Webserver (10 Dev, 10 Test, 80 Prod), legen Sie idealerweise drei Workspaces an – etwa web-dev, web-test, web-prod – und listen im jeweiligen inventory.yml nur die Hosts dieser Umgebung. Gemeinsame Automatisierung teilen Sie über Blöcke (Block Sharing), nicht über ein einziges Riesen-Inventory.
• In Polycrate liegt inventory.yml im Workspace-Root und ist die einzige Wahrheit für alle Blöcke und Actions dieses Workspaces. Ein schlankes Ansible-Inventory (z. B. all.vars, übersichtliche Gruppen) strukturiert Hosts für Playbooks innerhalb dieser Umgebung – Polycrate selbst hat keine eigenen Parameter für Ansible-Tags oder zur Auswahl von Inventory-Gruppen; polycrate run … bezieht sich immer auf den gesamten Workspace.
• Komplexe Konditionalität über Ansible-Tags oder ein überladenes Inventory abzubilden, ist nicht Best Practice. Dasselbe sollten Sie über Workspace- und Block-Segmentierung sowie Konfiguration der Block-Instanzen abbilden (siehe Best Practices).
• Polycrate führt Ansible immer im Container aus und löst damit das typische Dependency-Chaos (Python-Versionen, Ansible-Version, Module). Einmal definierte Workspaces und Inventories sind im gesamten Team reproduzierbar nutzbar.
• In ayedos Multi-Server-Workshops zeigen wir Admin-Teams in Formaten wie Platform Architecture und Platform Operations, wie sie bestehende Ansible-Automatisierung in Polycrate überführen, Inventories konsolidieren und Flotten-Updates sicher und nachvollziehbar betreiben.

Vom Einzelserver zur Flotte: Das eigentliche Skalierungsproblem

Solange Sie nur einen oder zwei Linux-Server verwalten, fühlt sich Ansible oft noch wie ein besseres SSH an: ein Playbook, ein Host, fertig.

Die Probleme beginnen, wenn:

• Sie plötzlich 10 Webserver, 3 Datenbankserver, 2 Monitoring-Hosts und ein paar Utility-Server haben.
• Staging, Test und Produktion sich nur durch Hostnamen unterscheiden.
• Kollegen „mal schnell“ ein eigenes Inventory anlegen – und Sie nach ein paar Monaten nicht mehr wissen, welche Hosts wo gepflegt werden.

Mit plain Ansible ist es dann verlockend, für jedes Team oder jeden Anwendungsfall ein eigenes Inventory-File zu pflegen. Das funktioniert, aber:

• Hosts sind in mehreren Dateien doppelt gepflegt.
• Variablen widersprechen sich (z.B. ansible_user unterschiedlich gesetzt).
• Niemand weiß mehr, welches Inventory das „richtige“ ist.

Polycrate dreht das Konzept bewusst um: pro Workspace ein Inventory, ein gemeinsames Verständnis für alle Blöcke und Teams, die diesen Workspace nutzen.

Ein Workspace, ein Inventory: Polycrate-Konvention statt Wildwuchs

In Polycrate ist ein Workspace Ihr logischer Rahmen – oft eine Umgebung (Dev, Test, Prod) oder eine klar abgegrenzte Infrastruktur-Linie. Er bündelt workspace.poly, inventory.yml, Secrets und die referenzierten Blöcke zu einer konsistenten Einheit.

Workspaces statt „ein Inventory für alles“

Klassisches Ansible drängt dazu, eine große Codebasis (Rollen, Gruppen, Tags) zu pflegen und Umgebungen nur über Inventory-Gruppen oder Host-Patterns zu unterscheiden – damit bleibt der gemeinsame Rollen-Ordner wartbar und nichts wird dupliziert. Das ist nachvollziehbar, wenn Code der teure Teil ist.

Mit Polycrate ist geteilte Funktionalität Sache der Blöcke (Registry, polycrate blocks push / from:). Sie segmentieren logisch nach Workspace: z. B. drei Workspaces web-dev, web-test, web-prod mit jeweils nur den Hosts dieser Stufe im inventory.yml – statt eines Workspaces web, in dem Sie Dev/Test/Prod ausschließlich über Ansible-Gruppen und Konventionen auseinanderhalten. Letzteres spiegelt alte Ansible-Denkweise; ersteres nutzt Polycrate so, wie Workspaces gedacht sind: Umgebung und Verantwortlichkeit zuerst, Inventory danach schlank und ehrlich.

Kurz: Workspaces für grobe, betriebliche Segmentierung; Blöcke für wiederverwendbare Automatisierung; im inventory.yml nur schlanke Gruppen für lesbare Playbooks innerhalb eines Workspaces – keine Tag-getriebene „Steuerlogik“ als Ersatz für Umgebungsgrenzen.

Wichtige Punkte:

• Die Workspace-Konfiguration liegt in workspace.poly.
• Das Inventory für alle Ansible-Aktionen liegt zentral im Workspace-Root als inventory.yml.

Polycrate setzt beim Ausführen von Actions automatisch ANSIBLE_INVENTORY auf dieses eine inventory.yml. Mehr dazu in der offiziellen Ansible-Integration-Dokumentation.

Minimaler Workspace mit Block server-setup

Ein einfacher workspace.poly für die ACME Corporation:

name: acme-corp-automation
organization: acme

blocks:
  - name: server-setup
    from: registry.acme-corp.com/acme/infra/server-setup:1.0.0
    config:
      maintenance_window: "Sundays 02:00-04:00 UTC"

Im Block-Paket selbst trägt block.poly denselben logischen Namen; die veröffentlichte OCI-Referenz ist dieselbe wie in from: oben:

# registry.acme-corp.com/acme/infra/server-setup:1.0.0
name: server-setup
version: 1.0.0
kind: generic

Wichtig:

• name und optional organization definieren den Workspace.
• Unter blocks binden Sie Blöcke per voller OCI-Registry-Referenz ein (registry/pfad/block:version) – die Version steckt im Tag am Ende der from-Zeile, wie bei Container-Images; ein separates version-Feld unter der Block-Instanz gibt es nicht.
• Konfigurationen (config) werden mit der Block-Definition gemergt – Details zur Vererbung finden Sie in den Best Practices.

Der Block liegt in der fiktiven Firmen-Registry unter registry.acme-corp.com (kein Bezug zu ayedos Produkt-Registry). Ein vorheriges polycrate blocks pull ist nicht nötig: Fehlt der Block lokal, erkennt Polycrate das beim Aufruf von polycrate run … und fragt, ob der Block aus der Registry automatisch installiert werden soll. Danach liegt die entpackte Struktur unter blocks/registry.acme-corp.com/acme/infra/server-setup/ (der Pfad unter blocks/ spiegelt die Referenz). Die Action apply (nicht mit einer Action update verwechseln) führt das zugehörige Playbook aus – im Container, gegen das zentrale inventory.yml im Workspace-Root und mit der hier gesetzten maintenance_window.

Zentrales Inventory: Gruppen und all.vars sauber nutzen

Kernstück unseres Multi-Server-Setups ist inventory.yml im Workspace-Root. Es ist die einzige Wahrheit für:

• Hostlisten
• Gruppen
• SSH-Parameter
• Host- und Gruppenvariablen

Beispiel: 10 Webserver, 3 Datenbankserver, 2 Monitoring-Hosts

Nehmen wir eine klassische Flotte auf Ubuntu 22.04:

• Webserver: web01–web10
• Datenbanken: db01–db03
• Monitoring: mon01, mon02

Das Inventory könnte so aussehen: Alle Hosts stehen unter all.hosts (mit Defaults aus all.vars und Host-Overrides); unter children verweisen die Gruppen nur noch per Hostnamen auf diese Einträge – ohne Variablen in den Gruppen zu duplizieren. Damit nutzen Ansible und polycrate ssh dieselbe kanonische Hostliste (siehe vorheriger Beitrag: SSH-Sessions & Operations):

all:
  vars:
    ansible_user: "ubuntu"
    ansible_ssh_port: 22
    ansible_ssh_common_args: "-o StrictHostKeyChecking=no"
    ansible_python_interpreter: /usr/bin/python3

  hosts:
    web01.acme-corp.com: {}
    web02.acme-corp.com: {}
    web03.acme-corp.com: {}
    web04.acme-corp.com: {}
    web05.acme-corp.com: {}
    web06.acme-corp.com: {}
    web07.acme-corp.com: {}
    web08.acme-corp.com: {}
    web09.acme-corp.com: {}
    web10.acme-corp.com: {}
    db01.acme-corp.com: {}
    db02.acme-corp.com: {}
    db03.acme-corp.com:
      ansible_user: "dbadmin"     # Host-spezifische Overrides
      ansible_ssh_port: 2222
    mon01.acme-corp.com: {}
    mon02.acme-corp.com: {}
    bastion.acme-corp.com:
      ansible_user: "admin"
      ansible_ssh_port: 2201

  children:
    webservers:
      hosts:
        web01.acme-corp.com:
        web02.acme-corp.com:
        web03.acme-corp.com:
        web04.acme-corp.com:
        web05.acme-corp.com:
        web06.acme-corp.com:
        web07.acme-corp.com:
        web08.acme-corp.com:
        web09.acme-corp.com:
        web10.acme-corp.com:

    databases:
      hosts:
        db01.acme-corp.com:
        db02.acme-corp.com:
        db03.acme-corp.com:

    monitoring:
      hosts:
        mon01.acme-corp.com:
        mon02.acme-corp.com:

Zentrale Punkte für erfahrene Admins:

• Unter all.vars definieren Sie die gemeinsamen Defaults für alle Hosts – z.B. SSH-User, Port, Python-Interpreter.
• Jeder Host erscheint einmal unter all.hosts; host-spezifische Werte (z.B. db03, Bastion) setzen Sie dort, sie überschreiben all.vars wie gewohnt.
• Unter children.*.hosts stehen nur die Hostnamen zur Gruppenzuordnung – ohne erneute Variablenblöcke, damit polycrate ssh und Ansible dieselbe kanonische Hostliste nutzen.
• children sind Ihre funktionalen Gruppen (webservers, databases, monitoring), die Sie in Playbooks gezielt adressieren.

Polycrate kümmert sich um den Rest: Bei jeder Action wird dieses Inventory automatisch genutzt. Wie Sie SSH-Keys und Verbindungen sauber zentralisieren, ist in der SSH-Dokumentation von Polycrate beschrieben.

Gruppen in der Praxis: Ein Playbook, unterschiedliche Ziele

Das Inventory ist sauber gruppiert – jetzt kommt der eigentliche Mehrwert: Ein Playbook, mehrere Plays mit jeweils eigenem hosts.

Anstatt drei verschiedene Playbooks für Web, DB und Monitoring zu pflegen, definieren wir ein update.yml, das alle drei Gruppen abdeckt. Die Trennung passiert nur über die Play-Zeilen hosts: – ohne Ansible-Tags (für Polycrate-Betrieb sind tag-lastige Playbooks nicht empfohlen).

- name: Update Webserver
  hosts: webservers
  become: true
  tasks:
    - name: Paketindex aktualisieren
      ansible.builtin.apt:
        update_cache: yes
        cache_valid_time: 3600

    - name: Sicherheitspatches installieren
      ansible.builtin.apt:
        upgrade: dist
      register: web_update

    - name: Webserver neu starten, falls Pakete aktualisiert wurden
      ansible.builtin.service:
        name: nginx
        state: restarted
      when: web_update is changed

- name: Update Datenbankserver
  hosts: databases
  become: true
  tasks:
    - name: Paketindex aktualisieren
      ansible.builtin.apt:
        update_cache: yes
        cache_valid_time: 3600

    - name: Datenbank-Pakete aktualisieren
      ansible.builtin.apt:
        name: "{{ item }}"
        state: latest
      loop:
        - postgresql
        - postgresql-contrib
      register: db_update

    - name: Datenbankdienst neu starten, falls Pakete aktualisiert wurden
      ansible.builtin.service:
        name: postgresql
        state: restarted
      when: db_update is changed

- name: Monitoring-Agents prüfen
  hosts: monitoring
  become: true
  tasks:
    - name: Sicherstellen, dass der Monitoring-Agent installiert ist
      ansible.builtin.apt:
        name: acme-monitoring-agent
        state: latest

    - name: Monitoring-Agent läuft
      ansible.builtin.service:
        name: acme-monitoring-agent
        state: started
        enabled: true

Wichtig:

• Keine hosts: localhost und kein connection: local – wir wollen echte Server verwalten, nicht den kurzlebigen Polycrate-Container.
• Jede Play-Definition zielt auf eine Gruppe (webservers, databases, monitoring).
• Dank Idempotenz von Ansible ist es unkritisch, das Playbook öfter laufen zu lassen – geänderte Pakete werden erkannt, unnötige Änderungen vermieden.

Ausführen mit Polycrate: Actions und Workspace

Der Vorteil von Polycrate gegenüber plain Ansible ist hier zweigeteilt:

1. Guardrails und UX: Sie müssen sich weder merken, welche ansible-playbook-Parameter zu setzen sind, noch wo Ihr Inventory liegt. Ein polycrate run reicht.
2. Konsistente Toolchain im Container: Ansible-Version, Python, zusätzliche Tools – alles kommt aus dem Polycrate-Container. Kein lokales Setup-Chaos, keine „funktioniert nur auf meinem Laptop“-Situationen.

Für die Block-Instanz server-setup (entpackte Struktur unter blocks/registry.acme-corp.com/acme/infra/server-setup/, sobald der Block lokal vorliegt) sieht der Aufruf so aus:

polycrate run server-setup apply

Polycrate:

• Lädt die Block-Instanz server-setup (definiert in workspace.poly).
• Startet den konfigurierten Container.
• Nutzt automatisch inventory.yml aus dem Workspace-Root.
• Führt das der Action apply zugeordnete Playbook mit Ansible im Container aus.

Polycrate definiert keine eigenen Flags für Ansible-Tags oder Inventory-Gruppen – das Steuerungsmodell ist der Workspace (und darin die Block-Instanzen samt config). Zusätzliche Argumente an polycrate run werden nicht an ansible-playbook durchgereicht; Umgebungs- und Rollenlogik modellieren Sie über Workspaces, Blöcke und Block-Konfiguration, nicht über Tag-Matrizen oder Inventories als „Schalterboard“ (siehe Best Practices).

Wenn Sie z. B. nur Webserver in einem Schritt ansprechen wollen, ist der saubere Weg typischerweise nicht ein polycrate run, der implizit über Ansible-Tags „aussortiert“. Üblich ist vielmehr, im Block config.hosts (oder einen ähnlichen Schlüssel) zu setzen und im Playbook hosts: "{{ block.config.hosts }}" zu verwenden – damit steuern Sie pro Action Run gezielt Gruppen wie webservers oder einzelne Hosts, weiterhin mit demselben inventory.yml im Workspace. Dasselbe Prinzip zeigt der Beitrag Linux-Server auf Autopilot mit default_target_group. Ergänzend können ein separates Playbook mit festem hosts: webservers oder eine eigene Block-Action sinnvoll sein.

Mit plain Ansible müssten Sie dieselbe Ausführung mit lokalem ansible-playbook und konsistenter Toolchain nachbauen; Polycrate kapselt den Lauf in eine standardisierte Action im Container.

Dynamische Inventories: Cloud-Flotten in ein statisches Inventory überführen

Viele Umgebungen sind heute dynamisch: VMs entstehen und verschwinden, Auto-Scaling-Gruppen passen die Hostanzahl an. Klassisches Ansible kennt dafür „Dynamic Inventory Scripts“ oder Plugins.

Polycrate verfolgt hier einen bewusst einfachen Ansatz:

• Zur Laufzeit von Actions arbeitet Ansible immer mit einem YAML-Inventory im Workspace-Root: inventory.yml.
• Dieses inventory.yml können Sie aber vorher dynamisch generieren – z.B. durch einen separaten Block, der die Cloud-API abfragt und daraus die Datei schreibt.

Ein minimalistisches Beispiel (Pseudocode, Konzept im Vordergrund): Ein Block blocks/inventory-sync könnte per Python oder Shell-Tooling aus Ihrem Cloud-Provider die Liste der Web- und DB-Server holen und inventory.yml aktualisieren.

Das Entscheidende:

• Polycrate trennt klar zwischen Erzeugung des Inventories (Ihre Logik, z.B. via API) und der Nutzung des Inventories (alle Blöcke und Actions im Workspace).
• Für Teams entsteht damit wieder ein zentraler Ort der Wahrheit – selbst wenn die Hosts im Hintergrund dynamisch sind.

Wenn Sie tiefer in dynamische Inventories einsteigen wollen, lohnt sich ein Blick in die Ansible-Integration und in unsere Best Practices.

Polycrate vs. plain Ansible: Wo das Inventory wirklich gewinnt

Ansible selbst ist ein exzellentes Tool. Der Unterschied liegt in der Betriebsform:

Mit plain Ansible:

• Jeder Admin hat seine eigene Installation (Versionen weichen ab).
• Inventories werden gern „projektweise“ dupliziert (inventory-prod.yml, inventory-web.yml, inventory-db.yml).
• Das Teilen von Best Practices und Playbooks über Teams hinweg erfordert Disziplin, Git-Workflow, Dokumentation.

Mit Polycrate:

• Ansible läuft immer im Container – identische Version für alle, kein Python- oder Abhängigkeits-Chaos.
• Der Workspace erzwingt ein zentrales Inventory (inventory.yml im Root), das für alle Blöcke gilt.
• Durch das Block-Modell bleiben Playbooks und Actions strukturiert. Es entsteht keine unübersichtliche Playbook-Landschaft.
• Ihre Automatisierung ist sharable: Blöcke können versioniert und z.B. über Polycrate-Registries oder den PolyHub geteilt werden. Das Inventory bleibt dabei workspace-spezifisch, die Logik (Block) aber wiederverwendbar.

Für Compliance-Teams kommt ein weiterer Punkt dazu: Polycrate bringt eingebaute Workspace-Verschlüsselung mit age mit. Sensible Daten (SSH-Keys, Zugangsdaten, Zertifikate) liegen verschlüsselt im Workspace, ohne dass Sie externe Vault-Produkte integrieren müssen. Details dazu in der Dokumentation zur Workspace-Verschlüsselung.

Häufige Fragen

Wie gehe ich mit unterschiedlichen Linux-Distributionen im gleichen Inventory um?

Sie können unterschiedliche Distributionen problemlos im gleichen inventory.yml verwalten. Typische Muster:

• Eigene Gruppen je Distribution, z.B. ubuntu_webservers, rhel_webservers.

• Distribution-spezifische Variablen in Gruppenvariablen:

  all:
    children:
      ubuntu_webservers:
        vars:
          ansible_python_interpreter: /usr/bin/python3
          package_manager: apt
        hosts:
          web-ubuntu-01.acme-corp.com:
  
      rhel_webservers:
        vars:
          ansible_python_interpreter: /usr/bin/python3
          package_manager: yum
        hosts:
          web-rhel-01.acme-corp.com:

Im Playbook können Sie dann entweder gruppenspezifische Plays definieren oder when-Bedingungen auf group_names bzw. package_manager nutzen. Polycrate macht hier keinen Unterschied – wichtig ist nur, dass alle Hosts im zentralen Workspace-Inventory geführt werden.

Wie binde ich SSH-Keys und Bastion-Hosts in Polycrate sauber ein?

SSH-Parameter und Bastion-Hosts modellieren Sie wie gewohnt über Ansible-Variablen:

• ansible_ssh_common_args für ProxyCommand / Jump-Hosts.
• Host- und Gruppenvariablen für spezifische Ports oder Benutzer.
• SSH-Keys selbst liegen typischerweise in artifacts/secrets/ Ihres Workspaces und können über Ansible-Variablen referenziert werden.

Polycrate selbst kümmert sich darum, dass diese Dateien im Container verfügbar sind. Eine ausführliche Beschreibung der Optionen und Best Practices (inkl. Beispielen mit Bastion-Hosts) finden Sie in der SSH-Dokumentation von Polycrate.

Kann ich bestehende Ansible-Projekte einfach nach Polycrate „umziehen“?

Ja, in vielen Fällen ist das relativ geradlinig:

1. Bestehende Playbooks in einen Block übernehmen, versionieren und per OCI-Registry teilen (polycrate blocks push).
2. Eine block.poly anlegen, die Ihre Playbooks in Actions kapselt.
3. Einen neuen Workspace mit workspace.poly erstellen und Ihre Blöcke dort referenzieren.
4. Ihr bisheriges Inventory in ein zentrales inventory.yml im Workspace-Root überführen und ggf. gruppenbasiert aufräumen.
5. Die Ausführung von ansible-playbook ... auf polycrate run BLOCK ACTION umstellen.

Genau diesen Weg gehen wir häufig gemeinsam mit Teams in Projekten und Workshops: Bestehende Automatisierung respektieren, aber in ein strukturiertes, teilbares Polycrate-Modell überführen.

Weitere Fragen? Siehe unsere FAQ

Von der Theorie zur Umsetzung

In diesem Beitrag haben Sie gesehen, wie Sie mit Polycrate:

• Ein zentrales, YAML-basiertes Inventory pro Workspace etablieren, das allen Blöcken und Teams als gemeinsame Wahrheit dient.
• Über Gruppen und all.vars eine heterogene Flotte aus Web-, Datenbank- und Monitoring-Hosts konsistent beschreiben.
• Differenzierte Rollouts über Playbook-Design (hosts:, Tags im Playbook selbst) planen – Zusatzargumente an polycrate run werden an ansible-playbook nicht durchgereicht.
• Dank Container-Ausführung von Ansible keine Zeit mehr in lokale Setups, Versionskonflikte und Ad-hoc-Inventories investieren müssen.

Für erfahrene System-Administratoren ist das vor allem eines: ein Weg von fragilen Einzellösungen hin zu reproduzierbarer Flotten-Automatisierung, die sich sauber in Teamstrukturen und Compliance-Anforderungen einfügt.

In unseren Multi-Server Workshops gehen wir mit Ihnen genau diese Schritte durch – von der Analyse Ihrer bestehenden Playbooks und Inventories, über das Design eines Polycrate-Workspaces und Block-Modells, bis hin zu automatisierten, nachvollziehbaren Updates Ihrer Serverflotte.

Wenn Sie Ihre bestehende Ansible-Automatisierung in eine skalierbare, teamfähige Struktur überführen möchten, ist das ein guter nächster Schritt: Multi-Server Workshop