Neuere Fassungen von edoburu/pgbouncer lauschen auf 5432 statt auf 6432. Der
Dienst lief damit einwandfrei, aber der Healthcheck fragte 6432 ab, blieb ohne
Antwort und meldete "unhealthy" - woraufhin web und worker gar nicht erst
starteten. DATABASE_URL haette danach dasselbe Problem gehabt.
LISTEN_PORT steht jetzt fest auf 6432. Das haelt ausserdem sichtbar
auseinander, ob eine Verbindung ueber den Pool geht oder mit
DIRECT_DATABASE_URL an ihm vorbei.
Wer die Anwendung auf einem anderen Port erreichen will, musste bisher die
compose.yaml aendern - eine verfolgte Datei. Jeder `git pull` lief danach in
"local changes would be overwritten", und die Aenderung ging beim Verwerfen
verloren.
Jetzt steht der Host-Port als WEB_PORT in der .env, die ohnehin nicht verfolgt
wird. Ohne Angabe bleibt es bei 3000.
Der Tunnel war fest im Stack und damit Voraussetzung, obwohl er nur eine von
mehreren Moeglichkeiten ist, die Anwendung von aussen erreichbar zu machen. Wer
einen eigenen Reverse Proxy betreibt, brauchte ihn nie - und wollte womoeglich
gerade nicht von einem fremden Dienst abhaengen.
Er steht jetzt in einem Profil und startet nur mit
`docker compose --profile cloudflare up -d`. Ohne Angabe bleibt er aus, und der
Stack laeuft mit acht Diensten.
`docker compose up` fragt zuerst in einer Registry nach, auch wenn das Image
lokal gebaut wird, und warnt dann "pull access denied". Mit `pull_policy: never`
nimmt Compose gleich das lokale Image.
Betrifft vor allem den Start-Knopf in Dockge, der `up -d` ohne vorheriges
`build` ausfuehrt.
Die drei eigenen Images standen als ghcr.io-Adressen mit einem Platzhalter im
Namen. Gebaut haetten sie nur GitHub Actions, und das Repository liegt nicht
auf GitHub - die Images gab es also nirgends, und wer den Platzhalter uebersah,
bekam "repository name must be lowercase".
Jetzt stehen die Bau-Anweisungen in der compose.yaml selbst. Das ist auch fuer
Dockge das richtige: dessen Editor zeigt nur diese eine Datei, eine
compose.override.yml waere unsichtbar gewesen und haette spaeter niemand mehr
erklaeren koennen.
Dazu ein Hinweis im Kopf der Datei, dass PORT und Healthchecks den Port *im*
Container meinen. Wer die Anwendung auf dem Host anders erreichen will, aendert
nur die linke Zahl bei ports.
compose.yaml aus docs/11-betrieb.md, ergänzt um Healthchecks für db-backup und
offsite-backup. Das Dokument verlangt für jeden Dienst einen, die abgedruckte
Fassung hatte für die beiden keinen, und ohne ihn zeigt Dockge nur "läuft",
auch wenn seit Wochen nichts mehr gesichert wird.
Die Migration läuft im Startkommando von web, nicht in einem Init-Container.
Die Prisma-CLI samt Schema-Engine liegt dafür unter /app/migrator im Image:
ein Container, der nur startet, wenn gerade eine Registry erreichbar ist, wäre
auf einem Homeserver die falsche Bauart.
Alle drei Images gebaut und laufen gegen eine echte Postgres-Instanz geprüft:
web wendet Migrationen an und liefert /api/health aus, worker schreibt sein
Lebenszeichen, pdf rendert ein echtes PDF.
Die CI prüft Lint, Typen, Tests und E2E gegen den Standalone-Server, also so,
wie der Container startet, und hält das Bündel-Budget aus
docs/09-performance-und-ux.md ein.
Phase 0 aus TASKS.md ist damit abgehakt.
Harlekin