Thomas.will: /* Container mit Docker: Caddy, Uptime Kuma und HedgeDoc */

2026-10-20T18:06:49Z

Container mit Docker: Caddy, Uptime Kuma und HedgeDoc

← Nächstältere Version		Version vom 20. Oktober 2026, 18:06 Uhr
Zeile 25:		Zeile 25:
	== Container mit Docker: Caddy, Uptime Kuma und HedgeDoc ==		== Container mit Docker: Caddy, Uptime Kuma und HedgeDoc ==

	Auf dem Server '''~~caddy~~.it2XX.xinmen.de''' laufen Dienste als Docker-Container.		Auf dem Server '''docker.it2XX.xinmen.de''' laufen Dienste als Docker-Container.
	Als praktisches Beispiel dienen drei Dienste: Caddy (Reverse Proxy), Uptime Kuma		Als praktisches Beispiel dienen drei Dienste: Caddy (Reverse Proxy), Uptime Kuma
	(Monitoring) und HedgeDoc (kollaborative Notizen). Jeder Dienst bekommt sein		(Monitoring) und HedgeDoc (kollaborative Notizen). Jeder Dienst bekommt sein

Thomas.will: /* Grundkonfiguration */

2026-10-20T18:06:25Z

Grundkonfiguration

@@ Zeile 22: / Zeile 22: @@
 *reboot
 *get-cert.sh
 == Container mit Docker: Caddy, Uptime Kuma und HedgeDoc ==

Thomas.will: /* DATEN */

2026-10-20T18:06:07Z

DATEN

← Nächstältere Version		Version vom 20. Oktober 2026, 18:06 Uhr
Zeile 4:		Zeile 4:
	! Parameter !! Wert !! Erläuterung		! Parameter !! Wert !! Erläuterung
	\|-		\|-
	\| '''Server''' \|\| ~~container~~ \|\| Debian-Server, Grundkonfiguration per Skript		\| '''Server''' \|\| docker \|\| Debian-Server, Grundkonfiguration per Skript
	\|-		\|-
	\| '''Betriebssystem''' \|\| Debian 13 \|\|		\| '''Betriebssystem''' \|\| Debian 13 \|\|
	\|-		\|-
	\| '''FQDN''' \|\| ~~container~~.it2XX.xinmen.de \|\| Fully Qualified Domain Name		\| '''FQDN''' \|\| docker.it2XX.xinmen.de \|\| Fully Qualified Domain Name
	\|-		\|-
	\| '''DOM''' \|\| it2XX.xinmen.de \|\| Domain Name		\| '''DOM''' \|\| it2XX.xinmen.de \|\| Domain Name
Zeile 19:		Zeile 19:
	\|}		\|}
	====Skript====		====Skript====
	*debian-setup.sh -h ~~caddy~~.it2XX.xinmen.de -a 10.88.2XX.21/24 -g 10.88.2XX.1 -n 9.9.9.9		*debian-setup.sh -h docker.it2XX.xinmen.de -a 10.88.2XX.9/24 -g 10.88.2XX.1 -n 9.9.9.9
	*reboot		*reboot
	*get-cert.sh		*get-cert.sh

Thomas.will: /* DATEN */

2026-10-20T17:57:39Z

DATEN

← Nächstältere Version		Version vom 20. Oktober 2026, 17:57 Uhr
Zeile 20:		Zeile 20:
	====Skript====		====Skript====
	*debian-setup.sh -h caddy.it2XX.xinmen.de -a 10.88.2XX.21/24 -g 10.88.2XX.1 -n 9.9.9.9		*debian-setup.sh -h caddy.it2XX.xinmen.de -a 10.88.2XX.21/24 -g 10.88.2XX.1 -n 9.9.9.9
			*reboot
			*get-cert.sh

	=== Grundkonfiguration ===		=== Grundkonfiguration ===

Thomas.will: /* DATEN */

2026-10-20T17:56:57Z

DATEN

