Znuny Docker – offizieller Stack, Compose & Befehle (2026)

Verwandte Themen: Docker-Compose-Installation · Staging- & Testsystem · Znuny REST API · Add-ons & Plugins · OpenTicketAI

Einführung

Mit Znuny Docker betreiben Sie das Ticketsystem in isolierten Containern: gleiche Laufzeitumgebung auf jedem Host, klare Trennung der Dienste und einfaches Hoch- und Herunterfahren. Docker eignet sich besonders für Demos, Testsysteme und Staging.

Offizieller Stack seit 2026

Znuny pflegt znuny/znuny-docker — Dockerfiles, docker-compose.yml (Compose akzeptiert auch compose.yml) und Images unter ghcr.io/znuny/znuny-docker. Das README kennzeichnet das Setup als experimentell: Upgrades können manuelle Schritte brauchen. Für Bare-Metal-Produktion folgen Sie doc.znuny.org.

Erste Docker-Installation? Schritt-für-Schritt: Znuny mit Docker Compose installieren.

Verfügbare Docker-Stacks

Projekt	Status	Geeignet für	Hinweise
znuny/znuny-docker	Offiziell (experimentell)	Znuny 7.3.x, getrennt httpd + Daemon + MariaDB	Auto-Install per .env, Traefik- und External-DB-Overrides, GHCR
Erik-Donath/znuny-docker	Community	Znuny 7.x mit Web-Installer (/znuny/installer.pl)	Ein App-Container + MariaDB
juanluisbaptiste/docker-otrs	Community	Znuny 6.x LTS, SMTP-Relay, geplante Backups	Legacy-Pfad /otrs/
nyanmark/znuny-docker	Community	Minimales Nginx- + PostgreSQL-Beispiel	Aktivität prüfen
cygnusnetworks/znuny	Community-Image	Debian-Images aus offiziellen Tarballs	Nicht Znuny GmbH

Vor dem Einsatz außerhalb lokaler Tests: Repository-Aktivität, Issues und Versionsunterstützung prüfen.

Architektur des offiziellen Stacks

Die offizielle Compose-Datei (docker-compose.yml im Repo — Compose v2 lädt compose.yml oder docker-compose.yml) trennt die Rollen:

Service	Containername	Rolle
znuny-httpd	znuny_httpd	Apache + Install-/Upgrade-Lifecycle
znuny-daemon	znuny_daemon	Znuny-Daemon (geplante Tasks; kein Linux-Cron)
znuny-db	znuny_db	MariaDB (weglassen mit docker-compose.external-db.yml)
znuny-base	(nur Build)	Gemeinsames Image: Debian, Perl-Module, Znuny-Tarball

Volumes: ZnunyApp (/opt/znuny), ZnunyPersistent (Config.pm, Versionsdatei), MariaDBVol.

Pflicht in .env (keine Defaults): ROOT_PASS, DB_USER_PASS, ZNUNY_ADMIN_PASS. Optional: ZNUNY_IMAGE_TAG, CONTAINER_REGISTRY=ghcr.io/znuny/znuny-docker, external_port (Standard 80), Ressourcenlimits.

Beim ersten Start läuft install.sh (Schema, SecureMode, zufällige SystemID, Admin-Passwort). Es gibt keinen Web-Installer.

Schnellstart mit Docker Compose

Offizieller Weg (Details in der Installationsanleitung):

1. Docker installieren — Ubuntu oder Debian
2. znuny/znuny-docker klonen
3. cp .env.example .env und die drei Pflichtpasswörter setzen
4. Starten: docker compose up -d --build (oder GHCR-Images ohne --build)
5. http://<host>:<external_port>/znuny/ öffnen und mit ZNUNY_ADMIN_PASS anmelden
6. Datenbank-Host im Stack: znuny-db, nicht localhost

docker compose up -d --build
docker compose ps
docker compose logs -f znuny-httpd

Testsystem, Demo und Staging mit Docker

