Custom Tooling

Argo CD bundles preferred versions of its supported templating tools (helm, kustomize, ks, jsonnet) as part of its container images. Sometimes, it may be desired to use a specific version of a tool other than what Argo CD bundles. Some reasons to do this might be:

  • To upgrade/downgrade to a specific version of a tool due to bugs or bug fixes.
  • To install additional dependencies to be used by kustomize’s configmap/secret generators. (e.g. curl, vault, gpg, AWS CLI)
  • To install a config management plugin.

As the Argo CD repo-server is the single service responsible for generating Kubernetes manifests, it can be customized to use alternative toolchain required by your environment.

Adding Tools Via Volume Mounts

The first technique is to use an init container and a volumeMount to copy a different version of a tool into the repo-server container. In the following example, an init container is overwriting the helm binary with a different version than what is bundled in Argo CD:

  1.     spec:
  2.       # 1. Define an emptyDir volume which will hold the custom binaries
  3.       volumes:
  4.       - name: custom-tools
  5.         emptyDir: {}
  6.       # 2. Use an init container to download/copy custom binaries into the emptyDir
  7.       initContainers:
  8.       - name: download-tools
  9.         image: alpine:3.8
  10.         command: [sh, -c]
  11.         args:
  12.         - wget -qO- https://storage.googleapis.com/kubernetes-helm/helm-v2.12.3-linux-amd64.tar.gz | tar -xvzf - &&
  13.           mv linux-amd64/helm /custom-tools/
  14.         volumeMounts:
  15.         - mountPath: /custom-tools
  16.           name: custom-tools
  17.       # 3. Volume mount the custom binary to the bin directory (overriding the existing version)
  18.       containers:
  19.       - name: argocd-repo-server
  20.         volumeMounts:
  21.         - mountPath: /usr/local/bin/helm
  22.           name: custom-tools
  23.           subPath: helm

BYOI (Build Your Own Image)

Sometimes replacing a binary isn’t sufficient, and you need to install other dependencies. The following example builds an entirely customized repo-server from a Dockerfile, installing extra dependencies that may be needed for generating manifests.

  1. FROM argoproj/argocd:v2.5.4 # Replace tag with the appropriate argo version
  3. # Switch to root for the ability to perform install
  4. USER root
  6. # Install tools needed for your repo-server to retrieve & decrypt secrets, render manifests 
  7. # (e.g. curl, awscli, gpg, sops)
  8. RUN apt-get update && \
  9.     apt-get install -y \
  10.         curl \
  11.         awscli \
  12.         gpg && \
  13.     apt-get clean && \
  14.     rm -rf /var/lib/apt/lists/* /tmp/* /var/tmp/* && \
  15.     curl -o /usr/local/bin/sops -L https://github.com/mozilla/sops/releases/download/3.2.0/sops-3.2.0.linux && \
  16.     chmod +x /usr/local/bin/sops
  18. # Switch back to non-root user
  19. USER $ARGOCD_USER_ID