← Nächstältere Version		Version vom 20. Oktober 2026, 17:56 Uhr
Zeile 4:		Zeile 4:
	! Parameter !! Wert !! Erläuterung		! Parameter !! Wert !! Erläuterung
	\|-		\|-
	\| '''Server''' \|\| ~~caddy~~ \|\| Debian-Server, Grundkonfiguration per Skript		\| '''Server''' \|\| container \|\| Debian-Server, Grundkonfiguration per Skript
	\|-		\|-
	\| '''Betriebssystem''' \|\| Debian 13 \|\|		\| '''Betriebssystem''' \|\| Debian 13 \|\|
	\|-		\|-
	\| '''FQDN''' \|\| ~~caddy~~.it2XX.xinmen.de \|\| Fully Qualified Domain Name		\| '''FQDN''' \|\| container.it2XX.xinmen.de \|\| Fully Qualified Domain Name
	\|-		\|-
	\| '''DOM''' \|\| it2XX.xinmen.de \|\| Domain Name		\| '''DOM''' \|\| it2XX.xinmen.de \|\| Domain Name
Zeile 18:		Zeile 18:
	\| '''IP, GW, NS''' \|\| per Skript \|\| werden von der Grundkonfiguration gesetzt		\| '''IP, GW, NS''' \|\| per Skript \|\| werden von der Grundkonfiguration gesetzt
	\|}		\|}
			====Skript====
			*debian-setup.sh -h caddy.it2XX.xinmen.de -a 10.88.2XX.21/24 -g 10.88.2XX.1 -n 9.9.9.9

	=== Grundkonfiguration ===		=== Grundkonfiguration ===

Thomas.will: Neuer Artikel: Caddy, Uptime Kuma und HedgeDoc mit Docker auf Debian (Nachfolger von Rocky container)

2026-10-20T17:38:06Z

Neuer Artikel: Caddy, Uptime Kuma und HedgeDoc mit Docker auf Debian (Nachfolger von Rocky container)

Neue Seite

== Installation ==
=== DATEN ===
{| class="wikitable" style="background-color: #f2f2f2;"
! Parameter !! Wert !! Erläuterung
|-
| '''Server''' || caddy || Debian-Server, Grundkonfiguration per Skript
|-
| '''Betriebssystem''' || Debian 13 ||
|-
| '''FQDN''' || caddy.it2XX.xinmen.de || Fully Qualified Domain Name
|-
| '''DOM''' || it2XX.xinmen.de || Domain Name
|-
| '''Dienst 1''' || kuma.it2XX.xinmen.de || Uptime Kuma (Monitoring)
|-
| '''Dienst 2''' || hedgedoc.it2XX.xinmen.de || HedgeDoc (kollaborative Notizen)
|-
| '''IP, GW, NS''' || per Skript || werden von der Grundkonfiguration gesetzt
|}

=== Grundkonfiguration ===
Der Server wird über ein Skript vorkonfiguriert (Netzwerk, Hostname, Benutzer, Zertifikate).

;Voraussetzung im DNS
Die Namen der Dienste müssen auf den Server zeigen, z. B. als CNAME auf <code>caddy.it2XX.xinmen.de</code>:
<pre>
kuma.it2XX.xinmen.de CNAME caddy.it2XX.xinmen.de.
hedgedoc.it2XX.xinmen.de CNAME caddy.it2XX.xinmen.de.
</pre>

== Container mit Docker: Caddy, Uptime Kuma und HedgeDoc ==

Auf dem Server '''caddy.it2XX.xinmen.de''' laufen Dienste als Docker-Container.
Als praktisches Beispiel dienen drei Dienste: Caddy (Reverse Proxy), Uptime Kuma
(Monitoring) und HedgeDoc (kollaborative Notizen). Jeder Dienst bekommt sein
'''eigenes Verzeichnis mit eigener compose.yaml'''. Das entspricht der Praxis,
Container-Stacks unabhängig voneinander verwaltbar zu halten (eigenes Update,
eigenes Down/Up, ohne andere Dienste zu berühren). Verwaltet werden die Stacks
mit '''docker compose'''.

