exneuland-deploy
new deployment repository for our CD efforts
Branching Model
main ---x------------------x-------------------------------------->
| ^
| |
| | fast-forward merge
v |
feature/name ------x-x-x-x---->
| |
+---+---+
|
v
squash to one commit
x = commit
This repository holds the entire configuration of the cluster and is considered the "source of truth" for the entire cluster configuration.
We have a staged environment for the exneuland
application. If you make changes to the exneuland
deployment, you can deploy it in stages.
Be careful with merging MRs to main
. Everything that is merged in main
will be deployed automatically.
Be super careful with merging automatically generated MRs from exneuland that change something below kustomize/overlays/staging
and kustomize/overlays/prod
. Make sure it's the right image tag you're deploying to prod!
Secret Management
Secrets are encrypted using SOPS (ksops and helmSecrets) and keys are handeled using age in favor to PGP Keys which are a pain to handle.
To edit a SOPS encrypted file:
sops path/to/encrypted/secret.yaml
and edit the file using the editor configured in $EDITOR
. This will make sure, the file is encrypted proberly and you don't accidentally commit an unencrypted secret.
Deployment
The deployment is done with ArgoCD in what's called a "pull deployment". This follows the Git-Ops workflow.
With our ArogCD instance, we can deploy everything:
- helm charts
- kustomize
- plain manifests
See:
ToDos
Repo Settings
- main protected (only allowed changes are via MR) --> not done to enable fast development of the base deployment
- staging, prod protected (only allowed changes are via MR)
- squash encouraged only from feature-branch to dev
- ff-merge enforced for all merges
- Merge only allowed if pipeline succeeds
GitLab CI Pipeline
- Linting (yamllint)
- Kustomize run
-
Kubeval
- No Secret print/output/...