MABEA/deploy

Deployment – MABEA

Zielserver: siehe Projekt-Memory (Debian 13, kein Docker-Zwang, Prompt 19).

Server-Grundausstattung (einmalig)

scp -i ~/.ssh/id_claude -r deploy root@<server>:/root/mabea-deploy
ssh -i ~/.ssh/id_claude root@<server>
cd /root/mabea-deploy
chmod +x install_server.sh
DB_PASSWORD='<sicheres-passwort>' APP_DOMAIN=<domain-oder-ip> ./install_server.sh

Installiert PostgreSQL + nginx, legt DB-Rolle/Datenbank an, richtet nginx als Reverse-Proxy vor 127.0.0.1:8000 ein. Ausgegebene DATABASE_URL sichern.

Backend deployen (später, nach Sprint-Fortschritt)

1. backend/ auf den Server kopieren (z. B. nach /opt/mabea/backend), .venv dort anlegen, pip install -e ".[dev]" bzw. ohne dev-Extra für Produktion.
2. .env aus backend/example.env ableiten, DATABASE_URL aus Schritt oben eintragen.
3. alembic upgrade head ausführen.
4. mabea-backend.service.template nach /etc/systemd/system/mabea-backend.service kopieren (Pfade/User anpassen), systemctl daemon-reload && systemctl enable --now mabea-backend.

Eskalations-Prüfung einrichten (Karte 12, nach Backend-Deploy)

cp mabea-eskalation.service.template /etc/systemd/system/mabea-eskalation.service
cp mabea-eskalation.timer.template /etc/systemd/system/mabea-eskalation.timer
systemctl daemon-reload
systemctl enable --now mabea-eskalation.timer

Läuft täglich 06:00 Uhr (±5min Streuung), ruft scripts/eskalation_pruefen.py direkt gegen die DB auf (kein HTTP/Admin-Token nötig). Zeitschwellen selbst liegen in der DB (eskalation_konfiguration, admin-editierbar über GET/PUT /api/v1/eskalation/konfiguration), nicht in dieser Timer-Konfiguration. Manueller Testlauf: systemctl start mabea-eskalation.service, Ergebnis in journalctl -u mabea-eskalation.service.

Weitere tägliche Prüfläufe einrichten

Gleiches Muster wie die Eskalations-Prüfung oben, je Timer:

cp mabea-readiness-snapshot.service.template /etc/systemd/system/mabea-readiness-snapshot.service
cp mabea-readiness-snapshot.timer.template /etc/systemd/system/mabea-readiness-snapshot.timer
cp mabea-wartung-benachrichtigung.service.template /etc/systemd/system/mabea-wartung-benachrichtigung.service
cp mabea-wartung-benachrichtigung.timer.template /etc/systemd/system/mabea-wartung-benachrichtigung.timer
systemctl daemon-reload
systemctl enable --now mabea-readiness-snapshot.timer mabea-wartung-benachrichtigung.timer

• mabea-readiness-snapshot (READY-006): täglich 23:55 Uhr, readiness_snapshot-Tabelle für Dashboard-Trend + Akte-Historie.
• mabea-wartung-benachrichtigung (NOTIF-003): täglich 06:30 Uhr, E-Mail bei neu fälliger Wartung.

Backup einrichten (FOUND-010)

cp mabea-backup.service.template /etc/systemd/system/mabea-backup.service
cp mabea-backup.timer.template /etc/systemd/system/mabea-backup.timer
systemctl daemon-reload
systemctl enable --now mabea-backup.timer

Läuft täglich 03:00 Uhr, pg_dump + gzip nach /opt/mabea/backups/, Rotation nach 14 Tagen (AUFBEWAHRUNG_TAGE in der .service-Datei anpassbar). Manueller Testlauf: systemctl start mabea-backup.service, Ergebnis in journalctl -u mabea-backup.service. Restore-Test nie automatisiert durchgeführt — vor echtem Ernstfall einmal manuell verifizieren (gunzip -c <backup>.sql.gz | psql <testdatenbank>).

Fehler-Tracking (GlitchTip) einrichten (FOUND-013, optional)

GlitchTip ist Sentry-API-kompatibles, selbst gehostetes Error-Tracking — komplett optional, MABEA läuft ohne unverändert weiter. Installation auf einem BELIEBIGEN Host (kann der MABEA-Server selbst oder ein separater sein):

scp glitchtip-install.sh root@<glitchtip-host>:/root/
ssh root@<glitchtip-host>
DOMAIN=<glitchtip-domain-oder-ip> ./glitchtip-install.sh

Installiert Docker (falls fehlend) + GlitchTip per Docker Compose unter /opt/glitchtip, legt zufälliges SECRET_KEY/DB-Passwort an. Danach:

cd /opt/glitchtip && docker compose exec web ./manage.py createsuperuser

Im Browser einloggen, Organisation + Projekt anlegen, angezeigte DSN-URL kopieren und in MABEA unter Admin > Fehler-Tracking eintragen — greift sofort (Backend + Frontend), kein Redeploy nötig. Leer lassen/Feld leeren deaktiviert das Tracking wieder vollständig.

Deinstallation: cd /opt/glitchtip && docker compose down -v (-v löscht auch alle GlitchTip-Daten).

Dateien

• install_server.sh – Server-Grundausstattung (PostgreSQL, nginx), idempotent
• nginx_mabea.conf.template – Reverse-Proxy-Vorlage, von install_server.sh verwendet
• mabea-backend.service.template – systemd-Unit-Vorlage für das Backend (noch nicht aktiviert, Pfade anpassen)
• mabea-eskalation.service.template / mabea-eskalation.timer.template – täglicher Eskalations-Prüflauf (Karte 12)
• mabea-readiness-snapshot.service.template / .timer.template – täglicher Bereitschafts-Snapshot (READY-006)
• mabea-wartung-benachrichtigung.service.template / .timer.template – täglicher Wartungsfälligkeits-Prüflauf (NOTIF-003)
• backup_datenbank.sh / mabea-backup.service.template / .timer.template – tägliches DB-Backup mit Rotation (FOUND-010)
• glitchtip-install.sh – optionale GlitchTip-Installation (FOUND-013, Error-Tracking), unabhängiger Host