Docker-Stacks auf Linux-Servern mit Polycrate verwalten

TL;DR

• Docker-Compose ist für viele Linux-Server-Setups weiterhin eine sinnvolle, pragmatische Lösung – besonders wenn Sie einzelne Hosts oder kleine Gruppen verwalten und kein Kubernetes einführen wollen.
• Mit Polycrate packen Sie Ihren Docker-Compose-Stack in einen wiederverwendbaren Block: block.poly für Konfiguration, docker-compose.yml.j2 als Template, Ansible-Playbook als Action – alles sauber strukturiert und teamfähig; der Block folgt derselben Registry-Konvention wie im Beitrag Nginx und Let’s Encrypt als wiederverwendbarer Polycrate-Block (registry.acme-corp.com/infra/…, Version per from: …:0.1.0 im Workspace, Veröffentlichung mit polycrate blocks push …).
• Geheime Werte liegen nicht in der docker-compose.yml und nicht in der lesbaren workspace.poly, sondern in secrets.poly im gleichen YAML-Format wie workspace.poly (Merge zur Laufzeit); die Datei wird im Rahmen der Workspace-Verschlüsselung geschützt – im Template referenzieren Sie block.config.db_password nach dem Merge.
• Rolling Updates und (nahezu) Zero-Downtime-Deployments auf Linux-Servern werden mit Ansible community.docker.docker_compose, Health-Checks und Polycrate-Actions reproduzierbar und für Kolleg:innen einfach ausführbar.
• ayedo unterstützt Sie mit Polycrate, Best Practices und individuellen Docker-Automatisierungslösungen – von lokalem Docker-Compose bis hin zu kompletten Plattform-Setups.

Docker-Compose auf Linux-Servern: Wann es Sinn macht

Nicht jedes Team braucht sofort Kubernetes. Viele System-Admins betreiben heute:

• ein paar Linux-Server mit Docker,
• Anwendungen als simple Docker-Compose-Stacks,
• vielleicht eine kleine HA-Konfiguration über zwei, drei Hosts.

Für solche Szenarien ist Docker-Compose oft genau richtig:

• Einfacher Einstieg: docker-compose up -d kennen viele Admins bereits.
• Geringe Komplexität: Kein Control-Plane-Cluster, kein etcd, keine Ingress-Controller.
• Direkte Kontrolle: Sie sehen die Container direkt auf dem Host, Logs via docker logs, Volumes im Filesystem.

Die Probleme kommen an anderer Stelle:

• Jedes Teammitglied hat eine andere Docker-/Compose-/Python-Version.
• Playbooks und Shell-Skripte liegen unstrukturiert auf verschiedenen Maschinen.
• Secrets stehen in docker-compose.yml, .env-Dateien oder im Wiki.
• Updates sind manuelle SSH-Sessions und Copy-Paste von Kommandos.

Genau hier setzt Polycrate an: Ansible läuft vollständig im Container, die Automatisierung wird als Block strukturiert, Geheimnisse werden verschlüsselt, und alles ist als wiederverwendbare Einheit teilbar.

Eine gute Übersicht zur Ansible-Integration in Polycrate finden Sie in der offiziellen Dokumentation.

Ausgangspunkt: Polycrate-Workspace und Inventory

Wir bauen ein Beispiel-Setup für die fiktive Firma acme-corp.com. Zielgruppe: Linux-Admins, die einen Docker-Compose-Stack (z. B. App + Postgres) auf mehreren Ubuntu-Servern verwalten.

workspace.poly

Zuerst definieren wir unseren Workspace:

# workspace.poly
name: acme-corp-automation
organization: acme

blocks:
  - name: acme-app-stack
    from: registry.acme-corp.com/infra/docker-stack:0.1.0
    config:
      stack_name: acme-app
      docker_host_group: docker_hosts
      host_port: 80
      app_port: 8080
      image_app: "ghcr.io/acme/app:1.2.3"
      db_image: "postgres:15-alpine"
      db_name: "acmeapp"
      db_user: "acmeapp"
      backup_host: "backup01.acme-corp.com"
      backup_path: "/data/backups/acme-app"

Wichtig:

