Argocd App of Apps

GitOps has taken the operations world by storm. Having your application deployment information in once place, gives companies and engineers alike a better holistic view of the their environments. GitOps seeks to simplify the code deployment process by having every interaction based on a git commit. This is a huge win for the Infrastructure deployment community.

Tools like Argo projects Argo-CD makes the shift to gitops fairly straight forward. Their solution is tailored for deploying applications into any kubernetes based environment. Once you have Argo CD installed and running, you can start spinning up applications with just a few lines of YAML. Right now we are going to take a look at a very powerful design pattern in Argo CD, the App of Apps pattern, which allows you to boot strap entire clusters in seconds. The initial documentation does a great job at introducing the design pattern, but here are some of the things I learned while working with Argo CD.

  

    ---
    apiVersion: argoproj.io/v1alpha1
    kind: Application
    metadata:
      name: homelab
      namespace: argocd
    spec:
      project: default
      source:
        repoURL: https://github.com/smarman85/argoapps
        path: apps
        targetRevision: HEAD
      destination:
        server: https://kubernetes.default.svc
        namespace: argoapps
      syncPolicy:
        automated: {}
  
  

Everything in Argo CD is an application. From this single applicaiton CRD, we will begin the first step of the Application of Applications pattern. What makes this one special is the chart under spec.source.repoURL. This chart is where you will define the applications and any overrides they will need to spin up. It's worth noting that this example uses helm, but Argo CD integrates extremely well with other main stream chart builders like Kustomize and Ksonnett. The chat apps inside the git repo argoapps, builds additional leaf application, we will see later, that argo will apply to the cluster. For a small example, at the time of this writing the CRD below, once applied to the cluster, will use the supplied chart to render out a helm chart that builds multiple Application CRDs that in turn get applied to the cluster.

  

    ---
    # Source: basicChart/templates/service.yaml
    apiVersion: v1
    kind: Service
    metadata:
      name: gosite-svc
      labels:
        app: gosite
    spec:
      ports:
      - name: http
        port: 8080
        nodePort: 30080
      selector:
        app: gosite
      type: NodePort
    ---
    # Source: basicChart/templates/deployment.yaml
    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: gosite
      labels:
        app: gosite
      annotations:
        app: gosite
    spec:
      replicas: 3
      selector:
        matchLabels:
          app: gosite
      strategy:
        rollingUpdate:
          maxSurge: 25%
          maxUnavailable: 25%
        type: RollingUpdate
      template:
        metadata:
          name: gosite
          labels:
            app: gosite
          annotations:
            app: gosite
        spec:
          containers:
          - name: gosite
            image: smarman/gosite:0.0.7
            imagePullPolicy: Always
            command:
              - "/usr/bin/dumb-init"
            args:
              - "--"
              - "./goSite"
              #livenessProbe:
              #  httpGet:
              #    path: /about
              #    port: 8080
              #  initialDelaySeconds: 5
              #  periodSeconds: 60
            ports:
            - containerPort: 8080
            stdin: true
            tty: true
          restartPolicy: Always
    ---
    # Source: basicChart/templates/ingress.yaml
    apiVersion: extensions/v1beta1
    kind: Ingress
    metadata:
      name: gosite-ing
    spec:
      rules:
      - host: gosite.local.seanhome.xyz
        http:
          paths:
          - backend: 
              serviceName: gosite-svc
              servicePort: http
            path: /
  
  

This is essentially all that you'll need to configure to get the Application of Applications patter up and running. The charts from these Applicaitons should be familiar to anyone who has built an ArgoCD application before. In this pattern the next stage will tempalate out the manifest that Argo CD will use to apply to the cluster.

Pro Tip: This pattern can be extremely powerful, but it does come with some cognative overhead. It's important to keep the ammount of levels of this pattern to a minimum. It is very easy to lose track of what is being applied accross the cluster as you add levels to the pattern. Luckily, there are some tools that can help you visualize the pattern. I was fortunate enough lead a team to create a manifest rendering tool now known as Mani-Diffy. This tool will start at your top-level Applicaion and render out all the manifest for you to review. After leaving, I have found some interesting updates to add to the tool, which I plan on contributing back to the project once I have the time.

Posts + Projects