ms
+39
@@ -0,0 +1,39 @@
|
||||
# HTTP-API
|
||||
|
||||
Basis `/api/`, JSON. Login liefert ein acht Stunden gültiges Bearer-Token.
|
||||
Alle Lesezugriffe benötigen Anmeldung. Agent-Token sind nur für Ingest gültig.
|
||||
|
||||
| Methode / Pfad | Funktion |
|
||||
|---|---|
|
||||
| POST auth/login/ | username, password → token |
|
||||
| POST auth/logout/ | aktuelles Token widerrufen |
|
||||
| GET auth/me/ | Benutzerinformationen |
|
||||
| POST ingest/ | Agent-Batch, Header Authorization: Agent TOKEN |
|
||||
| GET summary/ | Kennzahlen, Server, Durchsatz |
|
||||
| GET servers/ | Hostliste |
|
||||
| GET servers/UUID/ | Detail und Zeitreihe |
|
||||
| PATCH servers/UUID/ | maintenance boolean, Operator |
|
||||
| GET tasks/ | Taskliste mit q, state, offset |
|
||||
| GET events/ | Ereignisliste mit q, kind, offset |
|
||||
| GET alarms/ | offene Alarme, all=1 für Historie, offset |
|
||||
| POST alarms/ID/ack/ | Quittierung, Operator |
|
||||
| GET/PUT settings/ | Lesen / Operator-Konfiguration |
|
||||
| GET flower/ | zuletzt empfangene Flower-Statuswerte |
|
||||
| GET export/ | Serverübersicht als CSV |
|
||||
| GET report/ | Seaborn-Heatmap als PNG |
|
||||
| POST ai/ | konfigurierte KI-Analyse, Operator |
|
||||
| GET health/ | Datenbankprüfung |
|
||||
|
||||
Listen nutzen `segment` (Name), `server` (UUID) und je nach Endpunkt `hours`
|
||||
(1, 24, 168 oder 720). Tasks/Events/Alarme sind auf 100 Einträge pro Seite begrenzt.
|
||||
Flower-Status enthält den Messzeitpunkt; alte Werte sind kein aktueller Verfügbarkeitsnachweis.
|
||||
|
||||
Ingest-Beispiel:
|
||||
|
||||
```json
|
||||
{"events":[{"id":"9f242e23-d82d-457a-b89c-cc97ce5beee9","kind":"metric","occurred_at":"2026-11-04T12:00:00Z","payload":{"cpu":12.5,"ram":43.2,"disk":50.1,"services":{"django":true}}}]}
|
||||
```
|
||||
|
||||
Erfolgsantwort enthält `accepted` (neu eingefügte Ereignisse) und `received`
|
||||
(Anzahl verarbeiteter Eingabeelemente inklusive Duplikate). Nur bei erfolgreichem
|
||||
HTTP-Status und passender received-Anzahl bestätigt der Agent die Outbox-Einträge.
|
||||
@@ -0,0 +1,47 @@
|
||||
# Architektur und Datenhaltbarkeit
|
||||
|
||||
Agenten verbinden sich aus jedem Segment per HTTPS zur zentralen Django-API.
|
||||
Jeder Host sammelt alle fünf Sekunden Messwerte. Ein Collector je Broker empfängt
|
||||
Celery-Events. Vor dem Versand werden Daten in einer SQLite-WAL-Outbox auf dem Host
|
||||
committet. Die API validiert den gesamten Batch, sperrt den Serverdatensatz und
|
||||
schreibt Ereignisarchiv und abgeleitete Zustände in einer PostgreSQL-Transaktion.
|
||||
Erst nach bestätigter Annahme löscht der Agent die lokalen Einträge.
|
||||
|
||||
Ereignis-UUIDs verhindern Duplikate bei wiederholter Übertragung. Die API bindet
|
||||
Tokens an einen Server; Klartexttokens werden zentral nicht gespeichert. Bei Verlust
|
||||
der Antwort nach erfolgreichem Commit ist die Wiederholung unschädlich. Verspätete
|
||||
Messwerte überschreiben keine neueren Werte; veraltete Samples machen einen Host
|
||||
nicht online. Task-Endzustände werden nicht durch verspätetes RECEIVED überschrieben.
|
||||
|
||||
Der NiceGUI-Prozess spricht intern mit Django; Browser erhalten keine Agent-Tokens.
|
||||
Ein fünfsekündiger Timer aktualisiert die Ansichten. Einstellungen und KI-Ausgabe
|
||||
werden während der Bearbeitung nicht automatisch neu aufgebaut. Redis dient als
|
||||
zentraler Celery-Broker und Login-Limit-Cache, PostgreSQL als Monitoringspeicher.
|
||||
Seaborn/NumPy erzeugen PNG-Auslastungsberichte, ECharts die Live-Diagramme.
|
||||
|
||||
## Persistenzgrenzen
|
||||
|
||||
- Ausfall des zentralen Servers/Netzes: bereits erfasste Events bleiben in der lokalen Outbox.
|
||||
- Agentenneustart: vorhandene Outbox bleibt erhalten; vor der lokalen Speicherung
|
||||
verlorene Broker-Events können nicht rekonstruiert werden.
|
||||
- Voller Datenträger/Outbox-Limit: Erfassung kann ausfallen. Spool-Größe und Logs überwachen.
|
||||
- Celery-Eventtransport ist keine garantierte Geschäftsereignis-Zustellung.
|
||||
Für lückenlose Nachweise zusätzlich eine transaktionale Outbox in den Fachanwendungen einsetzen.
|
||||
- Flower-Neustart: eigener Dateistand wird geladen; seit dem letzten Speichern
|
||||
können bei hartem Absturz Daten fehlen. Zentrale bereits angenommene Events bleiben erhalten.
|
||||
- Aufbewahrung: Standard 90 Tage, einstellbar; stündliche bereinigende Celery-Aufgabe.
|
||||
Backups besitzen eine davon unabhängige Aufbewahrung.
|
||||
- Task-Argumente, Rückgabewerte und Exceptiontexte werden bewusst nicht gesammelt.
|
||||
Die Fehleransicht zeigt Zustände; Stacktraces bleiben in den jeweiligen Anwendungslogs.
|
||||
|
||||
## Dimensionierung
|
||||
|
||||
Bei fünf Sekunden pro Host entstehen 17.280 Host-Messereignisse pro Tag und Host,
|
||||
zusätzlich Flower-/Collector-Status sowie Task-/Worker-Events. Pro Metric werden
|
||||
Event- und Metric-Zeilen gespeichert. Kapazität mit echten Payloads messen.
|
||||
Für große Flotten sollten Partitionierung, ältere Zeitreihenaggregate und SQL-Abfragen
|
||||
unter Produktionslast optimiert werden; diese Version verwendet indizierte Tabellen
|
||||
und begrenzte Listen/Bereinigungsbatches, keine Partitionierung.
|
||||
|
||||
Quellen: https://flower.readthedocs.io/en/latest/config.html und
|
||||
https://docs.celeryq.dev/en/stable/userguide/monitoring.html (geprüft 04.11.2026).
|
||||
@@ -0,0 +1,28 @@
|
||||
# Vorhandene Flower-Taskdaten übernehmen
|
||||
|
||||
Optional kann der Agent die noch über Flowers API verfügbaren Tasks als Snapshots
|
||||
in seine lokale Outbox übernehmen. Keine direkte Deserialisierung fremder Flower-
|
||||
Datenbankdateien. Nicht mehr in Flower vorhandene Tasks können nicht rekonstruiert werden.
|
||||
|
||||
```bash
|
||||
cd /opt/dilib-dashboard
|
||||
sudo systemctl stop dilib-agent
|
||||
sudo -u dilib-agent .venv-agent/bin/python -m agent.import_flower --env /etc/dilib-agent/agent.env --limit 100000
|
||||
sudo systemctl start dilib-agent
|
||||
```
|
||||
|
||||
Der Agent überträgt anschließend die Outbox. Argumente, Ergebnisse und Tracebacks
|
||||
werden nicht importiert. Pro Task wird der verfügbare Zustand übernommen, keine
|
||||
vollständige historische Zustandsfolge. Wiederholung desselben Snapshots verwendet
|
||||
dieselbe Ereignis-ID. Flower muss erreichbar sein und gültige Zeitstempel liefern.
|
||||
Daten älter als die konfigurierte Retention werden bei der Bereinigung wieder entfernt.
|
||||
|
||||
Bei einem blockierten Upload kann eine gezielt geprüfte ungültige Event-ID in eine
|
||||
lokale Quarantänetabelle verschoben werden. Vorher Agent stoppen und Spool sichern:
|
||||
|
||||
```bash
|
||||
sudo -u dilib-agent .venv-agent/bin/python -m agent.spool /var/lib/dilib-agent/outbox.sqlite3
|
||||
sudo -u dilib-agent .venv-agent/bin/python -m agent.spool /var/lib/dilib-agent/outbox.sqlite3 --quarantine-id EVENT-UUID --reason 'Validierungsfehler geprüft'
|
||||
```
|
||||
|
||||
Die Quarantäne bleibt lokal erhalten; sie wird nicht an die API übertragen.
|
||||
@@ -0,0 +1,160 @@
|
||||
# Installation (Detailreferenz)
|
||||
|
||||
Für die aktuelle vollständige Reihenfolge zuerst **[START_HERE.md](../START_HERE.md)** verwenden.
|
||||
Nginx wird nicht automatisch installiert; Apache kann alternativ verwendet werden.
|
||||
|
||||
# Installation ohne Docker
|
||||
|
||||
Ziel: Ubuntu 24.04 LTS, Python 3.12, PostgreSQL und Redis. Andere Python-/OS-Versionen
|
||||
vorher prüfen. Anforderungen: DNS-Name, TLS-Zertifikat, SMTP optional, ausgehendes
|
||||
HTTPS von jedem überwachten Host zum Dashboard. Agent benötigt lokalen Brokerzugriff.
|
||||
|
||||
## 1. Zentralserver vorbereiten
|
||||
|
||||
Projektinhalt nach `/opt/dilib-dashboard` kopieren. Anschließend:
|
||||
|
||||
```bash
|
||||
cd /opt/dilib-dashboard
|
||||
sudo bash scripts/install-central.sh
|
||||
sudo -u postgres createuser --pwprompt dilib
|
||||
sudo -u postgres createdb --owner=dilib dilib_dashboard
|
||||
sudoedit /etc/dilib-dashboard/dashboard.env
|
||||
```
|
||||
|
||||
Das Skript installiert Pakete und systemd-Dateien, erzeugt zufällige Secrets und
|
||||
startet die Anwendung noch nicht. Die Datenbankkommandos nur bei einer neuen
|
||||
Installation ausführen. Vorhandene Datenbanken nicht löschen.
|
||||
|
||||
In `dashboard.env` setzen:
|
||||
- `DATABASE_URL`: tatsächlicher Datenbankbenutzer und Passwort (Sonderzeichen URL-kodieren).
|
||||
- `ALLOWED_HOSTS`: Domain plus `127.0.0.1,localhost`.
|
||||
- `CSRF_TRUSTED_ORIGINS`: `https://Ihre-Domain`.
|
||||
- `CACHE_URL` und `CELERY_BROKER_URL`: getrennte Redis-DBs; nicht mit produktiven Task-Queues teilen.
|
||||
- `EMAIL_*` und `ALERT_RECIPIENTS`: SMTP und kommaseparierte Empfänger, falls gewünscht.
|
||||
- `COOKIE_SECURE=1` im TLS-Betrieb belassen.
|
||||
|
||||
```bash
|
||||
sudo bash scripts/manage-env.sh migrate
|
||||
sudo bash scripts/manage-env.sh createsuperuser
|
||||
sudo bash scripts/manage-env.sh collectstatic --noinput
|
||||
sudo systemctl enable --now dilib-api dilib-ui dilib-worker dilib-beat
|
||||
```
|
||||
|
||||
API lauscht nur auf 127.0.0.1:8000, UI auf 127.0.0.1:8080. PostgreSQL und Redis
|
||||
nicht öffentlich freigeben. Genau eine Beat-Instanz betreiben.
|
||||
|
||||
## 2. HTTPS-Reverse-Proxy
|
||||
|
||||
Bei Nginx zuvor `sudo apt-get install nginx` ausführen.
|
||||
|
||||
Gültiges Zertifikat für die eigene Domain bereitstellen. `deploy/nginx.conf`
|
||||
nach `/etc/nginx/sites-available/dilib-dashboard` kopieren, Domain und Zertifikatpfade
|
||||
ersetzen. Die Datei gehört in den üblichen `http`-Include-Kontext von Nginx.
|
||||
|
||||
```bash
|
||||
sudo ln -s /etc/nginx/sites-available/dilib-dashboard /etc/nginx/sites-enabled/dilib-dashboard
|
||||
sudo nginx -t
|
||||
sudo systemctl reload nginx
|
||||
```
|
||||
|
||||
Firewall: 443 für Benutzer und Agenten; 80 nur für Redirect bzw. Zertifikatsvalidierung.
|
||||
Bestehende Nginx-Konfiguration auf Konflikte prüfen. Anmeldung über die eigene Domain.
|
||||
Benutzer in `/admin/` anlegen: aktive Benutzer lesen, `is_staff` erlaubt Quittierung,
|
||||
Wartungsmodus, Einstellungen und KI-Analyse. Superuser verwalten Modelle.
|
||||
|
||||
## 3. Host registrieren
|
||||
|
||||
Auf dem Zentralserver je Host ausführen:
|
||||
|
||||
```bash
|
||||
sudo bash scripts/manage-env.sh register_agent app-01 --segment Produktion --address 10.10.1.20
|
||||
```
|
||||
|
||||
Der Befehl zeigt das Agent-Token einmal an. Privat in die Agentkonfiguration übernehmen.
|
||||
Für Widerruf/Rotation denselben Befehl mit `--rotate` ausführen und Agent aktualisieren.
|
||||
|
||||
## 4. Agent auf jedem überwachten Host
|
||||
|
||||
Projekt auch dort nach `/opt/dilib-dashboard` kopieren:
|
||||
|
||||
```bash
|
||||
cd /opt/dilib-dashboard
|
||||
sudo bash scripts/install-agent.sh
|
||||
sudoedit /etc/dilib-agent/agent.env
|
||||
sudo systemctl enable --now dilib-agent
|
||||
sudo journalctl -u dilib-agent -n 50 --no-pager
|
||||
```
|
||||
|
||||
`DASHBOARD_URL=https://Ihre-Domain/api/ingest/`, `AGENT_TOKEN` sowie lokale
|
||||
`AGENT_HEALTH_URLS` anpassen. JSON in der env-Datei unverändert als eine Zeile eintragen.
|
||||
Nicht vorhandene Flower-Instanzen durch leeres `AGENT_FLOWER_URL=` deaktivieren.
|
||||
Interne Zertifizierungsstelle: PEM-Dateipfad in `AGENT_CA_BUNDLE` für Dashboard-Uploads.
|
||||
Für lokale HTTPS-Gesundheitsprüfungen muss die CA im Systemvertrauen installiert sein.
|
||||
|
||||
Pro unabhängigem Celery-Broker genau auf einem Agenten:
|
||||
|
||||
```ini
|
||||
AGENT_COLLECT_EVENTS=1
|
||||
AGENT_BROKER_URL=redis://127.0.0.1:6379/0
|
||||
AGENT_COLLECTOR_ID=dilib-monitor-production
|
||||
```
|
||||
|
||||
Auf allen anderen Agenten `AGENT_COLLECT_EVENTS=0`. Für RabbitMQ ist eine passende
|
||||
`amqp://`-URL möglich. Zugangsdaten nur lokal speichern. Bei mehreren Brokern eigene
|
||||
Agentinstanzen mit separaten registrierten Namen, Spool-Dateien und Umgebungen anlegen.
|
||||
|
||||
In den überwachten Django/Celery-Projekten (bei Namespace CELERY) konfigurieren:
|
||||
|
||||
```python
|
||||
CELERY_WORKER_SEND_TASK_EVENTS = True
|
||||
CELERY_TASK_SEND_SENT_EVENT = True
|
||||
CELERY_TASK_TRACK_STARTED = True
|
||||
```
|
||||
|
||||
Anschließend dortige Worker regulär neu starten. Alternativ Worker mit `-E` starten.
|
||||
Der Agent aktiviert Events nicht eigenständig per Remote-Control.
|
||||
|
||||
## 5. Flower dauerhaft speichern
|
||||
|
||||
Bestehendes Flower mit `deploy/flowerconfig.py` konfigurieren oder den mitgelieferten
|
||||
Dienst nutzen. Nur eine Flower-Instanz darf dieselbe Zustandsdatei schreiben.
|
||||
|
||||
```bash
|
||||
cd /opt/dilib-dashboard
|
||||
sudo .venv-agent/bin/pip install 'flower==2.2.0'
|
||||
sudo install -m 640 -o root -g dilib-agent deploy/flower.env.example /etc/dilib-agent/flower.env
|
||||
sudoedit /etc/dilib-agent/flower.env
|
||||
sudo install -m 644 deploy/systemd/dilib-flower.service /etc/systemd/system/
|
||||
sudo systemctl daemon-reload
|
||||
sudo systemctl enable --now dilib-flower
|
||||
```
|
||||
|
||||
Broker und `FLOWER_BASIC_AUTH` setzen. Im Agenten dieselben Flower-Zugangsdaten setzen.
|
||||
Flower bindet auf 127.0.0.1:5555, speichert alle 10 Sekunden unter
|
||||
`/var/lib/dilib-flower/flower` und hält maximal 100.000 Tasks im lokalen Zustand.
|
||||
Diese Dateipersistenz ist unabhängig von der PostgreSQL-Aufbewahrung des Dashboards.
|
||||
Nach Änderung `sudo systemctl restart dilib-agent` ausführen.
|
||||
|
||||
## 6. dilibAI optional
|
||||
|
||||
`DILIBAI_BASE_URL` inklusive API-Präfix (z.B. `https://ki.intern/v1`),
|
||||
`DILIBAI_API_KEY` und `DILIBAI_MODEL` setzen; API-Dienst neu starten.
|
||||
Der Adapter sendet maximal 30 offene Alarmzusammenfassungen an `/chat/completions`.
|
||||
Ein proprietärer dilibAI-Endpunkt benötigt eine Anpassung von `monitoring/views.py`.
|
||||
Es werden keine Task-Argumente oder Ergebnisse übertragen. KI führt keine Aktionen aus.
|
||||
|
||||
## Lokaler Entwicklungstest
|
||||
|
||||
```bash
|
||||
python3 -m venv .venv
|
||||
.venv/bin/pip install -r requirements-dev.txt
|
||||
.venv/bin/pytest -q
|
||||
```
|
||||
|
||||
Die Tests verwenden SQLite und ersetzen externe Dienste durch Mocks.
|
||||
Für eine manuelle lokale Demo `.env.example` nach `.env` kopieren, Secrets generieren,
|
||||
`TEST_SQLITE=1`, `COOKIE_SECURE=0` und `DEBUG=1` ergänzen; `var` anlegen.
|
||||
Mit `.venv/bin/python manage.py migrate`, `createsuperuser` und `seed_demo` vorbereiten.
|
||||
In zwei Terminals `manage.py runserver 127.0.0.1:8000` und
|
||||
`.venv/bin/python -m frontend.main` starten. UI: http://127.0.0.1:8080.
|
||||
Demo-Daten nie in die produktive Datenbank laden.
|
||||
@@ -0,0 +1,72 @@
|
||||
# Betrieb, Abnahme und Wiederherstellung
|
||||
|
||||
## Abnahme in Ihrer Infrastruktur
|
||||
|
||||
1. Anmeldung als Leser und Operator prüfen; Leser dürfen keine Alarme quittieren.
|
||||
2. Einen echten Agenten und Collector anbinden; Host, Worker und Testtask kontrollieren.
|
||||
3. HTTPS-Verbindung des Agenten kurz sperren: Outbox wächst. Wieder öffnen:
|
||||
Daten werden nachgeliefert, keine doppelten UUIDs. Alte Samples bleiben als alt erkennbar.
|
||||
4. Agent mit gefüllter Outbox neu starten und Nachlieferung prüfen.
|
||||
5. Django/UI und Flower separat neu starten. Historie im Dashboard und Flower prüfen.
|
||||
6. Host-Heartbeat unterbrechen; nach Timeout und Alarmzyklus Alarm prüfen.
|
||||
7. SMTP-Zustellung, Wiederholungen, Quittierung und automatische Auflösung prüfen.
|
||||
8. Datenbanksicherung in separater Datenbank wiederherstellen und Stichproben vergleichen.
|
||||
9. Mit erwarteter Host-/Task-Menge einen Lasttest ausführen; Aufbewahrung passend dimensionieren.
|
||||
10. Browser auf Desktop und Mobilgerät, TLS und WebSocket-Verbindung hinter Nginx prüfen.
|
||||
|
||||
## Diagnostik
|
||||
|
||||
```bash
|
||||
sudo systemctl status dilib-api dilib-ui dilib-worker dilib-beat
|
||||
sudo journalctl -u dilib-api -u dilib-ui -n 100 --no-pager
|
||||
sudo journalctl -u dilib-agent -n 100 --no-pager
|
||||
```
|
||||
|
||||
Keine Werte: Token, HTTPS-Verbindung, Systemzeit/NTP und Agentlog prüfen.
|
||||
Keine Tasks: Broker-URL und aktivierte Celery-Events prüfen; Collector muss laufen.
|
||||
Keine Mails: Beat, Worker, SMTP und Empfängerliste prüfen.
|
||||
Flower offline: lokale URL, Authentifizierung und Dienst prüfen.
|
||||
Dauerhafter HTTP-400 beim Upload: invaliden Payload in der Outbox untersuchen;
|
||||
Agent blockiert den Batch absichtlich und löscht keine Daten ungeprüft.
|
||||
|
||||
## Backup
|
||||
|
||||
```bash
|
||||
sudo -u postgres bash /opt/dilib-dashboard/scripts/backup.sh /var/lib/postgresql/dilib-backups
|
||||
```
|
||||
|
||||
Zusätzlich geschützt sichern: `/etc/dilib-dashboard`, `/etc/dilib-agent`,
|
||||
`/var/lib/dilib-dashboard` und Flower-Dateien. SQLite-Outbox nur bei gestopptem
|
||||
Agenten vollständig kopieren (einschließlich WAL-Dateien) oder SQLite-Backup-API nutzen.
|
||||
Flower vor Kopie seines Dateistands stoppen. Backups verschlüsselt extern aufbewahren.
|
||||
Automatische Backupplanung und externe Ausfallüberwachung betreiberseitig einrichten.
|
||||
|
||||
Wiederherstellung zunächst in separate DB:
|
||||
|
||||
```bash
|
||||
sudo -u postgres createdb --owner=dilib dilib_restore_test
|
||||
sudo -u postgres pg_restore --no-owner --role=dilib --dbname=dilib_restore_test /pfad/backup.dump
|
||||
```
|
||||
|
||||
Für Umschaltung Dienste stoppen, DATABASE_URL auf geprüfte Wiederherstellung setzen,
|
||||
Migration prüfen und Dienste wieder starten. Keine laufende DB blind überschreiben.
|
||||
Nach Datenverlust können bereits bestätigte Agentenevents nicht erneut aus der Outbox
|
||||
rekonstruiert werden; RPO richtet sich nach Backup/WAL-Archivierungsstrategie.
|
||||
|
||||
## Updates
|
||||
|
||||
Backup anfertigen, Änderungen zuerst in Testumgebung prüfen, Dienste stoppen,
|
||||
Code aktualisieren, Requirements installieren, Migration und collectstatic ausführen,
|
||||
Dienste starten und Abnahmetests wiederholen. Getestete Paketstände stehen in
|
||||
`requirements.txt`; Versionsbereiche für bewusste Updates in `requirements.in`.
|
||||
|
||||
## Lokale Prüfungen dieser Lieferung
|
||||
|
||||
Prüfstand und Testanzahl: siehe VALIDATION.md. Tests umfassen: Authentifizierung und Ablauf, Rate Limit, Rollen, Batchvalidierung,
|
||||
Idempotenz, verspätete Task-Events, veraltete Hostwerte, Alarme/Quittierung,
|
||||
Retention, SMTP-Wiederholung, API/CSV/PNG sowie persistente Agent-Outbox/Redaktion.
|
||||
Tests liefen mit SQLite; PostgreSQL-Sperrverhalten und externe Integrationen sind
|
||||
nicht durch diesen lokalen Testlauf nachgewiesen.
|
||||
|
||||
Die NiceGUI-Anwendung startete lokal ohne Startfehler. Eine visuelle Browserabnahme
|
||||
war hier mangels verfügbarer Browserinstallation nicht möglich.
|
||||
@@ -0,0 +1,30 @@
|
||||
# Prüfstand 1.1
|
||||
|
||||
Lokale Prüfung am 09.11.2026 unter Python 3.12:
|
||||
|
||||
- 19 pytest-Tests bestanden (6,40 Sekunden).
|
||||
- Django system check ohne Fehler.
|
||||
- makemigrations --check --dry-run: keine fehlenden Migrationen.
|
||||
- pip check: keine widersprüchlichen installierten Abhängigkeiten.
|
||||
- Python-Dateien kompilierbar, Shellskripte mit bash -n geprüft.
|
||||
- Apache-/Nginx-Konfigurationen aus beiden Vorlagen erfolgreich erzeugt.
|
||||
- NiceGUI-Navigation mit User-Simulation getestet; keine visuelle Browserabnahme.
|
||||
|
||||
Die Datenbanktests liefen lokal mit SQLite. Echte PostgreSQL-Integration, Redis,
|
||||
Celery-Worker, Flower-Neustart, SMTP, Reverse-Proxy/TLS und dilibAI wurden hier
|
||||
nicht Ende-zu-Ende ausgeführt. Es wurden keine Produktionsserver verändert.
|
||||
|
||||
Für PostgreSQL eine separate Testdatenbank und einen Testbenutzer mit CREATEDB
|
||||
verwenden (pytest erzeugt und entfernt seine Testdatenbank):
|
||||
|
||||
```bash
|
||||
export DATABASE_URL='postgresql://TESTBENUTZER:PASSWORT@127.0.0.1:5432/dashboard_test'
|
||||
export CACHE_URL='redis://127.0.0.1:6379/6'
|
||||
.venv/bin/pytest --ds=config.postgres_test_settings -q
|
||||
```
|
||||
|
||||
Den PostgreSQL-Testlauf nicht mit Produktionszugangsdaten ausführen. Die beigefügte
|
||||
GitHub-Actions-Konfiguration richtet einen eigenen PostgreSQL-Testdienst ohne
|
||||
Docker ein. Dieser CI-Lauf wurde hier nicht ausgeführt. Für die laufenden Dienste
|
||||
steht `manage.py doctor --workers` zur Verfügung; die Betriebsabnahme ist in
|
||||
OPERATIONS.md beschrieben.
|
||||
Reference in New Issue
Block a user