jklein
93fdb3eaea
One StatefulSet with two containers - the Puma web process and a Sidekiq worker - sharing one ReadWriteOnce PVC at /rails/storage. That shared volume is the reason they live in one pod: splitting them would need an RWX volume. Only the web container migrates, because the image entrypoint runs db:prepare solely for the './bin/rails server' command; the worker is started through args: so the entrypoint (and its jemalloc preload) stays in place and the two can never race. Probes are chosen for what they prove: liveness and startup use Rails' /up, which is a boot check and touches no database, while readiness uses '/', which runs User.count through authenticate_user! in self-hosted mode and therefore fails while Postgres is unreachable. The worker speaks no HTTP, so all three of its probes ask sidekiqmon whether this pod still holds a Sidekiq heartbeat in Redis. Three OnePasswordItem CRs (app, database, redis), ingress.domain kept required outside the Ingress because APP_DOMAIN and the WebAuthn relying party read it, strict values.schema.json, CI fixtures with throwaway Postgres 16 and Redis, and a Renovate manager on semver so the -alpha/-rc/-hotfix channel and the moving tags are never selected.
7 lines
393 B
Bash
7 lines
393 B
Bash
# The first start of the web container creates and migrates the whole Rails
|
|
# schema ("./bin/rails db:prepare", run by the image entrypoint) before Puma
|
|
# binds its port, and the worker container only registers with Sidekiq once
|
|
# that schema exists. Both startup probes budget 600s for it, so the rollout
|
|
# wait has to be longer than a single startup budget, not shorter.
|
|
INSTALL_TIMEOUT=900
|