Files
dilib_operations/START_HERE.md
T
ms 2c1c48df0c
PostgreSQL integration / tests (push) Has been cancelled
init
2026-11-09 13:15:48 +01:00

6.0 KiB
Raw Blame History

dilib Operations 1.1 – vollständiges Projekt

Die Anwendung läuft mit Django, PostgreSQL, Celery, Redis, Flower und NiceGUI. Der gesamte Betrieb erfolgt ohne Docker. Nginx oder Apache liefert HTTPS und die WebSocket-Verbindung zur Oberfläche; Certbot kann Zertifikate einrichten.

1. Dateien auf den Zentralserver kopieren

Das Archiv enthält dilib_dashboard/. Diesen Ordner nach /opt/dilib-dashboard kopieren. Zielsystem für die Installationsskripte: Ubuntu 24.04 mit Python 3.12.

cd /opt/dilib-dashboard
sudo bash scripts/install-central.sh
sudo .venv/bin/python scripts/configure.py --domain dashboard.example.com

dashboard.example.com durch die eigene Domain ersetzen. Der Installer legt eine virtuelle Umgebung, Dienstbenutzer, Konfigurationsdatei und systemd-Dienste an. Er installiert keinen konkurrierenden Webserver und startet die Anwendung noch nicht.

2. PostgreSQL und Konfiguration

Für eine neue Datenbank:

sudo systemctl enable --now postgresql redis-server
sudo -u postgres createuser --pwprompt dilib
sudo -u postgres createdb --owner=dilib dilib_dashboard
sudoedit /etc/dilib-dashboard/dashboard.env

DATABASE_URL mit dem gesetzten Passwort eintragen (URL-Sonderzeichen kodieren). ALLOWED_HOSTS und CSRF_TRUSTED_ORIGINS setzt configure.py anhand der Domain. Redis DB 5 und 6 sind voreingestellt und müssen frei bzw. für dieses Projekt vorgesehen sein. Optional SMTP-Einstellungen und Empfänger setzen. Bei externer DB entsprechend eigene Verbindung konfigurieren und die beiden createuser/createdb-Befehle auslassen.

sudo bash scripts/finalize-install.sh
sudo bash scripts/manage-env.sh createsuperuser

Dies führt Migrationen aus, sammelt statische Dateien, prüft DB/Redis/Broker und startet API, UI, Celery-Worker und Beat. doctor --workers prüft danach die Antwort mindestens eines Workers. Es ist kein umfassender Last- oder Verfügbarkeitstest.

3. Webserver – eine Variante auswählen

Nginx

sudo apt-get install nginx certbot python3-certbot-nginx
.venv/bin/python scripts/render-proxy.py --domain dashboard.example.com --server nginx --output dashboard.conf
sudo install -m 644 dashboard.conf /etc/nginx/conf.d/dilib-dashboard.conf
sudo nginx -t
sudo systemctl reload nginx
sudo certbot --nginx -d dashboard.example.com

Bei noch nicht gestartetem Nginx sudo systemctl start nginx verwenden.

Bestehender Apache

sudo apt-get install certbot python3-certbot-apache
sudo a2enmod proxy proxy_http headers alias
.venv/bin/python scripts/render-proxy.py --domain dashboard.example.com --server apache --output dashboard-apache.conf
sudo install -m 644 dashboard-apache.conf /etc/apache2/sites-available/dilib-dashboard.conf
sudo a2ensite dilib-dashboard.conf
sudo apache2ctl configtest
sudo systemctl reload apache2
sudo certbot --apache -d dashboard.example.com

Apache mindestens 2.4.47. Nur einen Webserver für dieselbe IP/Port-Kombination verwenden. DNS/AAAA auf den richtigen Server richten; Ports 80/443 freigeben. API/UI-Ports sind nur lokal gebunden. Sichere Cookies sind aktiviert: Anmeldung nach TLS-Einrichtung über https://dashboard.example.com. Unverschlüsseltes HTTP dient hier nur dem Setup.

4. Überwachte Hosts hinzufügen

Auf dem Zentralserver:

sudo bash scripts/manage-env.sh register_agent app-01 --segment Produktion --address 10.10.1.20

Token privat übernehmen. Auf dem überwachten Host Projekt nach /opt/dilib-dashboard kopieren und ausführen:

cd /opt/dilib-dashboard
sudo bash scripts/install-agent.sh
sudoedit /etc/dilib-agent/agent.env
sudo systemctl enable --now dilib-agent

AGENT_TOKEN, DASHBOARD_URL=https://dashboard.example.com/api/ingest/ und lokale Dienst-Health-URLs setzen. Ohne Flower dort AGENT_FLOWER_URL= leeren. Je unabhängigem Broker exakt einen Event-Collector einschalten: AGENT_COLLECT_EVENTS=1, Broker-URL und eindeutige Collector-ID setzen. Alle übrigen Host-Agenten bleiben ohne Event-Collector.

Die überwachten Celery-Projekte benötigen aktivierte Events:

CELERY_WORKER_SEND_TASK_EVENTS = True
CELERY_TASK_SEND_SENT_EVENT = True
CELERY_TASK_TRACK_STARTED = True

Diese Namen gelten für Django mit dem Namespace CELERY. Worker danach regulär neu starten. Bei nicht namespaced Celery-Konfiguration die klein geschriebenen Namen nutzen.

5. Flower je Cluster einrichten

Auf dem ausgewählten Agent-Host:

sudo bash scripts/install-flower.sh
sudoedit /etc/dilib-agent/flower.env
sudo systemctl enable --now dilib-flower

Broker-URL und FLOWER_BASIC_AUTH=monitor:LANGES-ZUFAELLIGES-PASSWORT setzen. Dieselben Flower-Zugangsdaten in agent.env übernehmen, dann Agent neu starten. Flower lauscht nur auf localhost:5555. Für direkte Bedienung einen SSH-Tunnel nutzen:

ssh -L 5555:127.0.0.1:5555 BENUTZER@AGENT-HOST

Dann http://127.0.0.1:5555 öffnen. Existiert bereits Flower, entweder dieses mit Persistenz konfigurieren oder den neuen Dienst verwenden; keine doppelte Portbelegung. Flower schreibt seinen Zustand unter /var/lib/dilib-flower/; PostgreSQL speichert parallel die zentrale Ereignishistorie. Das Dashboard rekonstruiert nicht Flowers UI.

6. Sicherung und Abnahme

Für die lokale Standarddatenbank ist ein täglicher Backup-Timer vorbereitet:

sudo systemctl enable --now dilib-backup.timer
sudo systemctl start dilib-backup.service
sudo systemctl list-timers dilib-backup.timer

Dumps liegen in /var/lib/postgresql/dilib-backups. Der Timer gilt nur für die lokale DB dilib_dashboard, läuft um 02:15 Uhr in der Serverzeitzone mit bis zu 10 Minuten Zufallsversatz und löscht keine Backups. Externe Kopie, Speicherüberwachung und Backup-Aufbewahrung betreiberseitig ergänzen. Für externe DB den Backupdienst anpassen.

Danach docs/OPERATIONS.md abarbeiten: echte Tasks, Netzunterbrechung, Neustart, SMTP und Restore prüfen. Rollen: aktive Benutzer lesen, Staff-Benutzer bedienen, Superuser verwalten. Alle Benutzer sehen alle Segmente; keine Mandantentrennung.