Sync the self-hosting stack

2026-08-27 17:52:23 +02:00
parent af6710d849
commit 02ab18aff1
12 changed files with 1407 additions and 0 deletions
@@ -0,0 +1,93 @@
+# 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"]