fisher
952de1ea8e
The health router is mounted at prefix="/api" in domaindingo's main.py, so /health 404s. Checking it would have failed every deploy and rolled back a perfectly good image. Also adopts three conventions from the vault's DomainDingo Development note: recreate a single named service (--no-deps --force-recreate), validate with compose config --quiet before touching the running container, and write the rollback record in the documented format and location.
58 lines
3.0 KiB
Markdown
58 lines
3.0 KiB
Markdown
# Hints
|
|
|
|
Short notes on things that were not obvious. Prune stale ones.
|
|
|
|
- **`bin/cd-target` cannot be imported normally.** The hyphen in the filename is
|
|
not a valid Python identifier, so `bin/cd-render-hooks` loads it through
|
|
`importlib.machinery.SourceFileLoader`. Importing `importlib.util` alone is
|
|
not enough — `importlib.machinery` needs its own import.
|
|
|
|
- **`if eval "$(cmd)"` tests the wrong thing.** `eval` reports the status of the
|
|
string it evaluates, and an empty string is success — so a failing `cmd` makes
|
|
the `if` take the *true* branch with nothing assigned, and `set -u` then aborts
|
|
on the first variable the branch reads. Capture first
|
|
(`if out="$(cmd)"; then eval "$out"`). This had made `cd-status`'s "host is not
|
|
configured" message unreachable.
|
|
|
|
- **`docker/metadata-action`'s `type=sha,format=short` produces 7 characters.**
|
|
That is why `image_tag_template` uses `{short7}`. domaindingo's `build.yml`
|
|
prefixes it with the branch, giving `test-sha-abc1234` / `prod-sha-abc1234`.
|
|
|
|
- **domaindingo's compose stacks are not in the domaindingo repo.** Test and
|
|
prod both live in `sysadmin/uas-ng` at
|
|
`docker/domaindingo/s5.fisher.hu/` (`docker-compose.yml` and
|
|
`docker-compose-prod.yml`). The `scripts/deploy-*.sh` files still in the
|
|
application repo point at compose files that do not exist on s5 — they are
|
|
dead code for both environments that matter.
|
|
|
|
- **domaindingo test and prod both run on s5, not s2.** Only dev is still on s2.
|
|
The `hostname != s2` guard in the old scripts therefore matched nothing and
|
|
`exit 0`d, which reads as success.
|
|
|
|
- **Registry tags in this fleet have drifted before.** `domaindingo:0.1.149`
|
|
once resolved to a different image than the one running, with a broken
|
|
`/login`. This is why `cd-deploy` checks
|
|
`org.opencontainers.image.revision` and deploys by digest.
|
|
|
|
- **`docker compose down -v` destroys the data volumes** for these stacks. The
|
|
retired paradicsomleves test script used it. `cd-deploy` only ever runs
|
|
`up -d`.
|
|
|
|
- **domaindingo's health endpoint is `/api/health`, not `/health`.** The route is
|
|
declared as `/health` in `src/domaindingo/api/status.py`, but `main.py` mounts
|
|
the router with `prefix="/api"`. Checking `/health` gets a 404, which reads as
|
|
a failed deploy and triggers a rollback. The vault's
|
|
"DomainDingo Development" note is the authority here.
|
|
|
|
- **The manual runbook recreates one service, not the project.**
|
|
`docker compose up -d --pull always --no-deps --force-recreate <service>`.
|
|
`cd-deploy` matches it (minus `--pull always`, since it has already pulled a
|
|
pinned digest), so an automated deploy and a hand-run one converge on the same
|
|
state.
|
|
|
|
- **Rollback records are a documented convention.**
|
|
`<service>-rollback-<UTC timestamp>.env` in `backup-test`/`backup-prod`,
|
|
holding `DD_ROLLBACK_IMAGE`, `DD_ROLLBACK_REVISION`, `DD_ROLLBACK_CAPTURED_AT`.
|
|
`cd-deploy` writes the same format in the same place, so an operator following
|
|
the manual note can recover from an automated deploy.
|