51 lines
2.4 KiB
Markdown
51 lines
2.4 KiB
Markdown
# 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
|
|
1. 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:
|
|
|
|
```bash
|
|
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.
|