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 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.
--- # 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 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 !