Docker Stack Traefik - Versionsgeschichte

Thomas.will am 27. Juni 2026 um 16:26 Uhr

2026-06-27T16:26:10Z

Änderungen zeigen

Thomas.will: Die Seite wurde geleert.

2026-06-27T16:25:41Z

Die Seite wurde geleert.

Thomas.will am 27. Juni 2026 um 16:21 Uhr

2026-06-27T16:21:38Z

Änderungen zeigen

Thomas.will am 27. Juni 2026 um 16:13 Uhr

2026-06-27T16:13:18Z

Änderungen zeigen

Thomas.will: Die Seite wurde neu angelegt: „Dieser Artikel beschreibt einen kompletten Docker-Compose-Stack mit '''Traefik''' als Reverse-Proxy, einer gemeinsamen '''MariaDB''' und den beiden Webanwendun…“

2026-06-27T16:06:46Z

Die Seite wurde neu angelegt: „Dieser Artikel beschreibt einen kompletten Docker-Compose-Stack mit '''Traefik''' als Reverse-Proxy, einer gemeinsamen '''MariaDB''' und den beiden Webanwendun…“

Neue Seite

Dieser Artikel beschreibt einen kompletten Docker-Compose-Stack mit '''Traefik''' als Reverse-Proxy, einer gemeinsamen '''MariaDB''' und den beiden Webanwendungen '''Nextcloud''' und '''MediaWiki'''. Traefik erkennt die Container automatisch über Labels und terminiert TLS mit einem statischen Wildcard-Zertifikat.

==Konzept==

; Traefik als Reverse-Proxy
* Im Gegensatz zu HAProxy werden die Backends nicht von Hand konfiguriert. Traefik liest die Docker-Labels der Container und erzeugt Router und Services dynamisch.

; Statisches Zertifikat
* Im Lab gibt es kein ACME/Let's-Encrypt nach außen. Das Wildcard-Zertifikat liegt unter <code>/etc/ssl/own.crt</code> und <code>/etc/ssl/own.key</code> und wird per File-Provider als Default registriert.

; Eine Datenbank für beide Apps
* Ein gemeinsamer MariaDB-Container hält zwei getrennte Datenbanken (<code>nextcloud</code> und <code>mediawiki</code>) mit jeweils eigenem Benutzer.

==Verzeichnisstruktur==

<pre>
docker-stack/
├── docker-compose.yml
├── traefik/
│ └── dynamic/
│ └── tls.yml
└── db-init/
└── 01-init.sql
</pre>

==docker-compose.yml==

<syntaxhighlight lang="yaml">
services:

# Traefik - Reverse Proxy (statisches Wildcard-Cert)
traefik:
image: traefik:v3.3
container_name: traefik
restart: unless-stopped
command:
- "--providers.docker=true"
- "--providers.docker.exposedbydefault=false"
- "--providers.file.directory=/etc/traefik/dynamic"
- "--providers.file.watch=true"
- "--entrypoints.web.address=:80"
- "--entrypoints.websecure.address=:443"
- "--entrypoints.web.http.redirections.entrypoint.to=websecure"
- "--entrypoints.web.http.redirections.entrypoint.scheme=https"
ports:
- "80:80"
- "443:443"
volumes:
- "/var/run/docker.sock:/var/run/docker.sock:ro"
- "./traefik/dynamic:/etc/traefik/dynamic:ro"
- "/etc/ssl/own.crt:/etc/ssl/own.crt:ro"
- "/etc/ssl/own.key:/etc/ssl/own.key:ro"
networks:
- proxy

# MariaDB - gemeinsame DB fuer Nextcloud + MediaWiki
db:
image: mariadb:11
container_name: db
restart: unless-stopped
command: --transaction-isolation=READ-COMMITTED --binlog-format=ROW
environment:
MARIADB_ROOT_PASSWORD: rootpass
MARIADB_AUTO_UPGRADE: "1"
volumes:
- db_data:/var/lib/mysql
- ./db-init:/docker-entrypoint-initdb.d:ro
networks:
- backend

