Task #9565
Updated by Nico Schottelius over 3 years ago
* Basically: git push && pipeline that does the rest
* Input from your experiences is appreciated
h2. Choices
h3. Flux v2
* Overall nice
* Does not cover the build phase
* Has nice multi cluster support
h3. "drone":https://github.com/drone/drone
* Unclear on how / where to store the output
* K8S support seems to be fragile
h3. Jenkins
* The "standard"
* Very heavy (4GB+ memory)
h3. "Buildbot":https://buildbot.net/
* 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
h3. "GoCD":https://www.gocd.org/kubernetes/
**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":https://github.com/tomzo/gocd-yaml-config-plugin#setup
Non-working installation:
<pre>
helm upgrade --install --set server.service.type=ClusterIP,server.ingress.enabled=false gocd gocd/gocd
</pre>
h3. 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":https://docs.gitlab.com/charts/
*** Seems to be "rather native"
*** Registry included -- "but no cleanup?":https://stackoverflow.com/questions/55361101/gitlab-container-registry-any-way-to-automate-deletion-of-old-containers
**** Can automatically deleted untagged - might be enough
* Gitlab/k8s seems to be "strongly tied to terraform":https://docs.gitlab.com/ee/user/project/clusters/add_remove_clusters.html
** Not suitable for bare metal
h3. "ArgoCD":https://argoproj.github.io/argo-cd/ *and(?)* "argoflow":https://argoproj.github.io/argo-workflows/
* Rather complicated / big ecosystem
* Design to be cloud native
* Dependencies nicely solved
** in order or via DAG
h3. Argo flow
* "Output is very S3 centered":https://github.com/argoproj/argo-workflows/blob/master/examples/input-artifact-git.yaml
** We could use this, even though it seems overkill
** This might be a practical requirement
** Might be able to ignore this feature
h2. Flows
h3. 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
h4. 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?
h4. 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
h4. 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.