Updates

Wer mit install.sh oder Variante B installiert hat, hat schon ein update.sh im Projektordner. Es macht alles, was sicher und nicht überraschend ist – und fragt, bevor es etwas Größeres anfasst.

Standardablauf

cd /pfad/zu/dns-manager
./update.sh

Was es der Reihe nach tut:

git fetch mit Tags. Wenn der Checkout auf einem Release-Tag steht, wechselt es auf das jeweils neueste v*-Tag. Wenn auf main, macht es git pull.
Bietet ein DB-Backup an (kann mit --no-backup übersprungen werden) – schreibt eine backup_<version>_<timestamp>.sql ins Repo-Verzeichnis via mysqldump --single-transaction.
Warnt, wenn ein Major-Versionssprung ansteht (rote Box, aktive Bestätigung nötig).
docker compose build backend – mit --no-cache nur bei tatsächlichem Versionswechsel oder explizitem --rebuild. Spart 3–5 min bei reinen Patches.
docker compose up -d.

Flags

Flag	Was es tut
`--rebuild` / `--no-cache`	Forciert `build --no-cache`, auch ohne Versionswechsel.
`--no-backup`	Überspringt die DB-Backup-Frage.
`--skip-fetch`	Kein `git fetch`/`pull`; nimmt einfach den lokalen Stand.
`--help` / `-h`	Hilfe ausgeben und beenden.

Was beim Update geschützt bleibt

Die MariaDB-Daten (mariadb_data-Volume).
Die .env-Datei (wird nie überschrieben).
Hochgeladene Dateien wie das Branding-Logo (backend_uploads-Volume).
Alle Tokens, Webhook-Definitionen, Server-Configs, User – alles in der DB.

Manuell auf eine bestimmte Version

cd dns-manager
git fetch origin --tags --force --prune --prune-tags
git checkout v2.3.7              # oder: git checkout main && git pull
docker compose build --no-cache backend
docker compose up -d

Rollback

# Container stoppen
docker compose down

# DB aus Backup zurückspielen
docker compose up -d mariadb
sleep 10
docker exec -i dns-manager-db mysql -u root -p dns_manager < backup_v2.3.7_20260420-153000.sql

# Auf alten Tag zurück
git checkout v2.3.7
docker compose build backend
docker compose up -d

Image-Build im Detail

Das Backend-Image baut in zwei Stages:

Frontend: Node 22, npm ci, npm run build in frontend/. Erzeugt dist/.
Backend: Python 3.12 slim, pip install aus requirements.txt, kopiert das gebaute Frontend-dist/ als Static rein.

Seit v2.3.7 prüft der Dockerfile nach dem Frontend-Copy explizit, dass index.html, assets/ und ein gebautes JS-Bundle existieren – sonst bricht der Build sofort ab. Damit kann es kein „leeres weißes Bild im Browser" mehr geben, weil ein Frontend-Build still gefailed ist.

Pre-Update-Checkliste

Frischen DB-Dump (./update.sh macht das automatisch, wenn man nicht --no-backup sagt).
Changelog der Zielversion lesen – siehe Changelog.
Bei Major-Sprüngen: kurzer Test-Restart auf einer Stage-VM, bevor du Production drehst.
Genug Plattenplatz für ein zweites Backend-Image (Multi-Stage-Build dauert ein paar Minuten und braucht temporären Speicher).