• Der Block kommt aus eurer Container Registry registry.acme-corp.com. In from: ist die Version explizit gepinnt (:0.1.0) – Best Practice für reproduzierbare Builds (siehe Registry-Dokumentation). Beim ersten Zugriff lädt Polycrate den Block nach blocks/registry.acme-corp.com/infra/docker-stack/ (Pfad spiegelt den Registry-Namen).
• Konfigurationen sind zentral unter config abgelegt und werden später im Template und im Playbook verwendet.
• Wir benennen eine Ansible-Hostgruppe docker_hosts, die wir im Inventory definieren.

inventory.yml

Polycrate verwendet ein YAML-Inventory im Workspace-Root:

# inventory.yml
all:
  hosts:
    docker01.acme-corp.com:
      ansible_user: ubuntu
    docker02.acme-corp.com:
      ansible_user: ubuntu
  children:
    docker_hosts:
      hosts:
        docker01.acme-corp.com:
        docker02.acme-corp.com:

• Polycrate setzt ANSIBLE_INVENTORY automatisch auf diese Datei.
• Hosts stehen unter all.hosts; Child-Gruppen listen nur die Hostnamen (ohne erneute Variablen) – so passt das Inventory zur SSH-Integration (polycrate ssh).
• Wir werden gleich im Playbook hosts: "{{ block.config.docker_host_group }}" verwenden.

Docker-Compose-Stack als Polycrate-Block

Jetzt modellieren wir den Docker-Compose-Stack als Block. Dieser Block enthält:

• block.poly mit Actions (deploy, backup, remove) und Block-Konfiguration,
• ein Jinja2-Template docker-compose.yml.j2,
• Ansible-Playbooks deploy.yml, backup.yml und remove.yml,
• im Workspace: secrets.poly für sensible Konfigurationswerte (gleiches Format wie workspace.poly, siehe unten).

block.poly

# blocks/registry.acme-corp.com/infra/docker-stack/block.poly
name: registry.acme-corp.com/infra/docker-stack
version: 0.1.0
kind: generic

config:
  stack_name: acme-app
  docker_host_group: docker_hosts
  host_port: 80
  app_port: 8080
  image_app: "ghcr.io/acme/app:1.2.3"
  db_image: "postgres:15-alpine"
  db_name: "acmeapp"
  db_user: "acmeapp"
  db_container_name: "acme-app-db"
  backup_host: "backup01.acme-corp.com"
  backup_path: "/data/backups/acme-app"

actions:
  - name: deploy
    playbook: deploy.yml
    description: "Deploy oder Update des Docker-Compose-Stacks mit Rolling Update"
  - name: backup
    playbook: backup.yml
    description: "Backup der Postgres-Datenbank aus dem Docker-Container"
  - name: remove
    playbook: remove.yml
    description: "Stack vollständig entfernen (Container, Volumes, Projektverzeichnis)"

Damit haben wir:

• Guardrails: Der Block gibt Struktur vor, anstatt dass Playbooks “irgendwo” liegen.
• Sharable Automation: Derselbe Block ist ein OCI-Artefakt in eurer Registry und für andere Workspaces über from: mit Tag nutzbar; optional zusätzlich über PolyHub auffindbar.

Registry: Block veröffentlichen (polycrate blocks push)

Voraussetzungen und Namensmodell (vollständiger OCI-name ohne Tag in der block.poly, Version im Feld version:) sind im Beitrag Nginx und Let’s Encrypt als wiederverwendbarer Polycrate-Block erklärt. Kurz zum Einprägen des Block-Sharings:

polycrate blocks push registry.acme-corp.com/infra/docker-stack

Damit landet registry.acme-corp.com/infra/docker-stack:0.1.0 in der Registry – Kolleg:innen nutzen exakt diese Referenz in workspace.poly (from: mit Tag), ohne Playbooks manuell zu kopieren.

Der Aufruf ist für das Team immer gleich:

polycrate run acme-app-stack deploy
polycrate run acme-app-stack backup
polycrate run acme-app-stack remove

Kein Ansible-CLI-Wirrwarr mehr – Polycrate-Actions bieten eine einfache UX, auch für Kolleg:innen, die nicht täglich mit Ansible arbeiten.

Jinja2-Template: docker-compose.yml aus block.config

Statt eine feste docker-compose.yml zu committen, nutzen wir ein Jinja2-Template. So kommen Ports, Images und Volumes dynamisch aus block.config (inkl. per Merge aus secrets.poly übernommene Geheimnisse wie db_password).

# blocks/registry.acme-corp.com/infra/docker-stack/docker-compose.yml.j2
version: "3.9"

