Files
jarvis-selfhost/kubernetes/03-migrate-job.yaml
T
2026-08-27 17:52:23 +02:00

94 lines
4.3 KiB
YAML

# The schema, brought up to this image's expectations. Once, before any pod of it starts serving.
#
# A JOB, and deliberately neither of the two alternatives:
#
# NOT an initContainer. It would run once per pod — which is exactly the bug this replaces, where
# every API container ran `prisma db push` at boot and N replicas raced the same DDL while the
# previous generation was still selecting the columns being altered.
#
# NOT a leader election inside the API. A Job is the primitive built for run-once work: it has an
# observable status, a bounded number of retries, and a failure that stops the rollout instead of
# letting it proceed against a schema that was never applied.
#
# With Helm this becomes a `pre-install,pre-upgrade` hook; with Argo, a sync-wave. Applied by hand,
# the ordering is yours to keep — see the README.
#
# It is safe to run twice: every pass is idempotent and the whole phase is wrapped in a Postgres
# advisory lock, so a second copy waits rather than racing.
apiVersion: batch/v1
kind: Job
metadata:
name: jarvis-migrate
namespace: jarvis
spec:
# One writer. The lock makes a second one wait rather than corrupt, but there is no reason to
# have one waiting.
parallelism: 1
completions: 1
# Two retries, because the failures worth retrying are transient (a database not finished failing
# over). A schema that Prisma REFUSES is not transient and must not be retried into submission —
# it is refused for a reason, and the reason is printed.
backoffLimit: 2
# A migration that has not finished in fifteen minutes is stuck, not slow, and the rollout is
# blocked behind it.
activeDeadlineSeconds: 900
template:
metadata:
labels:
app.kubernetes.io/name: jarvis
app.kubernetes.io/component: migrate
spec:
restartPolicy: Never
# Required by the `restricted` Pod Security Standard that 00-namespace.yaml enforces. At pod
# level so it covers anything added beside this container later. Without it the Job is
# accepted and its pod is refused, so the rollout waits on a Job that will never complete.
securityContext:
seccompProfile:
type: RuntimeDefault
containers:
- name: migrate
# THE SAME IMAGE, by the same digest, as the API that is about to roll. A migration from a
# different build is a schema that matches nothing.
image: git.luxit.be/luxit/jarvis-api@sha256:REPLACE_ME
command: ["/usr/local/bin/migrate.sh"]
envFrom:
- configMapRef:
name: jarvis-api-config
# Generated first, hand-written last, for the reason spelled out in 04-api.yaml: the
# last occurrence of a name wins, and a generated value must never override a typed one.
- secretRef:
name: jarvis-generated
optional: true
- secretRef:
name: jarvis-secrets
env:
# Its own, smaller pool: this is one process doing one thing, and the connections it
# takes are connections the running API cannot have while it works.
- name: DATABASE_URL
valueFrom:
secretKeyRef:
name: jarvis-secrets
key: DATABASE_URL
# Off, and it should stay off between deliberate acts. `prisma db push` used to run with
# `--accept-data-loss` at every boot, which meant an upgrade could destroy a column with
# nobody having decided to — survivable on one container, not during a rolling update
# where the previous generation is still selecting it.
#
# Without the flag the phase REFUSES, prints which columns it would have dropped, and
# fails the Job — so the rollout stops and nothing is serving a half-migrated schema.
# Set it to "true" for the ONE deploy where that drop is intended, then remove it.
- name: SCHEMA_ACCEPT_DATA_LOSS
value: "false"
resources:
requests:
cpu: 200m
memory: 512Mi
limits:
memory: 1Gi
securityContext:
runAsNonRoot: true
runAsUser: 1000
allowPrivilegeEscalation: false
capabilities:
drop: ["ALL"]