feat(deploy): Update und Sicherung fuer beide Installationsarten (#031)
Prüfung / pruefung (push) Canceled after 0s
Prüfung / pruefung (push) Canceled after 0s
deploy/update.sh und deploy/backup.sh konnten nur Docker. Beide erkennen die Installationsart jetzt selbst und beherrschen auch die Installation als Dienst: npm ci, prisma migrate deploy, bauen, systemctl restart - und pg_dump ueber DATABASE_URL fuer die Sicherung. Beim Durchspielen gegen einen laufenden Stapel zwei Fehler gefunden: 1. Die Zustandspruefung des Web-Containers konnte nie gelingen. Next bindet im Standalone-Modus an die Adresse aus HOSTNAME, und Docker setzt dort den Containernamen - der Server lauschte nur auf der Container-IP. Der Dienst web blieb dauerhaft auf "health: starting". Behoben mit ENV HOSTNAME=0.0.0.0; geprueft wird jetzt ueber 127.0.0.1. 2. Eine fehlgeschlagene Sicherung hielt die Aktualisierung nicht auf. Jetzt bricht sie ab, bevor etwas veraendert wird, und nennt die Auswege. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit is contained in:
@@ -0,0 +1,33 @@
|
||||
# #031 Update- und Sicherungsskript für beide Installationsarten
|
||||
**Status:** erledigt
|
||||
**Meilenstein:** v0.20.0
|
||||
**Labels:** deployment
|
||||
**Geschätzt:** 2 h **Tatsächlich:** 0 h 45 min
|
||||
|
||||
## Ziel
|
||||
`deploy/update.sh` und `deploy/backup.sh` konnten nur Docker. Die Installation als Dienst (Node und
|
||||
PostgreSQL direkt im LXC) ging leer aus – dort half nur der Weg über das Gerüst der community-scripts.
|
||||
|
||||
## Aufgaben
|
||||
- [x] Beide Skripte erkennen die Installationsart selbst (systemd-Dienst oder Docker)
|
||||
- [x] Dienst-Weg: `npm ci`, `prisma migrate deploy`, bauen, `systemctl restart`
|
||||
- [x] Sicherung für den Dienst-Weg: `pg_dump` über `DATABASE_URL`, Uploads aus `UPLOAD_DIR`
|
||||
- [x] Fehlgeschlagene Sicherung bricht die Aktualisierung ab – **vor** jeder Änderung
|
||||
- [x] Hinweis am Ende von `deploy/lxc-installer.sh` auf die Skripte umgestellt
|
||||
- [x] Handbuch und Betriebsdoku angepasst
|
||||
- [x] Docker-Weg vollständig durchgespielt
|
||||
|
||||
## Zwei Fehler beim Durchspielen gefunden
|
||||
1. **Die Zustandsprüfung des Web-Containers konnte nie gelingen.** Next bindet im Standalone-Modus an
|
||||
die Adresse aus `HOSTNAME` – und Docker setzt darin den Containernamen. Der Server lauschte also
|
||||
nur auf der Container-IP, nicht auf `127.0.0.1`. Der Dienst `web` blieb dauerhaft auf
|
||||
„health: starting“; von außen war er trotzdem erreichbar, deshalb fiel es bisher nicht auf.
|
||||
Behoben mit `ENV HOSTNAME=0.0.0.0` im Dockerfile; die Prüfungen verwenden jetzt `127.0.0.1`
|
||||
statt `localhost` (das löst im Container auch auf `::1` auf).
|
||||
2. **Die Sicherung scheiterte stumm an fehlenden Rechten** (`/var/backups` gehört root) und die
|
||||
Aktualisierung lief trotzdem weiter. Jetzt bricht sie ab und nennt die drei Auswege.
|
||||
|
||||
## Prüfung
|
||||
Vollständiger Durchlauf gegen einen laufenden Stapel: Sicherung (Datenbank 6,3 KB mit 25 Tabellen,
|
||||
Uploads, `.env`), Abbilder gebaut, migriert, neu gestartet, Dashboard nach zwei Sekunden wieder da.
|
||||
Danach stand `web` zum ersten Mal auf **healthy**.
|
||||
Reference in New Issue
Block a user