The backend is a containerized fastapi application built in https://git.kluster.moll.re/anydev/anyway. The container is deployed along some helper services on our own kubernetes cluster.

Overview

The deployment comes in two flavors - staging and production. The setup is straightforward and mostly identical between the two environments: most configuration lies in the base/ folder and only the environment-specific adjustments are in the overlays/ folders.

The deployment is in principle fully functional as-is, but the main benefits - automatic deployment, provisioning and updates - are only available when levering argoCD. In the recommended setup, the manifests are never applied manually, but are instead referenced in the app of apps. This handles both the deployment of a stable production version and the automatic deployment of staging versions for each pull request.

Cluster requirements

For the deployment of the backend application, the following prerequisites need to be met on the kubernetes cluster:

ingress controller (assumed to be traefik in the manifests but easily adaptable)
a storage class (assumed to be nfs-client in the manifests but easily adaptable)
argoCD (for automatic deployment)
(upcoming) sealed secrets controller (for managing secrets)

Deployments

The deployment is done to two environments:

Production

Only tagged builds from the main branch are deployed to the production environment. This is the live environment that is used by the users. The main branch is protected and can only be merged to through pull requests. This is handled as a simple argoCD application that points to the overlays/production folder which references the latest semver tagged version of the backend.

Staging

All builds from forks and pull requests are deployed to a seperate namespace. The crucial part is that this is handled as an argoCD applicationSet that automatically creates a new application for each pull request, adding a further modification to the overlays/staging patches. This way, each pull request gets its own isolated deployment that can be tested and validated before merging to main. The staging deployments are automatically removed when the pull request is closed.