Ziel	Empfehlung
Lokale Demo	Offizieller Compose-Stack auf PC oder VM
Test / Staging	Eigene Compose-Instanz mit anonymisierten Produktivdaten
CI / E2E	Kurzlebiger Stack in der Pipeline, danach docker compose down

Vollständiger Staging-Ablauf: Znuny Staging-System.

KI-Automatisierung in Docker

OpenTicketAI läuft als zusätzlicher On-Premise-Container und nutzt die Znuny REST API.

Docker vs. klassische Installation

Thema	Offizielles Docker	Klassisch (doc.znuny.org)
Setup	Repo klonen, .env, docker compose up	Apache, MariaDB/PostgreSQL, Perl-Module
Konfiguration	.env, Volumes, optionales Traefik-Override	Host-Pakete, Config.pm, SysConfig
Persistenz	ZnunyApp, ZnunyPersistent, MariaDBVol	Dateisystempfade auf dem Server
Updates	Neuer Image-Tag + upgrade.sh (noch experimentell)	Paket/Tar-Upgrade + Konsolen-Migration
Hintergrundjobs	Eigener znuny-daemon-Container	Cron.sh, systemd
Offizieller Support	Experimentelles Docker-Repo + klassische Doku	Vom Znuny-Projekt dokumentiert

Typische Container in Compose-Stacks

Namen kommen aus dem Compose-Projekt. Immer mit docker compose ps prüfen.

Häufige Rollen:

1. Web / App — HTTP (Apache + mod_perl)
2. Datenbank — MariaDB oder PostgreSQL mit persistentem Volume
3. Daemon / Scheduler — Mail, Generic Agent, Eskalationen
4. SMTP-Relay (optional) — juanluisbaptiste u. a.
5. Reverse-Proxy (optional) — offizielles Traefik-Override oder Nginx/Caddy

Der offizielle Stack trennt Web und Daemon. Erik-Donath kombiniert Web, Cron und Daemon in znuny-app plus db.

Was sind Docker-Container?

Container isolieren Prozesse und Dateisysteme, teilen aber den Host-Kernel — leichter als volle VMs. Persistente Daten liegen in Volumes; das Container-Dateisystem ist vergänglich.

Docker-Dienst steuern (Linux mit systemd)

• Starten: sudo systemctl start docker
• Autostart: sudo systemctl enable docker
• Stoppen: sudo systemctl stop docker
• Status: sudo systemctl status docker

Auf Docker Desktop (Windows/macOS) entfallen diese systemctl-Befehle.

Container listen und steuern

• Laufende Container: docker ps
• Alle Container: docker ps -a
• Images: docker images
• Logs: docker logs <name> (folgen: docker logs -f <name>)
• Start/Stop: docker start <name> / docker stop <name>

Docker Compose (v2):

• Start: docker compose up -d
• Stop: docker compose down (--volumes nur zum Löschen der Daten)
• Neu bauen: docker compose up --build -d

Znuny-Konsolenbefehle im Container

Offizieller Stack

docker exec -u znuny znuny_daemon /opt/znuny/bin/znuny.Console.pl List
docker exec -u znuny znuny_daemon /opt/znuny/bin/znuny.Console.pl Maint::Cache::Delete
docker exec -u znuny znuny_daemon /opt/znuny/bin/znuny.Console.pl Maint::Config::Rebuild

Nach Add-on-Install/Deinstall Prozesse neu starten:

docker exec -u znuny znuny_daemon touch /persistent/restart-daemon /persistent/restart-httpd

Community-Stacks

docker compose exec znuny-app bash
bin/znuny.Console.pl --help

Servicenamen variieren (znuny-app, web, znuny). docker compose ps zeigt die Namen.

Überblick Kommandozeile (CLI)

• Maint::Cache::Delete — Cache löschen
• Maint::Config::Rebuild — SysConfig neu aufbauen
• Admin::Package::Install — OPM-Paket installieren
• Admin::Package::UpgradeAll — Pakete aus Repos aktualisieren
• Maint::Test::System — System-Selbsttest

Migration und Updates

