Files
docker-podman-installation-…/docker-compose.yml
T
duffyduckandClaude Opus 5 58308264c6 Absturzschleife des Proxy Managers: IP-Bereich-Abruf abschaltbar
Das Containerprotokoll eines Kunden zeigte, was hinter dem 502 steckte:
der Dienst stuerzt in einer Schleife ab.

  [IP Ranges] Fetching https://ip-ranges.amazonaws.com/ip-ranges.json
  Uncaught Error: Client network socket disconnected before secure TLS
                  connection was established
  ... node --abort_on_uncaught_exception ... index.js
  Starting backend ...          [und das immer wieder]

Beim Start holt der Proxy Manager IP-Bereiche von AWS und Cloudflare -
gebraucht wird das nur fuer Zugriffslisten mit deren Adressbereichen,
auf einem internen Server also nie. Der Code faengt Fehler dabei ab,
dieser kommt aber asynchron vom TLS-Socket und laeuft am catch vorbei;
weil node mit --abort_on_uncaught_exception laeuft, bricht der Prozess
ab, s6 startet neu, und nginx davor antwortet durchgehend mit 502.

Am Abbild nachgesehen und ausprobiert:

  - IP_RANGES_FETCH_ENABLED=false verhindert den Abruf; im Protokoll
    steht dann "IP Ranges fetch is disabled by environment variable",
    das Backend laeuft.
  - Scheitert der Abruf sauber (DNS-Fehler, Verbindung abgelehnt), faengt
    der Code ihn ab und der Dienst laeuft weiter - der Absturz haengt
    also wirklich an der gekappten TLS-Verbindung.
  - initTimer() laeuft unabhaengig vom Schalter und versucht es alle
    sechs Stunden erneut. Das steht als Hinweis samt extra_hosts in der
    README.

Neu: NPM_IP_RANGES_FETCH, Vorgabe false. Und die Fehlermeldung erkennt
den Fall selbst - sie zaehlt Startversuche und Ausnahmen im
Containerprotokoll und nennt den Schalter, statt den Benutzer weiter auf
"startet noch" warten zu lassen.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-09-21 00:21:10 +02:00

89 lines
4.2 KiB
YAML

# =====================================================================
# Checkmk + NGINX Proxy Manager
# Funktioniert identisch mit: docker compose | podman-compose
#
# - Beide Dienste laufen im Host-Netzwerk -> keine "ports:"-Definition
# - Ausschliesslich Bind-Mounts nach ./data -> keine named volumes
# =====================================================================
services:
# -------------------------------------------------------------------
# Checkmk (OMD) - im Host-Netzwerk
# Port 5000 = Web-GUI (wird vom NGINX Proxy Manager als Backend genutzt)
# Port 8000 = Agent-Receiver (cmk-agent-ctl / TLS-registrierte Agents)
# Port 6557 = Livestatus (nur wenn CMK_LIVESTATUS_TCP=on)
# -------------------------------------------------------------------
checkmk:
# Vollqualifizierter Name! Wird aus der .env genommen und ggf. von
# "cmk-manage.sh image ..." dort eingetragen. Kurze Namen wuerde Podman
# ueber unqualified-search-registries aufloesen (auf RHEL zuerst
# registry.access.redhat.com) und das Image nicht finden.
image: ${CMK_IMAGE:-docker.io/checkmk/check-mk-raw:2.3.0-latest}
container_name: ${CMK_CONTAINER_NAME:-checkmk}
hostname: ${CMK_HOSTNAME:-checkmk}
network_mode: host
restart: unless-stopped
stop_grace_period: 120s
environment:
CMK_SITE_ID: ${CMK_SITE_ID:-cmk}
CMK_PASSWORD: ${CMK_PASSWORD:-}
CMK_LIVESTATUS_TCP: ${CMK_LIVESTATUS_TCP:-off}
MAIL_RELAY_HOST: ${MAIL_RELAY_HOST:-}
TZ: ${TZ:-Europe/Berlin}
volumes:
# Kompletter OMD-Datenbestand als Bind-Mount im Projektverzeichnis
- ${CMK_DATA_DIR:-./data/checkmk/sites}:/omd/sites:Z
- /etc/localtime:/etc/localtime:ro
ulimits:
nofile:
soft: 65536
hard: 65536
# ---------------------------------------------------------------
# Optional: tmpfs fuer das Site-tmp-Verzeichnis (Performance).
# Bewusst deaktiviert, weil uid/gid der Site nach einem Import
# abweichen koennen und das tmpfs dann falsch gemountet waere.
# Bei einer frisch angelegten Site ist uid/gid=1000 korrekt:
# ---------------------------------------------------------------
# tmpfs:
# - /opt/omd/sites/${CMK_SITE_ID:-cmk}/tmp:uid=1000,gid=1000
# -------------------------------------------------------------------
# NGINX Proxy Manager - ebenfalls Host-Netzwerk
# Port 80 = HTTP + Let's-Encrypt HTTP-01 Challenge
# Port 443 = HTTPS
# Port 81 = Admin-Oberflaeche (unbedingt per Firewall einschraenken!)
# -------------------------------------------------------------------
nginx-proxy-manager:
image: ${NPM_IMAGE:-docker.io/jc21/nginx-proxy-manager:2}
container_name: ${NPM_CONTAINER_NAME:-nginx-proxy-manager}
network_mode: host
restart: unless-stopped
environment:
DISABLE_IPV6: ${NPM_DISABLE_IPV6:-true}
TZ: ${TZ:-Europe/Berlin}
# Legt das erste Administratorkonto an - aber NUR beim allerersten
# Start mit leerer Datenbank. Ohne diese beiden Werte zeigt der
# Proxy Manager stattdessen einen Einrichtungsassistenten, und die
# REST-API laesst sich nicht ohne Weiteres nutzen.
INITIAL_ADMIN_EMAIL: ${NPM_ADMIN_EMAIL:-}
INITIAL_ADMIN_PASSWORD: ${NPM_ADMIN_PASSWORD:-}
# Beim Start holt der Proxy Manager sonst IP-Bereiche von AWS und
# Cloudflare. Gebraucht wird das nur fuer Zugriffslisten mit deren
# Adressbereichen - in einem internen Netz also nie. Wird die
# TLS-Verbindung dabei aufgebaut und dann gekappt (aufbrechender
# Proxy, Firewall), stirbt der Dienst an einer unbehandelten
# Ausnahme und startet in einer Schleife neu; nach aussen sieht man
# nur "502 Bad Gateway".
IP_RANGES_FETCH_ENABLED: ${NPM_IP_RANGES_FETCH:-false}
volumes:
- ${NPM_DATA_DIR:-./data/npm/data}:/data:Z
- ${NPM_LE_DIR:-./data/npm/letsencrypt}:/etc/letsencrypt:Z
# Verzeichnis fuer ein von aussen geliefertes Zertifikat. Wird es
# dort ersetzt, zeigen die Dateien unter /data/custom_ssl darauf -
# siehe "cmk-manage.sh cert external". Schreibgeschuetzt, denn der
# Container hat dort nichts zu suchen.
- ${CERT_EXTERNAL_DIR:-./data/npm/external-certs}:/certs:ro
depends_on:
- checkmk