Jinemi/thermograph
4
0
Fork 0
Code Issues 2 Pull requests 9 Projects Releases Packages Wiki Activity Actions
thermograph/infra/README.md
Emi Griffith df409f88b3
All checks were successful
PR build (required check) / changes (pull_request) Successful in 6s
Details
secrets-guard / encrypted (pull_request) Successful in 4s
Details
shell-lint / shellcheck (pull_request) Successful in 6s
Details
PR build (required check) / validate-observability (pull_request) Successful in 20s
Details
PR build (required check) / build-frontend (pull_request) Successful in 37s
Details
PR build (required check) / build-backend (pull_request) Successful in 51s
Details
PR build (required check) / gate (pull_request) Successful in 1s
Details
registry: move image and repo references to the Jinemi namespace 
Repos moved to the Jinemi org; the container packages did not follow, since
Forgejo does not transfer packages with a repo. The deploy path still resolved
`emi/thermograph/*` — a user_redirect to admin_emi — while build-push.yml
derives its push path from ${github.repository}, now jinemi/thermograph. The
next backend or frontend build would have published somewhere no deploy looks.

Point the image paths at jinemi/thermograph/* (lowercase: OCI references admit
no uppercase, which is why build-push.yml already pipes through tr), the clone
URLs at Jinemi/thermograph, and the registry logins at admin_emi — the account
that actually owns the tokens, rather than the redirect.

The live tags and both ci-runner tags were copied into the Jinemi namespace
first, so the switch has something to pull. thermograph-infra,
thermograph-observability and the retired */app packages stay under admin_emi;
they did not move.
2026-08-01 09:25:02 -07:00

4.7 KiB
Raw Blame History

infra/

Infrastructure for Thermograph: Terraform host provisioning, the SOPS+age secrets vault, WireGuard/Swarm networking, Forgejo, Caddy, mail, and the deploy scripts that run the already-built app images on each host. This is a domain of the Jinemi/thermograph monorepo — a host's checkout (/opt/thermograph, /opt/thermograph-beta, or /opt/thermograph-dev) is a checkout of the whole monorepo, and infra/ never builds app source; it only runs published images.

  • terraform/ — provisions/configures hosts (SSH-driven by default; an optional GCP-creating module is scaffolded, no live resources yet). See terraform/README.md. No tfstate is persisted anywhere — treat apply as executable documentation, not a routine operation.
  • deploy/secrets/ — the git-native SOPS+age secrets vault (every app secret, encrypted at rest, rendered at deploy time). See deploy/secrets/README.md.
  • deploy/swarm/, deploy/forgejo/ — the WireGuard/Swarm mesh spanning vps1, vps2 and the desktop, and Forgejo (git + CI + registry), pinned to vps1. See ACCESS.md.
  • deploy/env-topology.sh — the single source of truth for where each environment (dev/beta/prod) lives: host, checkout path, branch, deploy mode, stack/compose name, env file, LB ports, DB role/database, service-name prefix. Every deploy path sources it and derives its behavior from it rather than guessing from the host it happens to be running on — necessary since vps2 alone now runs two environments.
  • deploy/deploy.sh — the single deploy entry point for dev, beta and prod. Takes SERVICE=backend|frontend|all plus BACKEND_IMAGE_TAG/FRONTEND_IMAGE_TAG (and, on vps2, THERMOGRAPH_ENV=beta|prod to say which of the two checkouts it's acting on), resets the host checkout, renders secrets, and routes to the right orchestrator per env-topology.sh.
  • deploy/deploy-dev.sh — a thin dev-specific wrapper around deploy.sh (dev compose overlay, dev's secrets policy). See DEPLOY-DEV.md.
  • deploy/stack/ — the Swarm path, live on vps2 for both prod and beta: thermograph-stack.yml (prod: db, web, worker, lake, daemon, frontend, autoscaler, autoscaler-lake) and thermograph-beta-stack.yml (beta: the same service shape minus db and the autoscalers, every service name prefixed beta-). deploy-stack.sh, autoscale.sh and lb/ are shared by both. Rolling updates are start-first, health-gated, with auto-rollback. STACK_TEST=1 rehearses the whole stack on throwaway volumes and ports.
  • docker-compose*.yml — the compose path, live only on dev (vps1) (db, backend, lake, daemon, frontend). docker-compose.dev.yml is dev's mesh-only overlay; docker-compose.openmeteo.yml is the self-hosted Open-Meteo overlay (prod only). make dev-up also runs this path locally as a laptop convenience — that is not an "environment", just a local rehearsal.

Which path an environment takes is decided by deploy/env-topology.sh (TG_DEPLOY_MODE, keyed by dev/beta/prod): dev is compose, beta and prod are both stack. The old host-wide marker /etc/thermograph/deploy-mode still exists as a fallback for a by-hand run with no explicit environment, but it cannot describe vps2, which runs two environments in two different checkouts — so it is no longer the thing that decides where files go. The workflows never need to know which mode an environment runs; they only pass THERMOGRAPH_ENV.

Branches & how changes reach each environment

  • dev — deploys to dev on vps1 (/opt/thermograph-dev).
  • main — deploys to beta on vps2 (/opt/thermograph-beta).
  • release — deploys to prod on vps2 (/opt/thermograph).

App code IS environment-staged this way (dev→main→release maps to vps1/dev → vps2/beta → vps2/prod via image tags, one Deploy workflow keyed by branch). Infra itself is not environment-staged the same way: infra-sync.yml fires on a push touching infra/** — on dev it fast-forwards vps1's dev checkout, on main it fast-forwards both of vps2's checkouts (beta and prod) — re-rendering each environment's own env file from the vault. It deliberately does not roll any service: image tags are the app domains' axis, not infra's. A compose or stack change that must recreate containers takes effect on the next app deploy, or a by-hand SERVICE=all … deploy/deploy.sh (or deploy-dev.sh) run.

Note the asymmetry this leaves: dev's infra checkout tracks dev, the same branch its app images are staged by. Beta's and prod's infra checkouts both track main — prod's app images are staged by release, but prod's infra checkout follows main, same as beta's.