services:
  app:
    image: "{{ block.config.image_app }}"
    container_name: "{{ block.config.stack_name }}-app"
    restart: unless-stopped
    depends_on:
      - db
    environment:
      DATABASE_URL: "postgresql://{{ block.config.db_user }}:{{ block.config.db_password }}@db:5432/{{ block.config.db_name }}"
    ports:
      - "{{ block.config.host_port }}:{{ block.config.app_port }}"
    volumes:
      - "{{ block.config.stack_name }}-app-data:/var/www/data"
    healthcheck:
      test: ["CMD-SHELL", "curl -f http://localhost:{{ block.config.app_port }}/health || exit 1"]
      interval: 10s
      timeout: 3s
      retries: 10

  db:
    image: "{{ block.config.db_image }}"
    container_name: "{{ block.config.db_container_name }}"
    restart: unless-stopped
    environment:
      POSTGRES_DB: "{{ block.config.db_name }}"
      POSTGRES_USER: "{{ block.config.db_user }}"
      POSTGRES_PASSWORD: "{{ block.config.db_password }}"
    volumes:
      - "{{ block.config.stack_name }}-db-data:/var/lib/postgresql/data"

volumes:
  {{ block.config.stack_name }}-app-data: {}
  {{ block.config.stack_name }}-db-data: {}

Wichtig:

• db_password kommt nach dem Merge von workspace.poly und secrets.poly in block.config an und steht im Template als block.config.db_password zur Verfügung.
• Das Template enthält keine Klartext-Passwörter; workspace.poly bleibt ohne Geheimnisse lesbar.
• Healthcheck der App nutzen wir später im Ansible-Playbook für das Zero-Downtime-Update.

Secrets: secrets.poly im gleichen Format wie workspace.poly

Passwörter gehören nicht in .env oder in die docker-compose.yml. In Polycrate legen Sie sensible Werte in secrets.poly im Workspace-Root ab – mit demselben YAML-Schema wie workspace.poly, damit Polycrate die Dateien zur Laufzeit merged (Reihenfolge der Überlagerung: block.poly, dann workspace.poly, dann secrets.poly). So bleibt workspace.poly lesbar und frei von Geheimnissen; secrets.poly wird im Rahmen der Workspace-Verschlüsselung geschützt (Klartext typischerweise nur lokal, verschlüsselte .age-Artefakte im Git). Ausführlich: Konfiguration und Workspace-Verschlüsselung.

secrets.poly (Workspace-Root)

# secrets.poly (Workspace-Root, neben workspace.poly)
blocks:
  - name: acme-app-stack
    config:
      db_password: "hier-steht-das-echte-Postgres-Passwort"

Der Block-Instanzname acme-app-stack entspricht dem Eintrag unter blocks: in workspace.poly. Nach dem Merge steht db_password in Ansible/Templates wie gewohnt unter block.config.db_password zur Verfügung.

Vorteile:

• Kein HashiCorp Vault nötig für diesen Use Case.
• Kein Klartext in Git für Passwörter, keine .env-Lecks.
• Im Template nutzen Sie block.config.db_password (siehe docker-compose.yml.j2 oben).

Ansible-Playbook: Deploy & Rolling Update mit community.docker.docker_compose

Das Herzstück ist das Ansible-Playbook, das Polycrate im Container ausführt. Wichtig: Das Playbook läuft im Polycrate-Container, aber steuert per SSH die Linux-Server aus dem Inventory (hosts: docker_hosts). Wir installieren nichts im Container selbst außer den notwendigen Tools.

deploy.yml

# blocks/registry.acme-corp.com/infra/docker-stack/deploy.yml
- name: Deploy Docker-Compose-Stack mit Rolling Update
  hosts: "{{ block.config.docker_host_group }}"
  become: true
  serial: 1
  vars:
    project_name: "{{ block.config.stack_name }}"
    project_dir: "/opt/{{ project_name }}"
  tasks:
    - name: Zielverzeichnis für den Stack anlegen
      ansible.builtin.file:
        path: "{{ project_dir }}"
        state: directory
        owner: root
        group: root
        mode: "0750"

    - name: docker-compose.yml aus Template rendern
      ansible.builtin.template:
        src: "docker-compose.yml.j2"
        dest: "{{ project_dir }}/docker-compose.yml"
        owner: root
        group: root
        mode: "0640"

    - name: Neueste Images ziehen
      community.docker.docker_compose:
        project_src: "{{ project_dir }}"
        files:
          - "docker-compose.yml"
        pull: yes
        state: present

    - name: Stack aktualisieren (Rolling Update pro Host)
      community.docker.docker_compose:
        project_src: "{{ project_dir }}"
        files:
          - "docker-compose.yml"
        state: present
        remove_orphans: true
      register: compose_result

    - name: Auf gesunden Zustand des App-Containers warten
      ansible.builtin.uri:
        url: "http://{{ inventory_hostname }}:{{ block.config.host_port }}/health"
        status_code: 200
        timeout: 5
        validate_certs: false
      register: healthcheck
      retries: 30
      delay: 2
      until: healthcheck.status == 200

