Nico
Nico
Creator of this small website
Sep 27, 2020 3 min read

A CD pipeline on GKE With Argocd and Keel

thumbnail for this post

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 :

Development workflow

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 !