• Dev::Tools::Migrate::OTRSToZnuny — Migrationswerkzeug (je Version prüfen)
• Admin::Package::UpgradeAll — installierte Pakete aktualisieren

Immer Backup von Datenbank und Volumes. Zuerst in Staging testen. Der offizielle Docker-Upgrade-Pfad ist noch unvollständig — znuny-docker README lesen.

Volumes, Backup und Wiederherstellung

Offizieller Stack

Volume	Inhalt
ZnunyApp	Gemeinsamer Anwendungbaum (/opt/znuny)
ZnunyPersistent	Config.pm, installierte Version, Restart-Trigger
MariaDBVol	MariaDB-Dateien

source .env
docker exec znuny_db mysqldump -u "$DB_USER" -p"$DB_USER_PASS" "$DB_NAME" | gzip > backup_$(date +%Y%m%d_%H%M%S).sql.gz

Wiederherstellen:

source .env
docker exec -i znuny_db mysql -u "$DB_USER" -p"$DB_USER_PASS" "$DB_NAME" < backup.sql

Community-Stacks (Beispiel Erik-Donath)

Volume	Inhalt
znuny-var	Anhänge, Cache, Sessions, Logs
znuny-config	Kernel/Config
znuny-custom	Custom-Code
db-data	MariaDB-Dateien

docker compose exec db mysqldump -u root -p znuny > znuny-backup-$(date +%F).sql

juanluisbaptiste — tägliche Backups unter /var/otrs/backups über OTRS_BACKUP_*. Siehe Projekt-README.

Volume-Archiv (Stack vorher stoppen):

docker compose down
sudo tar -czf znuny-volumes-$(date +%F).tar.gz /var/lib/docker/volumes/
docker compose up -d

Pakete und Add-ons im Container

Offiziell:

docker exec -u znuny znuny_daemon /opt/znuny/bin/znuny.Console.pl Admin::Package::Install /tmp/mein-paket.opm
docker exec -u znuny znuny_daemon /opt/znuny/bin/znuny.Console.pl Maint::Config::Rebuild
docker exec -u znuny znuny_daemon touch /persistent/restart-daemon /persistent/restart-httpd

OPM-Datei zuerst kopieren (docker cp) oder ein Host-Verzeichnis mounten.

Znuny Add-ons auf OpenITSMHub — Übersicht: Znuny Add-ons.

Produktions-Hinweise

• Offizielles Docker ist experimentell — kein Ersatz für eine dokumentierte Bare-Metal-Installation.
• Starke Werte für ROOT_PASS, DB_USER_PASS und ZNUNY_ADMIN_PASS vor dem ersten Start.
• TLS: offizielles docker-compose.traefik.yml (ZNUNY_DOMAIN, ACME_EMAIL) oder eigener Reverse-Proxy.
• Ressourcen: Defaults etwa 5 GB RAM über die Services (Daemon 2G, httpd 1G, DB 2G).
• E-Mail: auf Testsystemen ausgehende Mail deaktivieren (SendmailModule → Kernel::System::Email::DoNotSendEmail).
• Monitoring: docker compose ps, Healthchecks, Daemon- und httpd-Logs.
• Updates: README des offiziellen Repos folgen; Backups nicht überspringen.

Migration von OTRS

Backup, Paket-Migration und Datenbank-Upgrade planen. Hilfen: Dev::Tools::Migrate::OTRSToZnuny, Admin::Package::UpgradeAll — nach offizieller Migrationsdoku und mit Staging-Test.

juanluisbaptiste-Stacks können OTRS-Backup-Verzeichnisse mit OTRS_INSTALL=restore einspielen.

Weiterführende Hinweise

• Docker-Compose-Installation — Walkthrough des offiziellen Stacks
• Offizielles Repo: github.com/znuny/znuny-docker
• Offizielle Dokumentation: doc.znuny.org
• Znuny REST API
• OpenITSMHub – Znuny Plugins
• Projekt- und Servicenamen aus der eigenen Compose-Datei und docker compose ps ableiten