# Nextcloud
nextcloud:
image: nextcloud:30-apache
container_name: nextcloud
restart: unless-stopped
depends_on:
- db
environment:
MYSQL_HOST: db
MYSQL_DATABASE: nextcloud
MYSQL_USER: nextcloud
MYSQL_PASSWORD: nextcloudpass
NEXTCLOUD_ADMIN_USER: admin
NEXTCLOUD_ADMIN_PASSWORD: adminpass
NEXTCLOUD_TRUSTED_DOMAINS: cloud.it2XX.xinmen.de.int
OVERWRITEPROTOCOL: https
volumes:
- nextcloud_data:/var/www/html
networks:
- proxy
- backend
labels:
- "traefik.enable=true"
- "traefik.http.routers.nextcloud.rule=Host(`cloud.it2XX.xinmen.de.int`)"
- "traefik.http.routers.nextcloud.entrypoints=websecure"
- "traefik.http.routers.nextcloud.tls=true"
- "traefik.http.services.nextcloud.loadbalancer.server.port=80"
- "traefik.http.middlewares.nc-dav.redirectregex.regex=https://([^/]*)/.well-known/(card|cal)dav"
- "traefik.http.middlewares.nc-dav.redirectregex.replacement=https://$${1}/remote.php/dav/"
- "traefik.http.routers.nextcloud.middlewares=nc-dav"

# MediaWiki
mediawiki:
image: mediawiki:1.43
container_name: mediawiki
restart: unless-stopped
depends_on:
- db
volumes:
- mediawiki_data:/var/www/html/images
# LocalSettings.php nach dem Setup einhaengen:
# - ./LocalSettings.php:/var/www/html/LocalSettings.php:ro
networks:
- proxy
- backend
labels:
- "traefik.enable=true"
- "traefik.http.routers.mediawiki.rule=Host(`wiki.it2XX.xinmen.de.int`)"
- "traefik.http.routers.mediawiki.entrypoints=websecure"
- "traefik.http.routers.mediawiki.tls=true"
- "traefik.http.services.mediawiki.loadbalancer.server.port=80"

networks:
proxy:
backend:

volumes:
db_data:
nextcloud_data:
mediawiki_data:
</syntaxhighlight>

==Erklärung der Bausteine==

===Traefik===

; Docker-Provider mit Opt-in
* <code>exposedbydefault=false</code> sorgt dafür, dass nur Container mit <code>traefik.enable=true</code> veröffentlicht werden. Alles andere bleibt unsichtbar.

; File-Provider für TLS
* Das statische Zertifikat wird nicht über Labels, sondern über eine Datei eingebunden (siehe <code>tls.yml</code>). <code>watch=true</code> lädt Änderungen ohne Neustart.

; HTTP→HTTPS-Redirect global
* Die beiden <code>redirections</code>-Zeilen leiten den gesamten Port-80-Verkehr auf HTTPS um. Das muss kein Container selbst regeln.

; Docker-Socket read-only
* Traefik liest die Container-Labels über den Docker-Socket. Der wird '''read-only''' gemountet.

===MariaDB===

; Gemeinsame Datenbank
* Ein Container, zwei Datenbanken. Die Anlage übernimmt das Init-Skript (siehe unten), das beim ersten Start automatisch ausgeführt wird.

; Transaction-Isolation
* <code>READ-COMMITTED</code> und <code>binlog-format=ROW</code> sind die von Nextcloud empfohlenen Einstellungen.

===Netze===

; Zwei Netze trennen Front und Back
* <code>proxy</code> verbindet Traefik mit den Webanwendungen. <code>backend</code> verbindet die Webanwendungen mit der Datenbank. Die DB hängt '''nicht''' am Proxy-Netz und ist damit von außen nicht erreichbar.

==Traefik Dynamic Config (tls.yml)==

