Llamas Band and Continuous Delivery

Overview

In this article, I’ll be providing details on how to configure ArgoCD for the Llamas Band project including deploying to the other sites.

Continuous Delivery

With ArgoCD installed and the Llamas container CI pipeline completed, we’ll use this configuration to ensure any changes that are made to the Llamas website are automatically deployed when the container image is updated or any other configuration changes are made.

Project

In my homelab, there really isn’t a requirement for projects to be created however in a more professional environment, you’ll create an ArgoCD project for your application.

In this project, you’re defining what Kubernetes clusters the containers in the project have access to. I have four environments and since one project is across all four clusters, we need to configure the access under specs.destinations. When you created the links using the argocd cli, those are the same ones used in this file.

Since this is an ArgoCD configuration, it goes in the argocd namespace.

apiVersion: argoproj.io/v1alpha1
kind: AppProject
metadata:
  name: llamas
  namespace: argocd
spec:
  clusterResourceWhitelist:
  - group: '*'
    kind: '*'
  description: Project to install the llamas band website
  destinations:
  - namespace: 'llamas'
    server: https://kubernetes.default.svc
  - namespace: 'llamas'
    server: https://cabo0cuomvip1.qa.internal.pri:6443
  - namespace: 'llamas'
    server: https://tato0cuomvip1.stage.internal.pri:6443
  - namespace: 'llamas'
    server: https://lnmt1cuomvip1.internal.pri:6443
  sourceRepos:
  - git@lnmt1cuomgitlab.internal.pri/external-unix/gitops.git

Application Configuration

When configuring the application, since I have four sites, I’m creating each with an extension; llamas-dev for example. The project defines what sites each application can access under the specs.destinations data set.

Much of the configuration should be easy enough to understand.

• name – I used the site type to extend the name
• namespace – It’s an ArgoCD configuration file so argocd
• project – The name of the project (see above)
• repoURL – The URL where the repo resides. I’m using an ssh like access method so git@ for this
• targetRevision – The branch to monitor
• path – The path to the files that belong to the llamas website
• recurse – I’m using directories to manage files so I want argocd to check all subdirectories for changes
• destination.server – One of the spec.destinations from the project
• destination.namespace – The namespace for the project

The ignoreDifferences block is used due to my using Horizontal Pod Autoscaling (HPA) to manage replicas. While HPA does update the deployment, there could be a gap where argocd terminates pods before it catches up with the deployment. With this we’re just ignoring that value to prevent conflict.

You can test this easily by setting the deployment spec.replicas to 1 (the default) then adding the HPA configuration. When checking the deployment after that, you’ll see it’s now set to 3.

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: llamas-dev
  namespace: argocd
spec:
  project: llamas
  source:
    repoURL: git@lnmt1cuomgitlab.internal.pri:external-unix/gitops.git
    targetRevision: dev
    path: dev/llamas/
    directory:
      recurse: true
  destination:
    server: https://kubernetes.default.svc
    namespace: llamas
  syncPolicy:
    automated:
      prune: false
      selfHeal: false
  ignoreDifferences:
    - group: apps
      kind: Deployment
      name: llamas
      namespace: llamas
      jqPathExpressions:
        - .spec.template.spec.replicas

And when checking the status.

$ kubectl get application -A
NAMESPACE   NAME         SYNC STATUS   HEALTH STATUS
argocd      llamas-dev   Synced        Healthy

Remote Clusters

Of course we also want the Dev ArgoCD instance to manage the other site installations vs installing ArgoCD to every site. Basically ArgoCD will need permission to apply the configuration files.

For the Llamas site, we’ll need a second, slightly different ArgoCD Application file. Note the difference is only the metadata.name where I added qa instead of dev, the spec.destination.server which is the api server of the cabo cluster, the spec.source.targetRevision of main instead of dev, and of course spec.source.path, the path to the Llamas files. The rest of the information should be the same.

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: llamas-qa
  namespace: argocd
spec:
  project: llamas
  source:
    repoURL: git@lnmt1cuomgitlab.internal.pri/external-unix/gitops.git
    targetRevision: main
    path: qa/llamas/
    directory:
      recurse: true
  destination:
    server: https://cabo0cuomvip1.qa.internal.pri
    namespace: llamas
  syncPolicy:
    automated:
      prune: false
      selfHeal: false
  ignoreDifferences:
    - group: apps
      kind: Deployment
      name: llamas
      namespace: llamas
      jqPathExpressions:
        - .spec.template.spec.replicas

Next, a green/blue deployment for the llamas website. What fun!