Die Oberflaeche legt einen Vorgang an und schickt nur dessen ID in die Warteschlange; der Worker fuehrt ihn aus und haelt Status, Ergebnis oder Fehler fest. So bleiben lange SSH-Vorgaenge aus dem Webprozess heraus, und der Fortschritt ist ohne Job-Interna sichtbar. Kein automatisches Wiederholen: ein halb ausgefuehrter Schreibvorgang auf einem Host gehoert vor einen Menschen. Fehlertexte aus fremden Bibliotheken erreichen die Oberflaeche nie. Dockerfile und Compose fuer den Betrieb: Master-Key als Secret nur im Worker, Datenbank in einem internen Netz. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
1.5 KiB
1.5 KiB
#007 Worker und Vorgänge
Status: erledigt Meilenstein: v0.1.0 Labels: backend Geschätzt: 3 h Tatsächlich: 0 h 15 min
Ziel
Eigener Worker-Prozess mit pg-boss; die Oberfläche legt Vorgänge an und zeigt deren Fortschritt.
Aufgaben
- Worker-Einstieg, gebündelt per esbuild
- pg-boss-Queues je Vorgangsart, Zeitpläne
- Modell
Vorgangfür Status/Ergebnis in der Oberfläche - Docker-Compose produktiv: web, worker, db, migrate; Master-Key nur im Worker
Akzeptanzkriterien
- Vorgang wird im Web angelegt, im Worker ausgeführt, Ergebnis sichtbar
Abhängigkeiten
#003
Notizen / Entscheidungen
- Eine Warteschlange
sshkv-vorgangstatt einer je Art: Der Job trägt nur die Vorgangs-ID; die Art steht imVorgang. Eine Handler-Tabelle (src/worker/handler.ts) wächst mit den Issues. - Kein automatisches Wiederholen (
retryLimit: 0): Ein halb ausgeführter Schreibvorgang auf einem Host soll ein Mensch ansehen. - Start nur aus WARTEND per bedingtem Update – zugleich die Sperre gegen doppelte Ausführung.
- Fehlermeldungen: Nur
VorgangsFehlererreichen die Oberfläche, alles andere wird „Interner Fehler“; ins Log nur Name und Meldung. - Compose: Datenbank in einem
internal-Netz; Master-Key als Secret ausschließlich im Worker. Docker-Secrets ohne Swarm sind Bind-Mounts mit den Rechten der Host-Datei – deshalbchown 1001:1001undchmod 400(siehe Kopf vondocker-compose.yml).