Pfad im Container: <code>/etc/traefik/dynamic/tls.yml</code>

<syntaxhighlight lang="yaml">
tls:
certificates:
- certFile: /etc/ssl/own.crt
keyFile: /etc/ssl/own.key
stores:
default:
defaultCertificate:
certFile: /etc/ssl/own.crt
keyFile: /etc/ssl/own.key
</syntaxhighlight>

; Default-Zertifikat
* Durch das <code>default</code>-Store reicht an jedem Router ein einfaches <code>tls=true</code>. Traefik greift automatisch auf dieses Zertifikat zurück, ein eigener Cert-Verweis pro Router entfällt.

==Datenbank-Init (01-init.sql)==

Pfad: <code>./db-init/01-init.sql</code> – wird beim '''ersten''' Start von MariaDB automatisch ausgeführt.

<syntaxhighlight lang="sql">
CREATE DATABASE IF NOT EXISTS nextcloud
CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;
CREATE USER IF NOT EXISTS 'nextcloud'@'%' IDENTIFIED BY 'nextcloudpass';
GRANT ALL PRIVILEGES ON nextcloud.* TO 'nextcloud'@'%';

CREATE DATABASE IF NOT EXISTS mediawiki
CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;
CREATE USER IF NOT EXISTS 'mediawiki'@'%' IDENTIFIED BY 'mediawikipass';
GRANT ALL PRIVILEGES ON mediawiki.* TO 'mediawiki'@'%';

FLUSH PRIVILEGES;
</syntaxhighlight>

; Nur beim ersten Start
* Das Init-Verzeichnis wird nur ausgeführt, solange das Datenverzeichnis <code>db_data</code> leer ist. Bei einem späteren Lauf muss man die Datenbanken von Hand anlegen oder das Volume löschen.

==Inbetriebnahme==

; Zertifikat ablegen
* Das Wildcard-Zertifikat zur Domain mit dem vorhandenen Skript ziehen, sodass <code>/etc/ssl/own.crt</code> und <code>/etc/ssl/own.key</code> vorhanden sind.
* <code>./get-cert.sh</code>

; Stack starten
* <code>docker compose up -d</code>

; Status prüfen
* <code>docker compose ps</code>

; Logs verfolgen
* <code>docker compose logs -f traefik</code>

==DNS==

Die beiden Hostnamen müssen auf den Docker-Host zeigen:

; Nextcloud
* <code>cloud.it2XX.xinmen.de.int</code>

; MediaWiki
* <code>wiki.it2XX.xinmen.de.int</code>

==MediaWiki-Setup abschließen==

; Erstaufruf im Browser
* MediaWiki startet ohne <code>LocalSettings.php</code> mit dem Web-Installer. Als Datenbank-Host <code>db</code>, Datenbank <code>mediawiki</code>, Benutzer <code>mediawiki</code> angeben.

; LocalSettings.php einhängen
* Nach dem Setup wird die generierte <code>LocalSettings.php</code> heruntergeladen, neben das Compose-File gelegt und der auskommentierte Volume-Mount im <code>mediawiki</code>-Service aktiviert. Danach Container neu starten.
* <code>docker compose up -d mediawiki</code>

← Nächstältere Version		Version vom 27. Juni 2026, 16:25 Uhr
Zeile 1:		Zeile 1:
−	Dieser Artikel baut auf dem [[Docker-Stack-Traefik\|Docker-Stack mit Traefik]] auf und integriert ihn in das SIEM. Der Wazuh-Agent läuft dabei auf dem '''Docker-Host''', nicht in den Containern. Drei Telemetriequellen werden eingebunden: Docker-Engine-Events, die Anwendungslogs und Datei-Integritätsüberwachung auf den Volumes.

