deploy/docker-compose.yml
Rama main · réplica de lectura del repositorio original.
# docs/00-DECISIONS.md D-10: ein Container, ein benanntes Volume.
# Start aus diesem Verzeichnis:
#
# cd deploy && docker compose up -d
#
# Danach http://<host>:8080/ öffnen -- eine frische Installation zeigt automatisch
# den Erstinbetriebnahme-Assistenten (kein Nutzer existiert => /setup statt
# /login). Siehe deploy/README.md für Backup/Restore und den Hardwarebedarf.
#
# Update-Helfer: gibt es hier bewusst nicht. Er aktualisiert nur das fertige Image (compose.standalone-mit-helfer.yml);
# diese Datei baut selbst, aktualisiert wird mit scripts/deploy_pi.sh. Achtung: Dort heißt der Datenspeicher
# nodvard-deck-data, hier deploy_lattice_data -- einfach die Datei zu wechseln startete mit leeren Daten.
# Projektname FEST, nicht vom Ordnernamen abhängig: Er steckt im Namen des Volumes
# des Containers (`deploy-nodvard-deck-1`). Das Volume ist zusätzlich unten fest benannt.
# Die Skripte in diesem Ordner rufen Compose immer mit `-p deploy` auf. Nicht ändern.
name: deploy
services:
nodvard-deck:
build:
context: ..
dockerfile: deploy/Dockerfile
image: nodvard-deck:latest
restart: unless-stopped
ports:
- "8080:8080"
environment:
NODVARD_DECK_ENV: prod
NODVARD_DECK_LOG_JSON: "true"
# Rückfall für `audit.retention_days` (docs/03 §9): gilt, solange unter Einstellungen,
# System keine Aufbewahrungsdauer gesetzt ist. Die Zeitzone stellt man dort ebenfalls ein
# (Vorgabe: NODVARD_DECK_TIMEZONE, sonst TZ, sonst Europe/Berlin).
NODVARD_DECK_AUDIT_RETENTION_DAYS: "90"
# NODVARD_DECK_JWT_SECRET bewusst NICHT gesetzt: unbelegt wird beim allerersten
# Start ein Zufallswert unter /app/data/jwt_secret.key abgelegt (config.py::
# get_or_create_jwt_secret()), der das persistente Volume überlebt. Nur
# explizit setzen, wer den Container ohne das Volume neu erzeugen will, ohne
# bestehende Sitzungen zu invalidieren (Secret-Mount-Fall, D-06).
# D-10: dieselbe Image, Fake-Daten statt echter Connectoren fürs
# Selbst-Antesten. Unverändert `false` lassen für einen echten Einsatz --
# siehe deploy/README.md für den aktuellen Umsetzungsstand dieses Schalters.
NODVARD_DECK_DEMO_MODE: "false"
# Optional, übersteuert die Einstellung unter Einstellungen -> Server & Zugänge: "true" = neue
# Server-Schlüssel werden nicht still gemerkt, sondern erst nach Bestätigung ("Verbindung
# prüfen"); "false" = still merken (nicht empfohlen). Ohne diese Zeile gilt die gespeicherte
# Einstellung, und ohne gespeicherten Wert wird bestätigt. Nach "Schlüssel vergessen" ist die
# Bestätigung immer nötig. Bereits gemerkte Schlüssel sind nie betroffen.
# Der alte Name LATTICE_SSH_CONFIRM_NEW_HOST_KEYS gilt nur noch übergangsweise (spätestens bis 1.0).
# NODVARD_DECK_SSH_CONFIRM_NEW_HOST_KEYS: "true"
# DNS nur für DIESEN Container (Docker Compose `dns:`), nicht am Host geändert.
# Hintergrund: ohne dieses Feld erbt der Container den Host-Resolver. Zeigt der auf
# einen Router, der die internen Namen des eigenen Netzes (z. B. `cloud.home.example`,
# aufgelöst von einem lokalen Pi-hole/AdGuard) nicht kennt, scheitern Quellen wie
# Nextcloud mit "Name or service not known". Ohne Angabe gibt es keine Vorgabe: Der
# Container fragt den Resolver des Hosts, und keine Anfrage geht ungefragt an einen
# fremden Dienst. Wer einen eigenen Resolver braucht, legt neben dieser Datei eine
# `.env` an (git-ignoriert), zum Beispiel:
#
# NODVARD_DECK_DNS_1=192.168.1.10 # lokaler Pi-hole/AdGuard
# NODVARD_DECK_DNS_2=1.1.1.1 # nur ein Beispiel: öffentlicher Resolver (Cloudflare)
#
# Die alten Namen LATTICE_DNS_1/2 gelten nur noch übergangsweise, spätestens bis 1.0 (verschachtelt:
# neu, sonst alt). Ein leerer Eintrag fällt weg, ohne beide Werte hat der Container keine eigene
# DNS-Einstellung. `scripts/deploy_pi.sh` schreibt nur die neuen Namen auf den Zielrechner,
# `pi_switch.sh switch` benennt alte Zeilen in deploy/.env um (siehe deploy/README.md).
dns:
- ${NODVARD_DECK_DNS_1:-${LATTICE_DNS_1:-}}
- ${NODVARD_DECK_DNS_2:-${LATTICE_DNS_2:-}}
# Log-Rotation: begrenzt die Docker-Logdatei des Dashboards (3 x 10 MB), damit sie auf
# dem Pi nicht ungebremst wächst (z. B. bei wiederholten Fehlern im Log).
logging:
driver: json-file
options:
max-size: "10m"
max-file: "3"
volumes:
# Der Schlüssel `lattice_data` bleibt aus Altersgründen so (Volume `deploy_lattice_data`
# mit allen Daten). NICHT umbenennen, sonst startet das Dashboard leer.
- lattice_data:/app/data
# Optional: Ordner für die Sicherungen aus Einstellungen -> System -> Sicherung, AUSSERHALB
# des Datenvolumes (am besten ein anderes Laufwerk oder ein NAS). Zeile einkommentieren,
# Ordner anlegen und dem Nutzer 1000 geben (`mkdir sicherungen && sudo chown 1000:1000 sicherungen`),
# dann in der Oberfläche als Ordner `/backups` wählen. Nur `/backups` (und darunter) ist
# als Ziel erlaubt, neben dem Standard /app/data/backups.
# - ./sicherungen:/backups
# NAS oder NFS: den eingehängten Ordner eintragen, Rechte für 1000 und Reihenfolge beim Start siehe
# docs/16-SICHERUNG.md, Abschnitt "Sicherungen auf ein NAS oder NFS".
# - /pfad/zum/nas:/backups
healthcheck:
test: ["CMD", "python", "-I", "-c", "import urllib.request; urllib.request.urlopen('http://127.0.0.1:8080/api/v1/health', timeout=2)"]
interval: 30s
timeout: 3s
# Vor dem Start läuft die Migration samt Kopie der Datenbank (`nodvard_deck.boot`) -- bei einer großen Datenbank auf einem Pi
# Minuten. Während dieser Zeit zählen Fehlschläge nicht. Die Notseite antwortet mit 503; der Check schlägt dann an.
start_period: 300s
retries: 3
volumes:
# Schlüssel UND Name fest: `name:` hält den echten Volume-Namen auch dann, wenn jemand den
# Projektnamen überstimmt (COMPOSE_PROJECT_NAME, `-p`). Sonst gäbe es ein neues, LEERES
# Volume (z. B. foo_lattice_data). Nicht ändern, siehe oben.
lattice_data:
name: deploy_lattice_data