265ca8ac38
All checks were successful
Container-Image bauen und veröffentlichen / build-and-push (push) Successful in 5m15s
62 lines
4.6 KiB
Markdown
62 lines
4.6 KiB
Markdown
# Betrieb und technische Abnahme
|
|
|
|
Stand: 14.09.2026. Die fachliche Freigabe durch den DSB und die vollständige manuelle Barrierefreiheitsprüfung sind getrennte Abnahmen.
|
|
|
|
## Geprüfter Stand
|
|
|
|
- Sechs Unit-/Integrationstests einschließlich Backup, Wiederherstellung und Überschreibschutz erfolgreich.
|
|
- Acht Browser-/API-Tests gegen den gebauten Standalone-Server erfolgreich.
|
|
- TypeScript, ESLint und beide npm-Audits ohne Fehler bzw. bekannte Schwachstellen.
|
|
- Aktueller Docker-Datenbestand gesichert und getrennt wiederhergestellt: 120 Erklärungen, ein Konto, ein Standardtext-Datensatz und ein Seitentext-Datensatz.
|
|
- Die Sicherung liegt lokal unter backups/abschluss-20260914.db und zusätzlich im Docker-Datenvolume unter /app/data/backups/abschluss-20260914.db. backups/ ist von Git und Docker-Builds ausgeschlossen.
|
|
|
|
## Backup
|
|
|
|
Das Werkzeug erstellt mit SQLite VACUUM INTO einen konsistenten Snapshot, auch während die Anwendung läuft. Es prüft die SQLite-Integrität und die vier Anwendungstabellen. Bestehende Zieldateien werden abgewiesen. Ein Backup enthält personenbezogene Inhalte und Passwort-Hashes; Zugriff auf berechtigte Administratoren begrenzen und für eine externe Ablage verschlüsseln.
|
|
|
|
Beispiel (Dateiname für jede Sicherung ändern):
|
|
|
|
```sh
|
|
docker exec syncova-policies node scripts/database-backup.js backup /app/data/backups/sicherung-20260914.db
|
|
docker cp syncova-policies:/app/data/backups/sicherung-20260914.db ./backups/sicherung-20260914.db
|
|
```
|
|
|
|
Der Hostordner backups muss vorher existieren. Eine Kopie auf demselben Rechner schützt nicht vor Verlust des Rechners. Ein externes Sicherungsziel und eine tägliche Ausführung müssen auf dem tatsächlichen Produktionshost eingerichtet werden; sie sind lokal noch nicht automatisiert. Auch vor jedem Update sichern. NEXTAUTH_SECRET und die Betriebs-Konfiguration separat im vorgesehenen Secret-/Passwortspeicher sichern; sie sind nicht Bestandteil des Datenbankbackups.
|
|
|
|
## Wiederherstellung prüfen
|
|
|
|
```sh
|
|
docker exec syncova-policies node scripts/database-backup.js verify /app/data/backups/sicherung-20260914.db
|
|
docker exec syncova-policies node scripts/database-backup.js restore /app/data/backups/sicherung-20260914.db /tmp/wiederherstellung.db
|
|
```
|
|
|
|
Der zweite Befehl erzeugt ausschließlich eine neue Datei und schaltet den laufenden Dienst nicht um. Für eine echte Wiederherstellung:
|
|
|
|
1. Dienst stoppen und aktuellen Zustand zusätzlich sichern.
|
|
2. Backup in ein neues Datenvolume übernehmen; Integrität mit dem Werkzeug prüfen.
|
|
3. Eigentümer UID/GID 1001:1001 für Datenbank und Datenverzeichnis sicherstellen.
|
|
4. Compose auf das neue Volume und das zum Backup passende Image umstellen; NEXTAUTH_SECRET beibehalten.
|
|
5. Dienst starten, Migrationen und Healthcheck kontrollieren; Anmeldung, Erklärungen und Seitentexte prüfen.
|
|
6. Altes Volume bis zur abgeschlossenen Abnahme behalten. Keine laufende SQLite-Datei überschreiben; WAL-/SHM-Dateien aus dem alten Zustand nicht mit dem Backup mischen.
|
|
|
|
## Veröffentlichung und Updates
|
|
|
|
Der Workflow .gitea/workflows/publish-image.yml prüft Code, Abhängigkeiten und Produktions-Browsertests, bevor er das Image baut. Pushes auf main veröffentlichen latest und einen kurzen Commit-Hash unter git.jfritzsche.de/jf/syncova-policies. REGISTRY_TOKEN muss als Gitea-Actions-Secret mit Schreibrecht auf die Registry vorhanden sein.
|
|
|
|
Produktiv möglichst den geprüften Commit-Tag oder Digest festlegen. Ein vorheriges Image allein ist kein sicherer Rollback nach einer nicht rückwärtskompatiblen Datenbankmigration; dafür auch die passende Sicherung verwenden.
|
|
|
|
Die lokale Testinstanz läuft auf http://localhost:3001. Der Entwicklungsserver nutzt Port 3000. Die lokale Portumstellung erfolgte als Compose-Override, die Standarddatei verwendet weiterhin Port 3000. Ein unverändertes docker compose up kann deshalb lokal einen Portkonflikt verursachen.
|
|
|
|
## Abnahmeliste für den Produktionshost
|
|
|
|
- HTTPS, Domain und Reverse-Proxy-Header prüfen.
|
|
- Dauerhaftes Datenvolume und stabiles NEXTAUTH_SECRET sicherstellen.
|
|
- Anmeldung mit berechtigtem Konto, Sperrung und Abmeldung prüfen.
|
|
- Erklärungen zählen, Stichproben öffnen und Seitentexte/Video kontrollieren.
|
|
- Externe Sicherung und tägliche Ausführung einrichten; Wiederherstellung regelmäßig proben.
|
|
- Healthcheck und Fehlerlogs überwachen.
|
|
- DSB-Freigabe sowie manuelle Screenreader-, Leichte-Sprache- und Videoprüfung dokumentieren.
|
|
- Barrierefreiheitserklärung um bestätigten Status und konkrete Restbarrieren ergänzen.
|
|
|
|
Automatisierte Tests bestätigen keine vollständige rechtliche oder technische Barrierefreiheit. Die lokale Sicherung und die lokale Docker-Instanz sind keine Prüfung des entfernten Produktionsservers.
|