Actions
Task #9565
closed
NS
NS
Select a CI/CD for deploying helm charts/docker containers etc.
Task #9565:
Select a CI/CD for deploying helm charts/docker containers etc.
Start date:
07/26/2021
Due date:
% Done:
0%
Estimated time:
PM Check date:
Description
- Basically: git push && pipeline that does the rest
- Input from your experiences is appreciated
Choices¶
Flux v2¶
- Overall nice
- Does not cover the build phase
- Has nice multi cluster support
drone¶
- Unclear on how / where to store the output
- K8S support seems to be fragile
Jenkins¶
- The "standard"
- Very heavy (4GB+ memory)
Buildbot¶
- Old
- Static workers (easy to configure via k8s)
- Seems to be fast and easy to setup
- Python based
- Website and documentation down as of 2021-08-08
GoCD¶
TL;DR: Does not even start in an IPv6 k8s cluster
- Recommended to me by the buildbot author (haaaaa??)
- Can push to docker registry
- Can be driven by a git repository
Non-working installation:
helm upgrade --install --set server.service.type=ClusterIP,server.ingress.enabled=false gocd gocd/gocd
Gitlab¶
TL;DR: has a lot included, maybe too much
- Is heavy to maintain without containers.
- Highly integrated
- Can use k8s workers, can use docker
- Widely deployed
- Huge and tricky to maintain
- Docker:
- https://hub.docker.com/_/gitlab-community-edition
- https://docs.gitlab.com/ee/install/docker.html
- Helm chart support
- Seems to be "rather native"
- Registry included -- but no cleanup?
- Can automatically deleted untagged - might be enough
- Gitlab/k8s seems to be strongly tied to terraform
- Not suitable for bare metal
ArgoCD and(?) argoflow¶
- Rather complicated / big ecosystem
- Design to be cloud native
- Dependencies nicely solved
- in order or via DAG
Argo flow¶
- Output is very S3 centered
- We could use this, even though it seems overkill
- This might be a practical requirement
- Might be able to ignore this feature
- Argo flow tries to access /var/run/docker.sock directly - which does not exist for crio based environments
- MountVolume.SetUp failed for volume "docker-sock" : hostPath type check failed: /var/run/docker.sock is not a socket file
Flows¶
DNS Update¶
Questions:
- Should we create a stand-alone zone repository?
- Would be very small
- Can only clone head/last commit
- If using git pull inside the container, we need to pass along credentials
- possible in a secret
Flow v1¶
- We change a zone file in git and push it somewhere
- A new helm chart is being created
- (maybe in between) bump the chartversion field?
- only if knot was able to run it?
- The new helm chart is uploaded to the chartmuseum
- The pods/services are notified about a new version
- How?
- Configmap change?
- git pull?
- How?
Flow v2: pull from git repo¶
- The helm chart is given a git repo (+possible secret)
- The pod tries reloading every minute
- if checkconf works: restart
- else: reject
- A webhook in gitea might be used to trigger the DNS server instances
- Faster deploy
- Question is where to, whether we have 1 hook per cluster, etc.
Disadvantage: need to build our own container (?)
- In theory a custom container could do that in a pod
Flow v3: push pipeline¶
- In theory we want every zone change to create a new version number
- Actually we have this already with the git commit
Nothing to be done here.
Actions