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. 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 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** TL;DR: * Is Can do everything, 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 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.