A CD pipeline on GKE With Argocd and Keel
As I mentioned in a previous post, I use argoCD as a tool in my CD pipeline for my GKE clusters at $DAYJOB. But it’s not the only tool that composes it. I’ve been using keel alongside argoCD to complement it. Let’s see how those 2 articulate and make our delivery fast and smooth
The development flow
The usual development workflow (relative to the delivery) we use is the following :
Keel
Keel is a simple piece of software that runs on the cluster and watches the changes to the registered images, allowing to update them automatically and therefore have our dev and preprod platform up-to-date without the developers having to do any action.
I use the helm chart for keel from its own repo and the following values :
---
# not using the helm provider
helmProvider:
enabled: false
slack:
enabled: true
botName: "keel"
token: "REDACTED"
channel: "#devops-slack-channel"
host: keel.xx.yy.the.corp.com
service:
enabled: false
type: ClusterIP
ingress:
enabled: false
As you can see, keel can handle helm charts but it’s far from being as advanced and mature than argoCD, so I disabled it.
To have an image being updated by keel, you need to do the following in the deployment :
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-deployment
labels:
keel.sh/policy: force
keel.sh/match-tag: "true"
keel.sh/trigger: poll
annotations:
keel.sh/pollSchedule: "@every 1m
ArgoCD
ArgoCD is bit more of a complex software than keel, but it manages much more. I use it to deploy the applicative charts than run the stack. It has the proper ACLs that allow us to delegate the management of a project to given users, and you can plug it to your gsuite identity management and so on.
Once again I deploy it using the official chart repository and a values file as follows :
---
global:
image:
tag: v1.5.7
installCRDs: false
host: &host xxx.yyy.zzz.the.corp.com
server:
ingress:
enabled: true
annotations:
ingress.kubernetes.io/ssl-redirect: "true"
cert-manager.io/cluster-issuer: letsencrypt-prod
external-dns.alpha.kubernetes.io/hostname: *host
nginx.ingress.kubernetes.io/backend-protocol: "HTTPS"
hosts:
- *host
paths:
- /
tls:
- hosts:
- *host
secretName: argocd-secret # do not change, this is provided by Argo CD
config:
url: https://xxx.yyy.zzz.the.corp.com
dex.config: |
connectors:
- config:
issuer: https://accounts.google.com
clientID: "REDACTED"
clientSecret: "REDACTED_TOO"
type: oidc
id: google
name: Google
rbacConfig:
policy.csv: |
# Role definition : these users are admin
g, foo@bar, role:admin
# policies : can be done multiple times to give access to multiple projects
# See https://github.com/argoproj/argo-cd/blob/master/docs/operator-manual/rbac.md for more information
p, meh@bar, applications, *, project1/*, allow
# default policy for people logging in --> no rights at all, they are blind and have no rights
policy.default: ""
scopes: '[email, group]'
redis:
containerSecurityContext:
runAsNonRoot: true
readOnlyRootFilesystem: true
capabilities:
drop:
- ALL
resources:
limits:
cpu: 100m
memory: 50Mi
You will then be able to configure your sources, projects and such either via the web UI or the CLI (because CLI rocks !) and give freedom to our users to handle the deployments by themselves, in a controlled manner. Since argoCD became an official CNCF project it’s pretty encouraging for the future.
Have fun setting up your pipeline !