Add update strategy to restart deployment if digest for same tag has changed

[starcraft66]

Is your feature request related to a problem? Please describe.
I would like to use argocd-image-updater to update some container images I have pinned to the latest tag (specifically linuxserver.io container images) because some image have "specific" tags are very long and nonsensical e.g. linuxserver/qbittorrent:version-14.3.4.99202103270406-7346-81a7b0c03ubuntu20.04.1. I realize this locking an image tag to latest isn't usually a good idea but it's necessary in this case. I can't use the "latest" update strategy because the latest images are pre-release builds I don't want to use.

I initially thought I could do something like:

annotations:
    argocd-image-updater.argoproj.io/image-list: "qbittorrent=linuxserver/qbittorrent"
    argocd-image-updater.argoproj.io/qbittorrent.update-strategy: name
    argocd-image-updater.argoproj.io/qbittorrent.allow-tags: "regexp:^latest$"

But then I quickly realized that that will only check that the deployment is locked to linuxserver/qbittorrent:latest but doesn't check the digest to see if that tag has been updated upstream at the registry since they are mutable.

Describe the solution you'd like
I'd like to see a new strategy added that just watches a single tag for digest updates and then restarts the relevant deployment (given that it is using ImagePullPolicy: Always) so that it pulls an updated image.

[magmax]

I'd discourage this solution, due to the docker behavior: if the image tag is present in the host, it won't ask to the server if there is any change. The result of this is some hosts using an image and others using other, despite both are using "latest".

In addition, if you change the "latest" tag by "latest" in the pod, it won't redeploy it despite having ImagePullPolicy: Always, because there is no change in the spec.

The only best solution is, as you said, using permanent tags.

[starcraft66]

Yes, I'm aware that this situation is less-than-ideal. I would use another update strategy if I could but I am specifically using third-party container images to avoid burdening myself with maintaining my own images for third-party software when there are other people maintaining it, and being able to automate image updates is another logical step in that direction.

Would it be possible for ArgoCD to perform a rollout restart on the active pods since the manifest won't change?

[starcraft66]

Actually, newTag in a Kustomize manifest can be set to an image digest. Perhaps this update strategy should update the Deployment to a new digest using the <name>@sha256:digest naming scheme. That would definitely trigger a rollout of new pods.

[jannfis]

After some research, I guess we could introduce a new updater strategy for this purpose, something along:

argocd-image-updater.argoproj.io/<imageAlias>.update-strategy: digest=<tagName>

Which would be a mix of strategy latest (as, that it sorts results by creation time and picks the latest built image) and then uses <tagName>@sha256:<digest> to set the image tag accordingly. This would allow users to track a single, mutable tag (tagName) for updates. Using this update strategy would update when:

1. Manifests have specified the tag without digest (e.g. initially): Tag will be set to the digest found in the registry
2. A tag is found in the registry with a digest differing from what's currently set (e.g. another image as tagged with same tag name)

I think this would be possible to achieve.

[starcraft66]

That is exactly what I had in mind, it would be very useful to me and others I'm sure.

[jannfis]

I came up with #176, which can be configured slightly different than what I proposed above. The tag to be inspected will be configured in the image list as constraint, instead of a parameter to the update strategy:

argocd-image-updater.argoproj.io/image-list: foo=some/image:latest
argocd-image-updater.argoproj.io/foo.update-strategy: digest

The new strategy will be part of the v0.10.0 release, but I can't tell right now when we'll release it. But feel free to give it a spin from the latest version of Image Updater and let me know how it works for you. Documentation has also been added at https://argocd-image-updater.readthedocs.io/en/latest/install/strategies/#update-to-the-most-recent-pushed-version-of-a-tag

[starcraft66]

Thanks for the quick implementation, I test it and it works great! Looking forward to the next release, I am using the development build for the moment.

[NitishGupta9282]

Hi i am using argocd image updater to update my image automatically. I am facing some issue during implementation i have two images name nitish9282/apache:alpine and nitish9282/apache:master. My annotations are mentioned below

     `argocd-image-updater.argoproj.io/update-strategy: digest
      argocd-image-updater.argoproj.io/write-back-method: git
      argocd-image-updater.argoproj.io/image-list: nitish9282/apache:alpine,nitish9282/apache:master`

when image updater run it update both the images to latest sha value but i need two different values like nitish9282/apache:@<sha_of_alpine_tag> and nitish9282/apache:@<sha_of_master_tag>