feat(ci): add the deploy job and the kubernetes manifests #8

Merged

hermes merged 4 commits from fix/dockerfile-python314 into master 2026-11-09 12:00:35 +10:00

Conversation 3 Commits 4 Files Changed 4

+231

4 Commits

Author	SHA1	Message	Date
hermes	958ae9b365	fix(ci): keep the credentials out of the process list ... Two small changes to the deploy job: - The registry password went through `-u armistace:$PASSWORD` on the curl command line, where it is visible in the process list for the duration of the request. It now goes through a curl config file on stdin instead. - The kubeconfig is written with mode 600 rather than the default, and is removed at the end of the job (with `if: always()`, so it is removed even if a later step fails). It is cluster-admin-equivalent, so it should not be readable by anything else on the runner. Verified: `curl --config -` against the registry returns the same digest as the `-u` form.	2026-11-09 12:00:18 +10:00
hermes	55d5e84150	fix(ci): pin the image to the commit SHA instead of the mutable :latest tag ... The review flagged `:latest` as a critical issue, and it is right: a mutable tag makes `kubectl rollout undo` meaningless and lets different pods in the same deployment run different code if they restart at different times. - The build job now pushes the image with BOTH `:latest` and `:${{ github.sha }}`. - The deployment manifest carries a sentinel tag rather than `:latest`, and the deploy job sets the real SHA with `kubectl set image`. That makes the deploy a genuine manifest change, so the Deployment rolls because its pod template changed — not because it was told to. `kubectl rollout undo` now means something: it goes back to the previous SHA. - The digest check now compares against the SHA tag rather than `:latest`, and it checks EVERY running pod instead of `items[0]`. During a rolling update `items[0]` may still be an old pod that has not been terminated, which would compare against the wrong digest. The job also fails if the deployment is not fully rolled out. - The smoke test now checks the app through the Service as well as directly in the pod. The pod check alone would pass even if the Service selector or the port mapping were wrong. - `readOnlyRootFilesystem: true` — the app writes no files, so the root filesystem can be read-only. /tmp is still writable via the emptyDir. - The kubectl install is skipped when the runner already has one.	2026-11-09 11:59:22 +10:00
hermes	b73df93f20	feat(ci): add the deploy job so the app deploys from the repo ... The workflow built and pushed the image but never deployed it - the cluster objects had been created by hand. This adds a `deploy` job that applies the manifests in `kube/` and rolls the deployment. The deploy job is separate from the build job on purpose. The `KUBEC_CONFIG_BUILDX` secret is cluster-admin-equivalent, and a build step that never talks to the cluster should not be able to read it. Three things this job does that a naive `kubectl apply` does not: 1. `kubectl rollout restart`. The image tag is `:latest`, which is immutable in the manifest, so `apply` alone does not roll the pods. Without the restart the deployment reports success while the old pods keep serving the old image - a deploy that silently changes nothing. 2. Verifies the running digest against the registry's `:latest`. CI green and pods `Ready` do not prove the new code is live; the digest comparison does. 3. Smoke tests the running app - `/healthz` and `/readyz` - from inside the pod, so a deploy that comes up but cannot serve is caught in CI rather than by the next person to open the page. The Secrets (`beer-db`, `beer-app`) are hand-provisioned and are deliberately not in the apply set, so a deploy cannot clobber them.	2026-11-09 11:46:06 +10:00
hermes	55c5de9d61	feat(deploy): add the kubernetes manifests so the deployment is in the repo ... The cluster objects for the beer namespace were created by hand. This puts them in the repo so they can be applied and reviewed like everything else. - `beer-deployment.yaml` — the Deployment, with the security context, the resource limits, and both probes wired up (`/healthz` liveness, `/readyz` readiness). - `beer-service.yaml` — the NodePort service. - `beer_namespace.yaml` — the namespace. The credentials are NOT in these files. `MONGO_PASS` and `SECRET_KEY` come from the live `beer-db` and `beer-app` Secrets, so applying the manifests cannot clobber a hand-provisioned credential. Notes on the pod security context --------------------------------- `runAsNonRoot: true` cannot be set on the container when the image's user is a *named* user - kubelet can only verify a numeric UID. The pod-level security context therefore sets `runAsUser: 999`, which matches the `beer` user the image creates (verified with `id` in the built image). The container also drops all capabilities and refuses privilege escalation.	2026-11-09 11:45:41 +10:00