remove.yml

Die remove-Action fährt den Stack auf den Ziel-Hosts kontrolliert herunter, entfernt Container und benannte Volumes und löscht das Projektverzeichnis – destruktiv für die Postgres-Daten im Volume, wenn Sie remove_volumes: true nutzen.

# blocks/registry.acme-corp.com/infra/docker-stack/remove.yml
- name: Docker-Compose-Stack vollständig entfernen
  hosts: "{{ block.config.docker_host_group }}"
  become: true
  serial: 1
  vars:
    project_name: "{{ block.config.stack_name }}"
    project_dir: "/opt/{{ project_name }}"
  tasks:
    - name: Compose-Projekt stoppen und entfernen (inkl. Volumes)
      community.docker.docker_compose:
        project_src: "{{ project_dir }}"
        files:
          - "docker-compose.yml"
        state: absent
        remove_volumes: true

    - name: Projektverzeichnis auf dem Host löschen
      ansible.builtin.file:
        path: "{{ project_dir }}"
        state: absent

Ein paar Punkte dazu:

• serial: 1 sorgt für ein Rolling Update über die Hosts in docker_hosts.
  • Auf docker01 wird aktualisiert und der Healthcheck abgewartet.
  • Erst danach folgt docker02 usw.
• Innerhalb eines Hosts übernimmt community.docker.docker_compose das “Updaten ohne alles abzureißen”:
  • state: present mit dem selben Projekt führt im Hintergrund das Äquivalent zu docker-compose pull + docker-compose up -d aus.
• Der Healthcheck im Compose-File und der uri-Task minimieren Downtime:
  • Die Anfrage trifft nur dann auf “den neuen” Container, wenn er wirklich bereit ist.

Mehr Details zur Nutzung von Ansible mit Polycrate finden Sie im Abschnitt Ansible-Integration der Dokumentation.

Polycrate-Befehl

Ausführen ist jetzt trivial:

polycrate run acme-app-stack deploy
polycrate run acme-app-stack remove

Polycrate:

• startet den vorbereiteten Container mit Ansible, Python und community.docker,
• bindet Ihren Workspace ein,
• stellt Inventory und gemergte Block-Konfiguration (inkl. Werte aus secrets.poly) bereit,
• führt deploy.yml bzw. remove.yml für den Block acme-app-stack aus.

Kein lokales Ansible, kein Python-Versions-Chaos, kein Frickeln an ansible.cfg. Das ist die Lösung des klassischen Dependency-Problems.

Backup-Action im Block: docker exec, pg_dump, tar, rsync

Backups sind oft das, was im Alltag “später” automatisiert wird – bis es zu spät ist. Die gute Nachricht: Im selben Block können Sie eine backup-Action definieren, die regelmäßig oder ad hoc läuft.

backup.yml

# blocks/registry.acme-corp.com/infra/docker-stack/backup.yml
- name: Backup der Postgres-Datenbank aus dem Docker-Container
  hosts: "{{ block.config.docker_host_group }}"
  become: true
  vars:
    project_name: "{{ block.config.stack_name }}"
    backup_dir: "/var/backups/{{ project_name }}"
    timestamp: "{{ ansible_date_time.iso8601_basic }}"
    backup_file: "{{ backup_dir }}/{{ block.config.db_name }}-{{ timestamp }}.sql.gz"
  tasks:
    - name: Backup-Verzeichnis auf dem Host anlegen
      ansible.builtin.file:
        path: "{{ backup_dir }}"
        state: directory
        owner: root
        group: root
        mode: "0750"

    - name: pg_dump im Container ausführen und komprimieren
      ansible.builtin.shell: >
        docker exec {{ block.config.db_container_name }}
        pg_dump -U {{ block.config.db_user }} {{ block.config.db_name }}
        | gzip > {{ backup_file }}
      args:
        executable: /bin/bash

    - name: Backup auf Backup-Server synchronisieren
      ansible.builtin.shell: >
        rsync -az {{ backup_dir }}/
        backup@{{ block.config.backup_host }}:{{ block.config.backup_path }}/
      args:
        executable: /bin/bash

