Project

General

Profile

Task #9565

Updated by Nico Schottelius over 2 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/ 

 * 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: 

 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. 

Back