glitchtip: pin image to 6.1.6 for reproducibility; HANDOFF observability complete
This commit is contained in:
+1
-1
@@ -39,7 +39,7 @@ Branch `main`. Took backlog item 2. Design-first: owner chose self-hosted Glitch
|
||||
|
||||
**Deployed (`c89e4d9`, run 26260262561 success); inert in prod** (`SENTRY_DSN` unset). Phase 1 was a safe no-behavior-change deploy.
|
||||
|
||||
**Phase 2 = a REPRODUCIBLE repo artifact, not droplet surgery (owner steer).** Instead of hand-building containers on the specific droplet, the GlitchTip backend is now committed at `deploy/glitchtip/` (`docker-compose.yml` + `.env.example` + README), self-contained (its OWN Postgres + Redis, shares nothing with the app stack), `127.0.0.1`-bound, memory-capped, one-command `docker compose up -d` (migrate runs first via `service_completed_successfully`). Any self-hoster gets it the same way; the app stays generic (`SENTRY_DSN` works with this OR Sentry SaaS OR nothing). A 2GB swapfile was added to the production droplet (was RAM-tight: 3.8G, no swap) + persisted in fstab. **Phase 2 is now LIVE on prod:** the GlitchTip stack runs from `/opt/hackerspace-ops/deploy/glitchtip` bound to `127.0.0.1:8100` (port 8100 not 8000 to avoid Supabase Kong; the committed compose default was fixed to 8100 in `ad4b9f5`), web/worker/redis/postgres healthy, ~2.3G RAM available + light swap. `SENTRY_DSN=http://<key>@localhost:8100/1` is set in `.env.production`, app restarted. Ingest proven: a verification event POSTed in the seam's exact request shape returned HTTP 200 + an event id (so DSN + auth + event format + GlitchTip ingest all work; the app uses the identical request from `buildEvent`, so real server errors now land automatically). Open registration locked off (`ENABLE_OPEN_USER_REGISTRATION=False`). Dashboard viewed via SSH tunnel `-L 8100:127.0.0.1:8100`. A first hand-rolled bring-up attempt was scrapped after a psql-quoting bug; the committed compose superseded it. Observability item 2 = DONE (both phases).
|
||||
**Phase 2 = a REPRODUCIBLE repo artifact, not droplet surgery (owner steer).** Instead of hand-building containers on the specific droplet, the GlitchTip backend is now committed at `deploy/glitchtip/` (`docker-compose.yml` + `.env.example` + README), self-contained (its OWN Postgres + Redis, shares nothing with the app stack), `127.0.0.1`-bound, memory-capped, one-command `docker compose up -d` (migrate runs first via `service_completed_successfully`). Any self-hoster gets it the same way; the app stays generic (`SENTRY_DSN` works with this OR Sentry SaaS OR nothing). A 2GB swapfile was added to the production droplet (was RAM-tight: 3.8G, no swap) + persisted in fstab. **Phase 2 is now LIVE on prod:** the GlitchTip stack runs from `/opt/hackerspace-ops/deploy/glitchtip` bound to `127.0.0.1:8100` (port 8100 not 8000 to avoid Supabase Kong; the committed compose default was fixed to 8100 in `ad4b9f5`), web/worker/redis/postgres healthy, ~2.3G RAM available + light swap. `SENTRY_DSN=http://<key>@localhost:8100/1` is set in `.env.production`, app restarted. Ingest proven: a verification event POSTed in the seam's exact request shape returned HTTP 200 + an event id (so DSN + auth + event format + GlitchTip ingest all work; the app uses the identical request from `buildEvent`, so real server errors now land automatically). Open registration locked off (`ENABLE_OPEN_USER_REGISTRATION=False`). Dashboard viewed via SSH tunnel `-L 8100:127.0.0.1:8100`. Verified in the GlitchTip UI: issue SH-1 `VerificationError` with tags `surface=phase2-verify` / `environment=production` (running GlitchTip 6.1.6). The committed compose image is now PINNED to `glitchtip/glitchtip:6.1.6` (was `latest`) for reproducibility. A first hand-rolled bring-up attempt was scrapped after a psql-quoting bug; the committed compose superseded it. Observability item 2 = DONE (both phases).
|
||||
|
||||
---
|
||||
|
||||
|
||||
Reference in New Issue
Block a user