Rocky container: Unterschied zwischen den Versionen

Aus Xinux Wiki
Zur Navigation springen Zur Suche springen
(Die Seite wurde neu angelegt: „== Podman-Goodie: Monitoring mit Uptime Kuma und Caddy (container.it2XX.int) == Als Ausblick nach der klassischen Systemadministration wird auf der Maschine '…“)
 
Zeile 1: Zeile 1:
== Podman-Goodie: Monitoring mit Uptime Kuma und Caddy (container.it2XX.int) ==
+
== Monitoring mit Uptime Kuma und Caddy (container.it2XX.int) ==
  
 
Als Ausblick nach der klassischen Systemadministration wird auf der
 
Als Ausblick nach der klassischen Systemadministration wird auf der

Version vom 4. Juli 2026, 09:29 Uhr

Monitoring mit Uptime Kuma und Caddy (container.it2XX.int)

Als Ausblick nach der klassischen Systemadministration wird auf der Maschine container.it2XX.int ein kleines Container-Setup gezeigt: Uptime Kuma als Monitoring-Tool, davor Caddy als Reverse Proxy. Beide laufen als Podman-Container, verwaltet über podman-compose.

Was ist Podman

Podman ist eine Container-Engine, kompatibel zur Docker-CLI, aber ohne zentralen Root-Daemon.

Wichtigste Unterschiede zu Docker
  • Daemonless: Docker braucht einen dauerhaft laufenden Root-Daemon
 (dockerd). Fällt er aus oder wird kompromittiert, sind alle Container
 betroffen. Podman startet Container als direkte Kindprozesse ohne
 zentralen Daemon.
  • Rootless by Default: Podman-Container laufen standardmäßig ohne
 Root-Rechte. Ein Escape aus dem Container landet nicht automatisch
 bei Root auf dem Host.
  • Systemd-Integration: Podman-Container lassen sich nativ als
 systemd-Units verwalten (Quadlets), passt gut in RHEL/Rocky-Abläufe.
Merksatz

Docker = ein Daemon regiert alle Container (meist als Root) | Podman = jeder Container ein eigener Prozess, standardmäßig ohne Root-Rechte

podman-compose installieren

Pip-Paket installieren (EPEL-Version ist teils veraltet)
  • dnf install -y python3-pip
  • pip3 install podman-compose

Vorbereitung: Zertifikate

Die Zertifikate liegen bereits vor unter:

  • /etc/ssl/own.crt
  • /etc/ssl/own.key

Caddyfile

Caddyfile im Projektverzeichnis anlegen (z. B. /opt/monitoring/Caddyfile)
kuma.it2XX.int {
    tls /etc/ssl/own.crt /etc/ssl/own.key
    reverse_proxy uptime-kuma:3001
}

compose.yaml

Im selben Verzeichnis wie die Caddyfile anlegen
version: "3"

services:
  uptime-kuma:
    image: docker.io/louislam/uptime-kuma:1
    container_name: uptime-kuma
    volumes:
      - uptime-kuma-data:/app/data
    networks:
      - monitoring

  caddy:
    image: docker.io/library/caddy:2
    container_name: caddy
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile:Z
      - /etc/ssl/own.crt:/etc/ssl/own.crt:Z
      - /etc/ssl/own.key:/etc/ssl/own.key:Z
      - caddy-data:/data
    networks:
      - monitoring
    depends_on:
      - uptime-kuma

volumes:
  uptime-kuma-data:
  caddy-data:

networks:
  monitoring:
Hinweis SELinux

Das :Z an den Bind-Mounts (Caddyfile, Zertifikate) ist auf Rocky notwendig, damit Caddy trotz aktivem SELinux Lesezugriff über den passenden Kontext erhält. Bei benannten Volumes (uptime-kuma-data, caddy-data) ist das nicht nötig, das übernimmt Podman selbst.

Starten und Stoppen

Stack starten
  • cd /opt/monitoring
  • podman-compose up -d
Status prüfen
  • podman-compose ps
Stack stoppen
  • podman-compose down

Test

Aufruf im Browser
https://kuma.it2XX.int

Beim ersten Aufruf fragt Uptime Kuma nach Anlegen eines Admin-Accounts. Danach lassen sich Monitore für ns, www, ldap, client und fw anlegen (Ping, TCP-Port, HTTP) und der Status live auf dem Dashboard verfolgen.

Merksatz

podman-compose = ein YAML-File statt mehrerer podman-run-Befehle | Rest bleibt gleich: rootless, daemonless, systemd-nahe Verwaltung möglich.