feat: deploy the agent — image, manifests, and the Flux plumbing

Two-stage Dockerfile: the runtime image carries neither uv nor a build
toolchain, runs as uid 10001, drops every capability and needs no writable
filesystem (verified with --read-only and no tmpfs).

k8s/ is what runs, dev/ is the Flux plumbing that applies it, self-managing
after three manual applies — the same shape every kong-* repo settled on.

Three choices worth naming:

- One namespace for the estate. What isolates an agent is its Keycloak client
  and the audiences it may request, not a namespace boundary.
- The GitRepository uses anonymous HTTPS rather than SSH with a Vault-held
  deploy key. The repo is already anonymously readable on gitea, so a key would
  guard nothing while adding two objects to create by hand before anything
  deploys. If the repos ever go private this becomes the kong-* SSH pattern.
- The lab CA certificate is committed. It is a certificate, never a key, and
  checking it in means the deployment has no hidden prerequisite.

replicas: 1 is a constraint, not a default — conversation history lives in the
process, so a second replica would route a user's "yes" to a pod that never saw
the question.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
Stéphane Tailland
2026-08-28 17:50:02 +02:00
parent 6ffab873e2
commit 9c3bdba3f9
13 changed files with 344 additions and 0 deletions
+41
View File
@@ -132,3 +132,44 @@ running library:
- Writes, and the A2A call to Approvisionnement.
- Deployment manifests — they belong in `classic-models-agent-platform` once a
second agent shows what is actually shared.
## Deployment
```
ghcr.io/staillanibm/classic-models-agent-catalogue:v0.1.0
```
Built from the `Dockerfile` here — two stages, so the runtime image carries no
build toolchain; non-root, read-only root filesystem, all capabilities dropped.
The image is built and pushed by hand for now: this repo lives on gitea and
gitea Actions is not set up, so there is no pipeline to do it.
```
docker build -t ghcr.io/staillanibm/classic-models-agent-catalogue:vX.Y.Z .
docker push ghcr.io/staillanibm/classic-models-agent-catalogue:vX.Y.Z
```
`k8s/` is what runs; `dev/` is the Flux plumbing that applies it. Three manual
applies close the loop once — nothing can watch `./dev` before the namespace and
the source that serves it exist:
```
kubectl apply -f k8s/namespace.yaml
kubectl apply -f dev/gitrepository.yaml
kubectl apply -f dev/bootstrap-kustomization.yaml
```
After that every file here reconciles from git, `dev/` included. Never
`kubectl apply` the objects under `k8s/` afterwards — Flux reverts them within
its interval and the cluster silently stops matching what you edited.
What the deployment assumes:
| | |
|---|---|
| Namespace | `agents` — one for the estate; what isolates an agent is its Keycloak client, not its namespace |
| Secret | `CATALOGUE_CLIENT_SECRET`, from the same Vault entry the realm import reads, through the `vault-keycloak` store |
| CA | `k8s/ca-configmap.yaml` holds the lab CA **certificate** — public by construction, checked in so the deployment has no hidden prerequisite. Regenerate it when the CA rotates (expires 2026-11-24) |
| DNS | every `*.sttlab.local` name resolves in-cluster already; no `hostAliases` needed |
| Replicas | exactly one. Conversation history lives in the process, so a second replica would route a user's "yes" to a pod that never saw the question |