Backend deployment

The container is built using the Dockerfile and deployed to our own kubernetes cluster.

Both steps are handled by the CI/CD pipeline:

• First the container is built in the workflow workflow_build-image.yaml and pushed to the (local) container registry.
• Then the deployment is handled in the workflow workflow_deploy-container.yaml which deploys the container to the kubernetes cluster. Depending on the branch, the deployment is done to the staging or production environment.

Prerequisites

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

• On the cluster side: a Kubernetes cluster with the following components:
  • ingress controller
  • storage class
• On the local side: for development and local testing:
  • kubectl installed
  • kustomize (usually bundled with kubectl)

Manual deployment

Initial deployment

To deploy the backend application, follow these steps:

1. Clone this repository
2. Apply the desired overly: kubectl apply -k <path-to-overlay>

Rolling updates

Since the deployment uses a single tag (along with the always pull policy) for the backend application, we simply need to trigger a rolling update which will pull the latest image from the registry. To do this, run the following command:

kubectl -n <namespace> rollout restart deployment/anyway-backend

Automated deployment

CI/CD and credentials

For the deployment to work, the CI runner needs to authenticate against the kubernetes cluster. This is done by creating a service account in the cluster and providing the CI runner with the necessary credentials through a kubeconfig file. This file is stored as a repository secret KUBE_CONFIG and is used by the kubectl command in the CI pipeline.

The RBAC configuration for the service included for your reference in the file rbac.yaml. To use it, extract the token from the secret deployment-token-secret. Then fill in the token and service account name into the kubeconfig.

Deployment environments

The deployment is done to two environments:

• Staging: All builds from forks and pull requests are deployed to the staging environment. This is done to test the changes before merging them to the main branch.
• Production: Only 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.