Znuny Hosting & Wartungsservice

Sorgenfreier Znuny-Betrieb: Softoft übernimmt Hosting, Staging-Umgebungen, regelmäßige Updates, Backups und kontinuierliches Monitoring.

Hosting & Betrieb anfragen

Häufig gestellte Fragen

Was ist der offizielle Znuny Docker Stack und wofür ist er gedacht?

Der offizielle Znuny Docker Stack, verfügbar unter github.com/znuny/znuny-docker, wird seit 2026 von Znuny gepflegt und bietet Dockerfiles sowie docker-compose.yml Dateien. Die zugehörigen Images finden Sie unter ghcr.io/znuny/znuny-docker. Dieser Stack trennt Znuny in verschiedene Container-Dienste, darunter einen für den Webserver (Apache), einen für den Znuny-Daemon und einen für die MariaDB-Datenbank. Obwohl er als experimentell gekennzeichnet ist und Upgrades manuelle Schritte erfordern können, eignet er sich hervorragend für die schnelle Bereitstellung von Demos, Testsystemen und Staging-Umgebungen. Für eine Bare-Metal-Produktionsumgebung empfiehlt Znuny weiterhin die klassische Installation gemäß der offiziellen Dokumentation.

Quellen:

• Znuny Docker – offizieller Stack, Compose & Befehle
• znuny/znuny-docker auf GitHub
• Znuny Dokumentation

Wie führe ich Znuny-Konsolenbefehle in einer Docker-Umgebung aus?

Um Znuny-Konsolenbefehle im offiziellen Docker Stack auszuführen, nutzen Sie den docker exec Befehl. Der Znuny-Daemon läuft im Container znuny_daemon unter dem Benutzer znuny. Der vollständige Befehl lautet: docker exec -u znuny znuny_daemon /opt/znuny/bin/znuny.Console.pl. Dies ermöglicht Ihnen, administrative Aufgaben wie Datenbankmigrationen, Cache-Löschungen oder das Hinzufügen von Benutzern direkt über die Kommandozeile innerhalb des laufenden Containers durchzuführen. Bei Community-Stacks, die oft einen einzigen App-Service verwenden, kann der Befehl variieren, meistens wird docker compose exec [service-name] [command] verwendet. Stellen Sie sicher, dass Sie den korrekten Service-Namen und den Pfad zur znuny.Console.pl kennen.

Quellen:

• Znuny Docker – offizieller Stack, Compose & Befehle
• Znuny Dokumentation

Wie kann ich Docker für Znuny-Test-, Demo- oder Staging-Systeme effektiv nutzen?

Docker ist ideal für die schnelle Einrichtung von Znuny-Instanzen zu Test-, Demo- oder Staging-Zwecken. Für eine lokale Demo können Sie den offiziellen Compose-Stack einfach auf Ihrem PC oder einer virtuellen Maschine starten. Ein Test- oder Staging-System sollte als eigene Compose-Instanz aufgesetzt werden, idealerweise mit anonymisierten Daten aus Ihrer Produktivumgebung, um realistische Tests zu ermöglichen. Für Continuous Integration (CI) oder End-to-End (E2E) Tests in einer Pipeline können Sie kurzlebige Stacks verwenden, die nach den Tests mit docker compose down wieder entfernt werden. Diese Flexibilität ermöglicht es, Änderungen sicher zu testen, bevor sie in Produktion gehen. Auch KI-Automatisierungslösungen wie OpenTicketAI können als zusätzliche Container in solchen Umgebungen betrieben werden.

Quellen:

• Znuny Docker – offizieller Stack, Compose & Befehle
• Znuny Staging-System
• OpenTicketAI

Welche wichtigen Hinweise gibt es für den produktiven Einsatz von Znuny mit Docker?

