Project

General

Profile

Actions
Copy link

Task #9565

closed

Select a CI/CD for deploying helm charts/docker containers etc.

Added by Nico Schottelius over 3 years ago. Updated almost 3 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Nico Schottelius
Target version:
-
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

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

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?

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
Copy link

Also available in: Atom PDF