−	~~==Konzept==~~
−
−	~~; Agent auf dem Host~~
−	* Der Wazuh-Agent wird auf dem Docker-Host installiert. Über das <code>docker-listener</code>-Modul liest er die Events der Docker-Engine direkt vom Socket.
−
−	~~; Was im SIEM ankommt~~
−	* Container start, stop und die
−	* Image-Pulls
−	* <code>docker exec</code> in laufende Container (jemand klettert in den Container)
−	* Netzwerk- und Volume-Events
−
−	~~; Drei Quellen~~
−	* Engine-Events (docker-listener), Anwendungslogs (Traefik, Nextcloud, MediaWiki) und FIM auf den Daten-Volumes.
−
−	~~==Voraussetzung: Python-Modul docker==~~
−
−	~~Das <code>docker-listener</code>-Modul benötigt das Python-<code>docker</code>-SDK in der '''Wazuh-eigenen''' Python-Umgebung. Ohne dieses Modul startet der Listener still nicht.~~
−
−	~~; SDK in die Wazuh-Python-Umgebung installieren~~
−	* <code>/var/ossec/framework/python/bin/pip3 install docker</code>
−
−	~~; Installation prüfen~~
−	* <code>/var/ossec/framework/python/bin/pip3 show docker</code>
−
−	~~==Agent-Konfiguration (ossec.conf)==~~
−
−	~~Der folgende Block kommt in die <code>/var/ossec/etc/ossec.conf</code> des Agents auf dem Docker-Host.~~
−
−	~~===docker-listener aktivieren===~~
−
−	~~<syntaxhighlight lang="xml">~~
−	~~<wodle name="docker-listener">~~
−	~~<interval>10m</interval>~~
−	~~<attempts>5</attempts>~~
−	~~<run_on_start>yes</run_on_start>~~
−	~~<disabled>no</disabled>~~
−	~~</wodle>~~
−	~~</syntaxhighlight>~~
−
−	~~; interval / attempts~~
−	* Der Listener verbindet sich beim Start mit dem Docker-Socket. <code>attempts</code> regelt, wie oft er es bei Nichterreichbarkeit erneut versucht.
−
−	~~; run_on_start~~
−	* Startet das Modul direkt beim Hochfahren des Agents, nicht erst nach dem ersten Intervall.
−
−	~~===Anwendungslogs einsammeln===~~
−
−	Die Container loggen auf <code>stdout</code>. Bei json-file-Logtreiber liegen die Logs auf dem Host und können direkt als Datei eingelesen werden. Einfacher und stabiler ist es, die relevanten Anwendungslogs auf ein gemountetes Verzeichnis zu schreiben und dieses zu überwachen.
−
−	~~<syntaxhighlight lang="xml">~~
−	~~<localfile>~~
−	~~<log_format>json</log_format>~~
−	~~<location>/var/lib/docker/containers//-json.log</location>~~
−	~~</localfile>~~
−	~~</syntaxhighlight>~~
−
−	~~; json-Logtreiber~~
−	* Docker schreibt pro Container eine <code>*-json.log</code>. Wazuh kann diese als <code>json</code> einlesen und die Felder direkt auswerten.
−
−	~~==FIM auf den Volumes==~~
−
−	~~Datei-Integritätsüberwachung auf den Daten-Volumes der Anwendungen. Veränderungen an hochgeladenen Dateien oder an der Wiki-Konfiguration lösen ein FIM-Event aus (Rule 554 bei neuen Dateien).~~
−
−	~~<syntaxhighlight lang="xml">~~
−	~~<syscheck>~~
−	~~<directories check_all="yes" realtime="yes">/var/lib/docker/volumes/docker-stack_nextcloud_data/_data/data</directories>~~
−	~~<directories check_all="yes" realtime="yes">/var/lib/docker/volumes/docker-stack_mediawiki_data/_data</directories>~~
−	~~</syscheck>~~
−	~~</syntaxhighlight>~~
−
−	~~; realtime~~
−	* <code>realtime="yes"</code> meldet Änderungen sofort über inotify, statt erst beim nächsten Scan-Durchlauf.
−
−	~~; Volume-Pfade~~
−	* Die genauen Pfade hängen vom Compose-Projektnamen ab (Präfix des Verzeichnisses). Mit dem folgenden Befehl ermitteln.
−	* <code>docker volume inspect docker-stack_nextcloud_data</code>
−
−	~~==Kompletter ossec.conf-Block==~~
−
−	Alle drei Bausteine (docker-listener, Anwendungslogs, FIM) am Stück zum Einfügen in die <code>/var/ossec/etc/ossec.conf</code> des Agents auf dem Docker-Host. Die Volume-Pfade ggf. an den eigenen Compose-Projektnamen anpassen.
−
−	~~<syntaxhighlight lang="xml">~~
−	~~<wodle name="docker-listener">~~
−	~~<interval>10m</interval>~~
−	~~<attempts>5</attempts>~~
−	~~<run_on_start>yes</run_on_start>~~
−	~~<disabled>no</disabled>~~
−	~~</wodle>~~
−
−	~~<localfile>~~
−	~~<log_format>json</log_format>~~
−	~~<location>/var/lib/docker/containers//-json.log</location>~~
−	~~</localfile>~~
−
−	~~<syscheck>~~
−	~~<directories check_all="yes" realtime="yes">/var/lib/docker/volumes/docker-stack_nextcloud_data/_data/data</directories>~~
−	~~<directories check_all="yes" realtime="yes">/var/lib/docker/volumes/docker-stack_mediawiki_data/_data</directories>~~
−	~~</syscheck>~~
−	~~</syntaxhighlight>~~
−
−	~~==Agent neu starten==~~
−
−	~~<syntaxhighlight lang="bash">~~
−	~~systemctl restart wazuh-agent~~
−	~~</syntaxhighlight>~~
−
−	~~==Funktionsprüfung==~~
−
−	~~===Modul-Status im Agent-Log===~~
−
−	~~; ossec.log auf dem Agent prüfen~~
−	* <code>tail -f /var/ossec/logs/ossec.log</code>
−
−	~~; Auf docker-listener-Meldungen achten~~
−	* <code>grep docker-listener /var/ossec/logs/ossec.log</code>
−
−	~~Erscheint hier eine Meldung über ein fehlendes Python-Modul, wurde das <code>docker</code>-SDK nicht in die Wazuh-Python-Umgebung installiert (siehe oben).~~
−
−	~~===Event auslösen===~~
−
−	~~; Test-Container starten und wieder entfernen~~
−	* <code>docker run --rm hello-world</code>
−
−	~~; In einen laufenden Container klettern~~
−	* <code>docker exec -it nextcloud sh</code>
−
−	~~===Im Manager prüfen===~~
−
−	~~; archives.json mitlesen (alle Events)~~
−	* <code>tail -f /var/ossec/logs/archives/archives.json</code>
−
−	~~; alerts.json mitlesen (nur Alerts)~~
−	* <code>tail -f /var/ossec/logs/alerts/alerts.json</code>
−
−	Die Docker-Events erscheinen mit dem Decoder <code>docker</code>. Das <code>docker exec</code> ist didaktisch der interessanteste Fall: Es zeigt, dass ein Eindringen in einen laufenden Container im SIEM sichtbar wird.
−
−	~~==Hinweis zum Datenfluss==~~
−
−	~~; Engine-Events vs. Anwendungslogs~~
−	* Der docker-listener meldet, '''dass''' ein Container gestartet oder betreten wurde – nicht, was innerhalb der Anwendung passiert. Für Angriffe auf die Webanwendung (z.B. gegen MediaWiki oder Nextcloud) liefern die Anwendungslogs und FIM die Telemetrie.
−
−	~~; Zusammenspiel~~
−	* Erst die Kombination macht das Bild vollständig: Engine-Ebene (Container-Lifecycle), Anwendungs-Ebene (Logs) und Datei-Ebene (FIM).