External Value Files in Argo CD With ApplicationSets - Softrams

  • Press

Oreon Lothamer
May 10, 2022 111 views

External Value Files in Argo CD With ApplicationSets.

We’ve been using Argo CD to deploy to our Kubernetes clusters for a while now. The overall experience has been great, but as we get more advanced we have started to wish for additional options. One issue we’ve had is the value files for helm charts have to exist in the same repo as the helm chart.

This is fine when we are deploying a standalone helm chart we control, but it is not so easy when using existing helm charts or our own helm charts that are meant to be deployed to all clusters we spin up. So we end up supplying values as overrides on the Application manifest. There are some concerns with this approach, like wanting to separate permissions to update Applications from permissions to update the values used.

There are a few different ways people have gone about addressing this. Some use proxy charts that just consist of value files and a dependency on the regular chart. Some have created plugins for Argo CD that handle pulling in separate value files. And there is also a proposal being worked on to implement a feature in Argo CD to support external value files. While we were enabling our platform to support Argo CD managing multiple clusters we realized we could use the same ApplicationSets we were using to deploy to all clusters to also grab helm values from separate repos.

ApplicationSets have multiple different generators you can use to generate the Applications to be deployed. The Git Generator: Files is what gives us the ability to pass values from a separate repo. It will look in a git repo for files that define the clusters and we can include overrides there. It effectively does what we were already doing with the values as overrides, but allows us to store those values in a separate repo. Here is an example:

apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: example
spec:
  generators:
  - git:
      repoURL: https://github.com/example.git
      revision: HEAD
      files:
      - path: "examples/**.yaml"
  template:
    metadata:
      name: '{{name}}-example'
    spec:
      project: default
      source:
        helm:
          valueFiles:
          - values.yaml
          values: |-
            {{values}}
        repoURL: https://github.com/bitnami/charts.git
        targetRevision: HEAD
        path: "bitnami/nginx"
      destination:
        server: '{{address}}'
        namespace: default

In the example repo you would have a yaml file (ie in-cluster.yaml) that defines your cluster and the overrides:

name: "in-cluster"
address: "https://kubernetes.default.svc"
values: |
  replicaCount: 2
  resources:
    limits:
      cpu: 100m
      memory: 128Mi

This will generate an Application with the values specified and targeting the cluster specified in the in-cluster.yaml file.

If we are just using this to pass values to the cluster Argo CD is running on, and don’t need to provide the ability to deploy to other clusters, we can simplify:

apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: example
spec:
  generators:
  - git:
      repoURL: https://github.com/example.git
      revision: HEAD
      files:
      - path: "examples/in-cluster.yaml"
  template:
    metadata:
      name: 'example'
    spec:
      project: default
      source:
        helm:
          valueFiles:
          - values.yaml
          values: |-
            {{values}}
        repoURL: https://github.com/bitnami/charts.git
        targetRevision: HEAD
        path: "bitnami/nginx"
      destination:
        server: "https://kubernetes.default.svc"
        namespace: default

And then we don’t need to include the name or address in the in-cluster.yaml file. That way the files will only contain the values we are trying to override and we can separate roles and responsibilities.

values: |
  replicaCount: 2
  resources:
    limits:
      cpu: 100m
      memory: 128Mi


More Stories

  • Accessibility: More Than a Buzzword, So Much More

    Zara Ikram
    May 14, 2021

    Websites govern their content to ensure it follows accessibility guidelines for the disabled. These practices allow equal access for all, which leads to inclusivity. We have to make a conscious effort to ensure our digital content is accessible for everyone.

  • Reflections of a Softrams Security Intern

    Nitya Parasuramuni
    July 26, 2021

    Online identity thefts, phishing attempts, ransomware attacks, and much more are at an all-time high. Our Softrams Security Intern provides an insight of translating her expectations into a career and provides some wisdom she's learned along the way.

  • Build a Great Product by Focusing on Quality

    Chris Hand
    September 14, 2021

    The best software lets users accomplish their goal without getting in the way. Build quality into your process to launch better produces and empower your users.