[jim-toth]

Summary

The stage job for the ported api-service, under the existing api-service-stage job and group names, so running it replaces the current service as a canary update and the old allocation keeps serving until the new one is promoted. It takes over from the parity job definition.

Changes

• operations/api-service-stage.hcl (from api-service-parity-stage.hcl): Consul service api-service-stage with the existing Traefik tags, Vault path kv/stage-services/api-service-stage, default geo-ip cache TTL, no host volume and no Mongo lookup.
• Varnish task pinned to varnish:9.1.0, listening on 8080 in the allocation. VCL: 5xx responses are never cached, /healthz is passed through, successful and 4xx responses keep the five minute TTL.
• varnishd -p http_req_size=128k -p workspace_client=256k, so requests up to the service's 80 KB limit reach it and larger ones get its 431 instead of a dropped connection.
• HTTP check on /healthz through Varnish with address_mode = "alloc", keeping the existing check_restart settings.
• Update block: healthy_deadline 10m, progress_deadline 15m.
• One group-level service tagged logging; the log follower falls back to the group service for tasks without their own, so both tasks' logs ship.
• Operations README: api-service section in place of the parity run.

Verified

• nomad job validate passes.
• VCL on varnish:9.1.0 against a stub backend: /healthz is never cached; 200 and 404 are cached; a 500 is not cached and the request after recovery gets a fresh 200; a cached 200 is still served while the backend fails.
• Request sizes on varnish:9.1.0 with these parameters in front of Bun with --max-http-header-size=80000: up to 79 KB answered 200, 81 KB to 127 KB answered 431 by the service; with Varnish defaults everything above 32 KB was a reset connection.