Deploying as a pod

deploy/ has both as one pod: the hub in one container, clockwork in another, so the web-facing one holds no key. The screening proxy is a second pod.

$ podman build -t instamix-hub -f deploy/Containerfile .
$ podman build -t instamix-src -f deploy/Containerfile.src .
$ podman build -t instamix-clockwork ../clockwork
$ kustomize build deploy/kustomize/base | kubectl apply -f -     # or: | podman kube play -
$ kubectl port-forward service/instamix 8480:8480

The base and its overlays#

deploy/kustomize/base is a Deployment of that pod, a ClusterIP Service and two volume claims (the hub’s database; clockwork’s jobs and logs), and the proxy’s Deployment, Service, volume claim and CronJob. When the pod starts it makes the token between the two, clones the repositories of INSTAMIX_PLAY_REPOS and syncs the catalogue.

An overlay fits it: deploy/kustomize/overlays/example sets the images, the team and the repositories, the instamix-ssh secret (the key and known_hosts of the runs, mounted in clockwork only), how long jobs are kept, and the storage.

A pod to each job#

deploy/kustomize/components/job-pods gives each job a pod of its own: an overlay that names it under components: has clockwork make a Kubernetes Job for every run, from the template job.json, follow it and remove it.

What a script starts is then apart from the hub and clockwork – it has not the token between them, their databases or the other jobs’ output, and it cannot reach clockwork, which listens inside its own pod. The SSH key is in the jobs’ pods only, the repositories are a volume claim (instamix-plays) that those pods read, and clockwork gets an account that may make and remove jobs in its namespace (rbac.yaml). A job builds what its script requires anew each time, through the proxy and its cache. Its pod still reaches the hub, for its inventory.

The proxy’s pod#

The screening proxy is a pod of its own there (instamix-proxy), and clockwork’s runs go through it: with -env and -install a job builds the Python, the ansible and the collections its script requires before it starts (kept between runs), and INSTAMIX_PROXY makes that come through the proxy, so only what its list lets through.

The list works as a blacklist: osv-blacklist --allow-rest (tools/osv_blacklist.py, in the image) denies what OSV reports as malicious and allows the rest. It runs when the proxy starts, and the CronJob instamix-proxy-blacklist brings the rules up to date each day. Galaxy has no such source, so collections and roles are only screened by rules you add yourself (kubectl exec deploy/instamix-proxy -- imix proxy insert ...).

On this machine#

deploy/compose.yaml is the same containers on this machine, for rootless podman: podman compose -f deploy/compose.yaml up, with your scripts (INSTAMIX_PLAYS) and your key (INSTAMIX_SSH) mounted in.

The pipeline#

What is on master is in production. .gitea/workflows/ci.yml runs make check on every push, and on master builds the hub image, an image of the source and the image of this site into the registry (zot.lab.fizzyflux.nl/instamix/hub, .../src and .../docs), then applies deploy/kustomize/overlays/lab to the cluster with the images of that commit. clockwork’s own pipeline builds the runner image from that source image and rolls it out.

The account they deploy with is made by examples/instamix_deploy.py: it can apply the pods in the instamix namespace and read no secret.

This site#

The site you are reading is part of the same build. Its source is site/, a Hugo site without a theme to fetch. Its reference is not written by hand: the commands, the declarations and the events are read from api/openapi.json, and the settings from imix config keys, both of the commit the image is built from.

$ make docs          # build it into site/public
$ make docs-serve    # serve it at http://localhost:1313 while you write
$ podman build -t instamix-docs -f deploy/Containerfile.docs .

make uses hugo when it is on PATH, and the Hugo image with podman or docker when it is not. deploy/Containerfile.docs builds the site and puts it in an unprivileged nginx. deploy/kustomize/components/docs is its Deployment and Service: nothing in it holds a key, a token or a database, so unlike the hub it can be public. The lab’s overlay takes the component and adds the Ingress, at instamix-docs.lab.fizzyflux.nl.