Hier nutzen wir bewusst klassische Admin-Tools:

• docker exec für pg_dump des Datenbank-Containers.
• gzip zur Komprimierung.
• rsync für die Übertragung auf einen Backup-Server.

Auch das läuft natürlich komplett aus dem Polycrate-Container heraus auf den Ziel-Hosts. Starten:

polycrate run acme-app-stack backup

Sie können diese Action in einen Polycrate-Workflow einbinden, z. B. “backup und danach aufräumen”. Mehr dazu in der Dokumentation zu Workflows.

Polycrate vs. plain Ansible: derselbe Stack, weniger Reibung

Wie sähe das gleiche Setup mit “plain Ansible” typischerweise aus?

• Sie installieren Ansible manuell auf Ihrem Laptop (oder einem Jumphost).
• Sie verwalten Python-Versionen, community.docker-Collection, eventuell docker-Python-Bindings.
• Jeder im Team hat ein eigenes Setup; “funktioniert nur bei mir” ist Alltag.
• ansible-vault wird für Secrets genutzt, aber nicht jeder kommt gut damit zurecht.
• Playbooks und Rollen liegen teils auf Laptops, teils auf Shares.

Mit Polycrate:

• Läuft alles im Container – keine lokalen Abhängigkeiten, die driften können.
• Workspace- und Block-Struktur verhindern Playbook-Wildwuchs.
• Sensible Werte liegen in secrets.poly (gleiches Format wie workspace.poly) und werden über die Workspace-Verschlüsselung geschützt.
• Actions sind klar benannte, wiederverwendbare Use Cases (deploy, backup, remove), die Sie auch Kolleg:innen anvertrauen können, die sonst wenig mit Ansible zu tun haben.

Der Block ist – wie oben – bereits als Artefakt in registry.acme-corp.com gedacht; polycrate blocks push registry.acme-corp.com/infra/docker-stack ist der wiederkehrende Schritt bei neuen Versionen. Ergänzend: PolyHub und die Polycrate-Best-Practices.

Wann Docker-Compose, wann Kubernetes? Eine pragmatische Entscheidungshilfe

Docker-Compose und Kubernetes sind Werkzeuge mit unterschiedlichen Stärken. Aus Admin-Sicht hilft folgende Daumenregel:

Docker-Compose ist oft die bessere Wahl, wenn:

• Sie pro Stack einen Host betreiben: Docker Compose beschreibt kein Multi-Node-Deployment; denselben Stack auf mehrere Maschinen zu bringen, ist Orchestrierung mit Ansible/Polycrate (wie in diesem Beitrag), nicht eine Compose-Funktion.
• Die Anzahl der Services überschaubar ist.
• Sie primär statische Deployments haben (z. B. 1–2 Releases pro Monat).
• Sie direkten SSH-Zugriff auf die Hosts haben und das auch so behalten wollen.
• Sie keine komplexen Multi-Tenant-Anforderungen haben.

Kubernetes wird interessanter, wenn:

• Sie deutlich mehr Services (>10) und/oder Teams haben.
• Sie kurzfristig skalieren müssen (mehr Replikas, Auto-Scaling).
• Sie Self-Service für Entwicklerteams anbieten wollen.
• Sie Multi-Region- oder Hybrid-Cloud-Szenarien planen.
• Sie ein Ökosystem aus Operators, Service-Mesh, GitOps etc. nutzen möchten.

Mit Polycrate sind Sie in beiden Welten zuhause:

• Heute Docker-Compose auf klassischen Linux-Servern, wie in diesem Beitrag gezeigt.
• Morgen eventuell Kubernetes mit denselben Prinzipien: Blöcke, Workspaces, Actions, verschlüsselte Secrets. Dazu gibt es offizielle Blöcke im PolyHub.

Der Punkt ist: Sie müssen Kubernetes nicht einführen, um saubere, reproduzierbare Automatisierung zu bekommen. Polycrate bringt Ordnung, Sharability und Sicherheit auch in bestehende Docker-Compose-Setups.

Häufige Fragen