Im weiteren Verlauf des Kurses werden diese Container überwacht, z. B. mit Wazuh.
Der Aufbau ist deshalb von Anfang an so angelegt, dass Logs an festen Stellen
landen (siehe [[#Vorbereitung für die Überwachung|Vorbereitung für die Überwachung]]).

=== Was ist Docker ===

Docker ist eine Container-Engine. Ein Container ist ein normaler Linux-Prozess,
der durch Kernel-Funktionen (Namespaces, cgroups) vom Rest des Systems
abgeschottet ist und sein eigenes Dateisystem aus einem Image mitbringt.

;Aufbau
* '''dockerd''': Der Docker-Daemon läuft dauerhaft als root und verwaltet alle Container, Images, Netze und Volumes.
* '''containerd''': startet und überwacht die eigentlichen Container-Prozesse.
* '''docker''' (CLI): spricht über den Socket <code>/run/docker.sock</code> mit dem Daemon.

;Sicherheitsrelevant
* Wer auf <code>/run/docker.sock</code> zugreifen darf, hat praktisch '''root-Rechte''' auf dem Host. Mitglieder der Gruppe <code>docker</code> sind damit root-gleich.
* Der Daemon läuft als root. Ein Ausbruch aus einem Container kann deshalb beim Host-root landen, wenn der Container falsch konfiguriert ist (z. B. <code>--privileged</code>, gemounteter Docker-Socket).

;Unterschied zu Podman
Podman kommt ohne zentralen Daemon aus und läuft standardmäßig rootless. Die
Befehle sind nahezu identisch, <code>docker</code> und <code>podman</code> lassen sich meist 1:1 austauschen.

;Merksatz
Docker = ein Daemon (root) verwaltet alle Container | Zugriff auf den Docker-Socket = root

=== Docker installieren ===

Installiert wird aus dem offiziellen Docker-Repository.

;Schlüssel und Repository einrichten
*apt update
*apt install -y ca-certificates curl
*install -m 0755 -d /etc/apt/keyrings
*curl -fsSL https://download.docker.com/linux/debian/gpg -o /etc/apt/keyrings/docker.asc
*echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/debian $(. /etc/os-release && echo $VERSION_CODENAME) stable" > /etc/apt/sources.list.d/docker.list

;Docker und das Compose-Plugin installieren
*apt update
*apt install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

;Prüfen
*systemctl status docker
*docker version
*docker compose version

;Hinweis
Compose ist heute ein Plugin von Docker. Der Befehl heißt <code>docker compose</code> (mit Leerzeichen),
nicht mehr <code>docker-compose</code>.

=== Docker-Logging festlegen ===

Docker schreibt die Ausgabe jedes Containers in eine Datei unter
<code>/var/lib/docker/containers/</code>. Ohne Begrenzung wachsen diese Dateien
unbegrenzt. Die Rotation wird einmal zentral festgelegt.

;Daemon-Konfiguration anlegen
*vim /etc/docker/daemon.json

<syntaxhighlight lang="json">
{
"log-driver": "json-file",
"log-opts": {
"max-size": "10m",
"max-file": "3"
}
}
</syntaxhighlight>

;Docker neu starten
*systemctl restart docker

;Hinweis
Die Einstellung gilt für Container, die '''danach''' erstellt werden. Der Treiber
<code>json-file</code> ist wichtig für die spätere Überwachung, weil ein Agent wie
Wazuh diese Dateien direkt lesen kann.

=== Vorbereitung: Zertifikate ===

Die Zertifikate liegen bereits vor unter:
* <code>/etc/ssl/own.crt</code>
* <code>/etc/ssl/own.key</code>

Das Zertifikat muss die Namen <code>kuma.it2XX.xinmen.de</code> und <code>hedgedoc.it2XX.xinmen.de</code> enthalten
(oder ein Wildcard-Zertifikat für <code>*.it2XX.xinmen.de</code> sein).

=== Verzeichnisstruktur ===

Jeder Dienst bekommt ein eigenes Verzeichnis mit eigener Compose-Datei. Der
Dateiname ist immer '''compose.yaml''', das ist der aktuelle Standardname (der
alte Name <code>docker-compose.yml</code> funktioniert noch, wird aber nicht mehr verwendet).
<code>docker compose</code> sucht beim Aufruf automatisch nach dieser Datei im aktuellen Verzeichnis.

<pre>
/opt/docker/
├── caddy/
│ ├── compose.yaml
│ └── Caddyfile
├── uptime-kuma/
│ └── compose.yaml
└── hedgedoc/
├── compose.yaml
└── .env
</pre>

;Struktur anlegen
*mkdir -p /opt/docker/{caddy,uptime-kuma,hedgedoc}
*mkdir -p /var/log/caddy

;Merksatz
Ein Verzeichnis = ein Dienst = ein eigenständiges Compose-Projekt.

=== Wie Container sich im Netzwerk finden ===

Docker legt für jedes selbst angelegte Netzwerk ein internes DNS an. Jeder
Container ist darin unter seinem '''container_name''' erreichbar, nicht unter
<code>localhost</code> und nicht über die Host-IP.

;Merksatz
container_name = Hostname im internen Netz. Zwei Container im selben Netzwerk
erreichen sich per <code>ping container_name</code> bzw. <code>curl http://container_name:PORT</code>.

'''Wichtige Besonderheit bei getrennten Verzeichnissen:''' Jedes Compose-Projekt
legt sein eigenes, isoliertes Netzwerk an. Liegen Caddy und Uptime Kuma in
unterschiedlichen Verzeichnissen, finden sie sich '''nicht''' automatisch. Die
Lösung: Ein gemeinsames Netzwerk wird einmalig '''manuell und
projektübergreifend''' angelegt, und jede compose.yaml bindet sich als
<code>external</code> ein.

;Einmalig das gemeinsame Netzwerk anlegen
*docker network create proxy

;Prüfen
*docker network ls

<pre>
Internet / Schulungsnetz
│ 80/443
┌──────┴──────┐
│ caddy │ einziger Container mit Ports am Host
└──────┬──────┘
Netz "proxy" │
┌────────────┴────────────┐
┌──────┴──────┐ ┌──────┴──────┐
│ uptime-kuma │ │ hedgedoc │
│ :3001 │ │ :3000 │
└─────────────┘ └──────┬──────┘
internes Netz │ (nur HedgeDoc-Projekt)
┌──────┴──────┐
│ hedgedoc-db │
│ :5432 │
└─────────────┘
</pre>

=== Dienst 1: Caddy (Reverse Proxy) ===

Caddy ist der einzige Container, der Ports am Host öffnet, weil er der einzige
Kontaktpunkt von außen ist. Er terminiert TLS mit dem vorhandenen Zertifikat
und leitet intern per HTTP an die Dienste weiter.

;Compose-Datei anlegen
*vim /opt/docker/caddy/compose.yaml

<syntaxhighlight lang="yaml">
services:
caddy:
image: caddy:2
container_name: caddy
restart: unless-stopped
ports:
- "80:80"
- "443:443"
- "443:443/udp"
volumes:
- ./Caddyfile:/etc/caddy/Caddyfile:ro
- /etc/ssl/own.crt:/etc/ssl/own.crt:ro
- /etc/ssl/own.key:/etc/ssl/own.key:ro
- /var/log/caddy:/var/log/caddy
- caddy-data:/data
- caddy-config:/config
networks:
- proxy

volumes:
caddy-data:
caddy-config:

networks:
proxy:
external: true
</syntaxhighlight>

;Erklärung
* <code>restart: unless-stopped</code>: Docker startet den Container nach einem Absturz oder Neustart des Servers wieder, außer man hat ihn selbst gestoppt. Ohne diese Zeile bleibt der Dienst nach einem Reboot aus.
* <code>:ro</code>: Caddyfile und Zertifikate werden nur lesend eingebunden. Der Container kann sie nicht verändern.
* <code>443:443/udp</code>: für HTTP/3. Kann entfallen, schadet aber nicht.
* <code>/var/log/caddy</code>: Hier schreibt Caddy seine Zugriffslogs, direkt auf dem Host lesbar.

;Hinweis depends_on
Caddy und die Dienste liegen in getrennten Compose-Projekten, ein <code>depends_on</code>
zwischen ihnen gibt es deshalb nicht (das funktioniert nur innerhalb eines Projekts).
Das ist unproblematisch: Caddy versucht bei jeder Anfrage erneut, den Dienst zu erreichen.

=== Caddyfile ===

Die '''Caddyfile''' ist Caddys Konfigurationsdatei (reiner Text, kein YAML/JSON).
Sie legt pro Domain fest, welches Zertifikat benutzt wird und wohin intern
weitergeleitet wird.

;Caddyfile anlegen
*vim /opt/docker/caddy/Caddyfile

<pre>
(logging) {
log {
output file /var/log/caddy/access.log
format json
}
}

kuma.it2XX.xinmen.de {
tls /etc/ssl/own.crt /etc/ssl/own.key
import logging
reverse_proxy uptime-kuma:3001
}

hedgedoc.it2XX.xinmen.de {
tls /etc/ssl/own.crt /etc/ssl/own.key
import logging
reverse_proxy hedgedoc:3000
}
</pre>

Aufbau:
* <code>(logging) { … }</code>: ein wiederverwendbarer Baustein (Snippet). Er wird in jedem Host-Block mit <code>import logging</code> eingebunden.
* <code>log … format json</code>: Jeder Zugriff wird als eine JSON-Zeile in <code>/var/log/caddy/access.log</code> geschrieben. JSON lässt sich später von Wazuh ohne eigenen Decoder auswerten.
* <code>kuma.it2XX.xinmen.de {</code>: für welchen Hostnamen der Block gilt.
* <code>tls …</code>: welches Zertifikat und welcher Schlüssel verwendet werden.
* <code>reverse_proxy uptime-kuma:3001</code>: wohin die entschlüsselte Anfrage intern geht (container_name als DNS-Name).

;Caddyfile prüfen, bevor Caddy sie lädt
*docker run --rm -v /opt/docker/caddy/Caddyfile:/etc/caddy/Caddyfile:ro caddy:2 caddy validate --config /etc/caddy/Caddyfile --adapter caddyfile

Die Prüfung meldet einen Fehler, solange die Zertifikate nicht eingebunden sind. Alternativ nach dem Start:
*docker exec caddy caddy validate --config /etc/caddy/Caddyfile --adapter caddyfile

;Caddyfile im laufenden Betrieb neu laden
*docker exec caddy caddy reload --config /etc/caddy/Caddyfile --adapter caddyfile

=== Dienst 2: Uptime Kuma ===

Uptime Kuma braucht keinen Port am Host. Es lauscht intern auf Port '''3001''' und
wird ausschließlich über Caddy nach außen gereicht. Die Daten (SQLite-Datenbank,
Konfiguration) liegen in einem benannten Volume, damit sie Neustarts und Updates überleben.

;Compose-Datei anlegen
*vim /opt/docker/uptime-kuma/compose.yaml

<syntaxhighlight lang="yaml">
services:
uptime-kuma:
image: louislam/uptime-kuma:1
container_name: uptime-kuma
restart: unless-stopped
volumes:
- uptime-kuma-data:/app/data
networks:
- proxy

volumes:
uptime-kuma-data:

networks:
proxy:
external: true
</syntaxhighlight>

;Wichtig
Kein <code>ports:</code>-Eintrag. Ein Dienst, der nur von Caddy angesprochen wird,
muss nicht am Host offen sein. Ein offener Port wäre sogar ein unnötiges Risiko:
Er läge ungeschützt ohne TLS am Netz.

;Achtung Docker und Firewall
Ports, die mit <code>ports:</code> veröffentlicht werden, trägt Docker selbst in die
Paketfilter-Regeln ein. Sie sind dann von außen erreichbar, '''auch wenn eine
Host-Firewall''' (nftables, ufw) den Port eigentlich sperrt. Deshalb nur dort Ports
veröffentlichen, wo es wirklich nötig ist: hier nur bei Caddy.

=== Dienst 3: HedgeDoc mit Datenbank ===

HedgeDoc braucht eine Datenbank. Sie läuft als zweiter Container im selben
Compose-Projekt. Die Datenbank hängt '''nur''' im internen Netz des Projekts,
HedgeDoc zusätzlich im Netz <code>proxy</code>. Caddy erreicht so HedgeDoc, aber
niemals die Datenbank.

;Passwort in eine eigene Datei
*vim /opt/docker/hedgedoc/.env

<pre>
DB_PASSWORD=EinLangesPasswortHierEintragen
</pre>

*chmod 600 /opt/docker/hedgedoc/.env

;Compose-Datei anlegen
*vim /opt/docker/hedgedoc/compose.yaml

<syntaxhighlight lang="yaml">
services:
database:
image: postgres:16-alpine
container_name: hedgedoc-db
restart: unless-stopped
environment:
- POSTGRES_USER=hedgedoc
- POSTGRES_PASSWORD=${DB_PASSWORD}
- POSTGRES_DB=hedgedoc
volumes:
- hedgedoc-db:/var/lib/postgresql/data
networks:
- intern

hedgedoc:
image: quay.io/hedgedoc/hedgedoc:1.10.0
container_name: hedgedoc
restart: unless-stopped
environment:
- CMD_DB_URL=postgres://hedgedoc:${DB_PASSWORD}@hedgedoc-db:5432/hedgedoc
- CMD_DOMAIN=hedgedoc.it2XX.xinmen.de
- CMD_PROTOCOL_USESSL=true
- CMD_URL_ADDPORT=false
volumes:
- hedgedoc-uploads:/hedgedoc/public/uploads
depends_on:
- database
networks:
- intern
- proxy

volumes:
hedgedoc-db:
hedgedoc-uploads:

networks:
intern:
proxy:
external: true
</syntaxhighlight>

;Erklärung
* <code>.env</code>: <code>docker compose</code> liest diese Datei im Projektverzeichnis automatisch. <code>${DB_PASSWORD}</code> wird beim Start ersetzt. Das Passwort steht so nicht in der compose.yaml.
* <code>networks: intern</code>: wird vom Projekt selbst angelegt (ohne <code>external</code>). Nur die beiden HedgeDoc-Container hängen darin.
* <code>depends_on</code>: Innerhalb desselben Projekts funktioniert es. Die Datenbank wird vor HedgeDoc gestartet.

;Hinweis Reverse-Proxy-Variablen
HedgeDoc muss wissen, unter welcher URL es von außen erreichbar ist. Sonst erzeugt
es Links auf CSS und JavaScript mit falscher Adresse und die Seite erscheint ohne Styling:
* <code>CMD_DOMAIN</code>: externer Hostname
* <code>CMD_PROTOCOL_USESSL=true</code>: Links als https:// erzeugen, obwohl HedgeDoc intern nur HTTP spricht (TLS macht Caddy)
* <code>CMD_URL_ADDPORT=false</code>: keinen Port an die URLs hängen

;Merksatz
Ein neuer Dienst braucht vier Dinge: eigenes Verzeichnis, eigener container_name,
Anbindung an das Netz <code>proxy</code> mit <code>external: true</code>, eigener Host-Block
in der Caddyfile mit <code>container_name:Port</code>. Nach außen offen sind immer nur 80/443 bei Caddy.

=== Starten und Stoppen ===

Jeder Dienst wird aus seinem eigenen Verzeichnis gestartet. Die Reihenfolge ist
egal, solange das Netzwerk <code>proxy</code> existiert.

;Dienste starten
*cd /opt/docker/uptime-kuma && docker compose up -d
*cd /opt/docker/hedgedoc && docker compose up -d
*cd /opt/docker/caddy && docker compose up -d

;Status prüfen
*docker ps

;Einzelnen Dienst stoppen
*cd /opt/docker/caddy && docker compose down

=== Test ===

;Aufruf im Browser
<pre>
https://kuma.it2XX.xinmen.de
https://hedgedoc.it2XX.xinmen.de
</pre>

Beim ersten Aufruf fragt Uptime Kuma nach einem Admin-Account. Danach lassen sich
Monitore anlegen (Ping, TCP-Port, HTTP), z. B. für <code>https://hedgedoc.it2XX.xinmen.de</code>.

;Zugriffslog ansehen
*tail -f /var/log/caddy/access.log

;Nur die wichtigsten Felder (mit jq)
*apt install -y jq
*tail -f /var/log/caddy/access.log | jq -c '{ts, ip: .request.remote_ip, host: .request.host, uri: .request.uri, status}'

== Vorbereitung für die Überwachung ==

Im weiteren Kurs werden die Container überwacht, z. B. mit einem Wazuh-Agenten
auf diesem Server. Diese Quellen sind dafür interessant:

{| class="wikitable"
! Quelle !! Wo !! Was steht drin
|-
| Caddy-Zugriffslog || <code>/var/log/caddy/access.log</code> || jeder HTTP-Zugriff als JSON: Quell-IP, Host, URL, Statuscode, User-Agent
|-
| Container-Ausgaben || <code>/var/lib/docker/containers/*/*-json.log</code> || stdout und stderr jedes Containers, z. B. Fehlermeldungen von HedgeDoc oder der Datenbank
|-
| Docker-Ereignisse || <code>docker events</code> || Container gestartet, gestoppt, gelöscht, Image gezogen, <code>docker exec</code> ausgeführt
|-
| Docker-Daemon || <code>journalctl -u docker</code> || Meldungen des Daemons selbst
|-
| Dateien und Socket || <code>/etc/docker</code>, <code>/run/docker.sock</code>, <code>/opt/docker</code> || Änderungen an Konfiguration und compose-Dateien, Zugriffe auf den Socket (auditd)
|}

;Docker-Ereignisse live ansehen
*docker events

In einem zweiten Terminal z. B. <code>docker exec -it caddy sh</code> ausführen: Im ersten Terminal
erscheint ein <code>exec_create</code>- und <code>exec_start</code>-Ereignis. Genau solche Ereignisse sind für die Überwachung
interessant, weil ein Angreifer oder ein neugieriger Admin so in einen Container gelangt.

;Merksatz
Was überwacht werden soll, muss zuerst an einer festen Stelle protokolliert werden:
Caddy schreibt nach <code>/var/log/caddy</code>, Docker nach <code>/var/lib/docker/containers</code>, Ereignisse liefert <code>docker events</code>.

== Cheat Sheet: Docker und docker compose ==

=== Container ===

;Laufende Container anzeigen
*docker ps

;Alle Container anzeigen (auch gestoppte)
*docker ps -a

;Logs eines Containers anzeigen
*docker logs caddy

;Logs live mitverfolgen (wie tail -f)
*docker logs -f uptime-kuma

;Nur die letzten 50 Zeilen
*docker logs --tail 50 hedgedoc

;Shell im laufenden Container öffnen
*docker exec -it caddy sh

;Einzelnen Befehl im Container ausführen
*docker exec caddy cat /etc/caddy/Caddyfile

;Container neu starten
*docker restart caddy

;Container stoppen / starten
*docker stop caddy
*docker start caddy

;Details zu einem Container (IP, Mounts, Umgebungsvariablen)
*docker inspect uptime-kuma

;Wo liegt die Logdatei eines Containers
*docker inspect --format '{{.LogPath}}' caddy

;Ressourcenverbrauch live anzeigen
*docker stats

=== Images ===

;Lokale Images anzeigen
*docker images

;Image aktualisieren (neue Version ziehen)
*docker pull louislam/uptime-kuma:1

;Ungenutzte Images aufräumen
*docker image prune

=== Netzwerke und Volumes ===

;Netzwerke anzeigen
*docker network ls

;Details zu einem Netzwerk (welche Container hängen drin, IPs)
*docker network inspect proxy

;Volumes anzeigen
*docker volume ls

;Wo liegt ein Volume auf dem Host
*docker volume inspect uptime-kuma_uptime-kuma-data

;Hinweis
docker compose stellt Volume-Namen den Projektnamen voran, also dem Verzeichnisnamen:
aus <code>uptime-kuma-data</code> im Verzeichnis <code>uptime-kuma</code> wird <code>uptime-kuma_uptime-kuma-data</code>.

=== docker compose (im jeweiligen Dienst-Verzeichnis) ===

;Stack starten (im Hintergrund)
*docker compose up -d

;Stack stoppen und Container entfernen (Volumes bleiben erhalten)
*docker compose down

;Status der Container dieses Projekts
*docker compose ps

;Logs aller Container dieses Projekts
*docker compose logs

;Logs live mitverfolgen
*docker compose logs -f

;Dienst aktualisieren (neues Image ziehen, dann neu erstellen)
*docker compose pull
*docker compose up -d

;Fertige Konfiguration anzeigen (mit eingesetzten Variablen aus .env)
*docker compose config

=== Troubleshooting-Reihenfolge ===

Wenn ein Dienst nicht erreichbar ist, immer in dieser Reihenfolge prüfen:

# Läuft der Container überhaupt? → <code>docker ps</code>
# Was sagen die Logs? → <code>docker logs -f containername</code>
# Hängt er im richtigen Netz? → <code>docker network inspect proxy</code>
# Ist der Dienst intern erreichbar? → <code>docker exec -it caddy sh</code>, dann <code>wget -O- http://uptime-kuma:3001</code>
# Stimmt die Caddyfile? → <code>docker exec caddy caddy validate --config /etc/caddy/Caddyfile --adapter caddyfile</code>
# Kommt die Anfrage bei Caddy an? → <code>tail -f /var/log/caddy/access.log</code>
# Zeigt der Name auf den Server? → <code>host kuma.it2XX.xinmen.de</code>

;Merksatz
docker logs -f = erste Anlaufstelle bei jedem Problem | docker exec -it NAME sh =
das Problem von innen ansehen | docker network inspect = wer hängt wirklich in welchem Netz

=== Merksatz (Zusammenfassung) ===
docker compose = ein YAML-File statt mehrerer docker-run-Befehle | getrenntes
Verzeichnis pro Dienst = unabhängige Compose-Projekte | gemeinsames Netz einmalig
anlegen und in jeder compose.yaml als external einbinden | container_name = DNS-Name
im internen Netz | nur Caddy veröffentlicht Ports | restart: unless-stopped, sonst
bleibt der Dienst nach dem Reboot aus | Logs an feste Stellen schreiben, damit sie
später überwacht werden können

Docker Caddy - Versionsgeschichte

Thomas.will: /* Container mit Docker: Caddy, Uptime Kuma und HedgeDoc */

Thomas.will: /* Grundkonfiguration */

Thomas.will: /* DATEN */

Thomas.will: /* DATEN */

Thomas.will: /* DATEN */

Thomas.will: Neuer Artikel: Caddy, Uptime Kuma und HedgeDoc mit Docker auf Debian (Nachfolger von Rocky container)