Der offizielle Znuny Docker Stack wird derzeit als experimentell eingestuft und ist nicht als direkter Ersatz für eine dokumentierte Bare-Metal-Installation in Produktionsumgebungen gedacht. Bei der Einrichtung ist es unerlässlich, vor dem ersten Start starke und komplexe Passwörter für die Umgebungsvariablen ROOT_PASS (für den Datenbank-Root-Benutzer), DB_USER_PASS (für den Znuny-Datenbankbenutzer) und ZNUNY_ADMIN_PASS (für den Znuny-Administrator) zu setzen. Für die Absicherung der Kommunikation mittels TLS können Sie die bereitgestellte docker-compose.traefik.yml Datei nutzen, indem Sie ZNUNY_DOMAIN und ACME_EMAIL konfigurieren, oder einen eigenen Reverse-Proxy wie Nginx oder Apache vor den Docker-Container schalten. Bei der Nutzung von Community-Stacks ist es zudem wichtig, die Aktivität des Repositorys, offene Issues und die Versionsunterstützung sorgfältig zu prüfen.

Quellen:

• Znuny Docker – offizieller Stack, Compose & Befehle
• Znuny Dokumentation

Welche Architektur verfolgt der offizielle Znuny Docker Stack und welche Komponenten sind enthalten?

Die Architektur des offiziellen Znuny Docker Stacks ist darauf ausgelegt, die verschiedenen Rollen des Ticketsystems in separate Container zu trennen, um Isolation und Skalierbarkeit zu gewährleisten. Die Hauptkomponenten sind:

• znuny-httpd: Dieser Container hostet den Apache-Webserver und ist für den Installations- und Upgrade-Lebenszyklus zuständig.
• znuny-daemon: Hier läuft der Znuny-Daemon, der für geplante Aufgaben und Hintergrundprozesse verantwortlich ist, und ersetzt den traditionellen Linux-Cron.
• znuny-db: Dieser Service stellt eine MariaDB-Datenbankinstanz bereit. Er kann bei Bedarf durch eine externe Datenbank ersetzt werden, indem docker-compose.external-db.yml verwendet wird.
• znuny-base: Dies ist ein Build-Container, der ein gemeinsames Basis-Image mit Debian, Perl-Modulen und dem Znuny-Tarball erstellt.
  Wichtige persistente Daten werden über Docker Volumes wie ZnunyApp (für /opt/znuny), ZnunyPersistent (für Config.pm und Versionsdateien) und MariaDBVol verwaltet. Beim ersten Start führt ein install.sh-Skript die Schema-Installation, SecureMode-Konfiguration und die Zuweisung einer zufälligen SystemID durch; ein Web-Installer ist nicht vorgesehen.

Quellen:

• Znuny Docker – offizieller Stack, Compose & Befehle
• znuny/znuny-docker auf GitHub

Wie unterscheidet sich die Docker-Installation von einer klassischen Bare-Metal-Installation von Znuny?

Die Installation und der Betrieb von Znuny unterscheiden sich grundlegend zwischen einer Docker-basierten und einer klassischen Bare-Metal-Umgebung. Bei Docker klonen Sie ein Repository, konfigurieren eine .env-Datei und starten das System mit docker compose up. Die Konfiguration erfolgt über .env-Variablen und Docker Volumes, optional ergänzt durch Traefik-Overrides. Updates werden durch neue Image-Tags und ein upgrade.sh-Skript (noch experimentell) durchgeführt, und Hintergrundjobs laufen in einem eigenen znuny-daemon-Container.
Im Gegensatz dazu erfordert eine klassische Installation die manuelle Einrichtung von Apache, MariaDB/PostgreSQL und Perl-Modulen auf dem Hostsystem. Die Konfiguration erfolgt über Host-Pakete, Config.pm und die SysConfig. Persistenz wird über Dateisystempfade auf dem Server gewährleistet, Updates erfolgen über Paket- oder Tar-Upgrades mit Konsolen-Migrationen, und Hintergrundjobs werden traditionell über Cron.sh oder systemd verwaltet. Der offizielle Support für Docker ist derzeit noch experimentell, während die klassische Installation umfassend dokumentiert ist.

Quellen:

• Znuny Docker – offizieller Stack, Compose & Befehle
• Znuny Dokumentation