Wie installiere ich Docker und die community.docker-Collection auf den Ziel-Hosts?

Docker selbst installieren Sie (falls noch nicht vorhanden) klassisch über Ihr Betriebssystem – z. B. apt auf Ubuntu. Das ist bewusst nicht Teil des Playbooks oben, um die Zuständigkeiten klar zu halten.

Die Ansible-Collection community.docker wird im Polycrate-Container bereitgestellt. Sie müssen sie nicht auf den Ziel-Hosts installieren – nur der Docker-Daemon und das docker-CLI müssen dort vorhanden sein. Polycrate kümmert sich darum, dass Ansible im Container die passende Collection-Version zur Verfügung hat, ohne Ihr lokales System zu verändern.

Alternativ können Sie einen eigenen Block (z. B. mit apt/dnf und dem offiziellen Docker-Repo) bauen, der Docker auf den Ziel-Hosts installiert – und diesen vor dem App-Stack-Block ausführen. Das bleibt hier bewusst eine Hausaufgabe für den Leser; dieser Beitrag fokussiert den Compose-Stack.

Was passiert mit meinen Secrets, wenn ich den Workspace in Git versioniere?

Die sensiblen Werte aus secrets.poly werden verschlüsselt abgelegt; die verschlüsselten Artefakte können im Git-Repository landen. workspace.poly bleibt ohne Passwörter lesbar – Geheimnisse stehen nur in secrets.poly (bzw. in der verschlüsselten Form in Git).

Solange Sie die Workspace-Verschlüsselung nutzen (siehe Workspace-Verschlüsselung), stehen keine Klartext-Geheimnisse in Git. Nur wer den Workspace-Schlüssel hat, kann entschlüsseln; in Playbooks/Templates verwenden Sie die gemergten Werte wie block.config.db_password.

Kann ich denselben Block in mehreren Umgebungen (z. B. staging, prod) nutzen?

Ja. Genau das ist eine der Stärken des Block-Modells. Typischer Ansatz:

• Ein Workspace pro Umgebung (acme-corp-automation-staging, acme-corp-automation-prod).
• In beiden Workspaces referenzieren Sie denselben Block (z. B. aus einer Registry).
• Unterschiedliche config-Werte im jeweiligen workspace.poly (z. B. andere Images, Ports, Hostgroups).
• Unterschiedliche Secrets pro Workspace (z. B. eigene DB-Passwörter).

So bleibt die Automatisierung identisch, aber die Umgebungsparameter sind sauber getrennt und bleiben trotzdem nachvollziehbar.

Weitere Fragen? Siehe unsere FAQ

Von der Routine zur reproduzierbaren Plattform

In diesem Beitrag haben Sie gesehen, wie Sie einen bestehenden Docker-Compose-Stack auf Linux-Servern in einen strukturierten Polycrate-Block überführen:

• Sie haben einen Workspace mit Inventory und Block-Instanz angelegt.
• Sie haben block.poly, docker-compose.yml.j2, deploy.yml, backup.yml, remove.yml sowie secrets.poly im Workspace so kombiniert, dass Deployments, Backups und Aufräumen reproduzierbar, sicher und teamfähig sind.
• Sie nutzen die Stärken von Ansible (community.docker.docker_compose, Idempotenz, Rolling Updates) – ohne sich um lokale Python- oder Collection-Versionen kümmern zu müssen.
• Sie haben erlebt, wie Polycrate mit Workspace-Verschlüsselung und dem Block-Modell guardrails setzt, ohne Sie zu bevormunden.

Genau das ist der Ansatz, den wir bei ayedo verfolgen: Wir helfen Teams, vorhandene Infrastruktur – ob klassischer Linux-Server mit Docker-Compose oder später Kubernetes – in robuste, teilbare Automatisierung zu überführen. Polycrate ist dabei das Werkzeug, mit dem Sie als System-Admin Schritt für Schritt mehr Struktur, Sicherheit und Wiederverwendbarkeit etablieren können, ohne Ihren Stack über Nacht zu wechseln.

Wenn Sie Ihre eigenen Docker-Compose-Stacks in ähnliche Blöcke überführen oder eine bestehende Ansible-Landschaft in Polycrate migrieren möchten, unterstützen wir Sie gern – von ersten Workshop-Sessions bis zu maßgeschneiderten Plattform-Lösungen.

Starten Sie mit einer unverbindlichen Docker-Automatisierung Demo