The build half of the platform

A cluster runs containers; it doesn't build them. Something has to turn a git push into an image sitting in a registry, ready to deploy. That's CI/CD, and in this lab it's two pieces working together:

  git push  ->  Gitea (git.example.com)
                   |  triggers a workflow
                   v
              GIT-Runner (10.100.100.11)
                 - checks out the code
                 - docker build
                 - docker push
                   |
                   v
              private registry (registry.example.com)
                   |  image is now available to...
                   v
              Kubernetes pulls & runs it

The Git server (Gitea) and the registry get their own books in the Core Infrastructure shelf. This book is about the runner — the worker that actually does the building — and how images flow from there into the cluster.

Why we use this: self-hosting the build pipeline (rather than using a SaaS CI) keeps the whole loop — code, build, artifact store, deploy target — inside one network you control and can explain. For a platform whose point is to show how it fits together, an end-to-end loop you own beats a hosted black box.

Diagram