Continuous Delivery with Mutable Tags in ArgoCD

2025-02-15

In modern software development, the benefits of continuous delivery are well-known. Dev teams can enjoy immediate feedback on live backend environments, reducing time spent manually executing pipelines and manifest changes as well as increasing velocity on critical features. ArgoCD is a deployment orchestrator for Kubernetes workloads, utilizing a GitOps driven approach to ensuring an application's state matches that in version control. Container updates are typically rolled out by comparing the 'tag' of a container's image in a Kubernetes manifest with the tag of a container currently running on the cluster. If a mismatch is detected, ArgoCD will replace the existing pod with a pod matching the specified state.

But what if the tag is the same between the manifest and container in the Kubernetes cluster? The above approach is sufficient for immutable tags, such as when you tag a image in the form of myapp:1.0.0 and myapp:1.0.1 and the underlying image never changes. However, it is not uncommon for development and staging environments particularly to use the same tag, such as myapp:develop or myapp:latest-develop to represent the latest dev build. Or, a tag such as myapp:1.0.1-develop in which the referenced underlying image changes over the course of the sprint. These are considered mutable tags, and regardless there must be a solution to automatically rolling out new pods in which a referenced image tag is a mutable tag.

One such solution is the ArgoCD Image Updater. ArgoCD Image Updater is a standalone component that can work with your ArgoCD installation, container repository, and version control to automatically scan for changes to mutable tags and ensure pods stay up-to-date with the most recent image tied to that mutable tag.

Installation is simple. It is typically deployed alongside ArgoCD in the argocd namespace of a Kubernetes cluster, removing most setup steps. Next, the ArgoCD Image Updater must be configured on what Argo apps to work off of, what strategy to use for updating images, and what specific images to update. The final result is that your build system can build a container image, tag it with a mutable tag, and ArgoCD will automatically ensure this new image is the image being used on your live environment.

When an image with a new digest is pushed to a mutable tag configured to be watched by the Argo Image Updater, the Argo Image Updater will detect the change and modify a file in the repository to tell ArgoCD which digest to use for that specific image. When the repository is changed, ArgoCD will detect this change and ensure any pods using the referenced image and tag and override them to utilize the specified digest. This action results in any pods using the out-of-date image tag to be terminated, replaced by pods using the up-to-date image.

You can find a reproducible hands-on lab on setting the ArgoCD Image Updater up on my GitHub: https://github.com/JBLorincz/argocd-image-updater-example

Read more about the ArgoCD Image Updater here: https://argocd-image-updater.readthedocs.io/en/stable/