Image Update support for "Plugin" ArgoCD Applications.

[justin-watkinson-sp]

Is your feature request related to a problem? Please describe. ArgoCD supports a concept of Plugins, such as the kustomize/helm integration, and also used for extending ArgoCD for other use cases.

It appears that the argocd-image-updater only functions with the app.Status.SourceType is set to Kustomize or Helm (via auto-detect), and not when it is set to Plugin.

Describe the solution you'd like When the type Plugin is used, we could still implement Helm or Kustomize like-behavior for git-based workflows, whereas the image override file can be written back to git as if it were one of these two types.

Describe alternatives you've considered Mainly it would be dropping the use of the plugin, but it has proven to be handy at times for pre-Sync instrumentation of service discovery.

Additional context Relevant segment using the kustomized helm example:

resources:
  - health:
      status: Healthy
    kind: Service
    name: kustomize-release-name-helm-guestbook
    namespace: default
    status: Synced
    version: v1
  - group: apps
    health:
      status: Healthy
    kind: Deployment
    name: kustomize-release-name-helm-guestbook
    namespace: default
    status: Synced
    version: v1
  sourceType: Plugin
  summary:
    images:
    - gcr.io/heptio-images/ks-guestbook-demo:0.2

I'm not 100% sure if this is an ArgoCD thing, argocd-image-updater, or sort of both for a feature such as this. I understand there's a lot of "if" there especially if it couldn't reconcile using the imperative updated to the Application resource itself.

[jannfis]

This is an interesting proposal. Config management plugins in Argo CD don't have a concept of parameters (yet), but do support setting environment variables. I think to implement support for plugins, this would involve a coordinated change at Argo CD and the Image Updater:

• Adapt Argo CD's parameter override from Git to also support setting plugin environment
• Adapt Argo CD Image Updater to support applications of type plugin, and have user specify which environment variables to set similar to how we allow to specify the helm parameter names to set

Additional to that, the plugin would have to make sure that the image gets set correctly when rendering the manifests, e.g. given image name and tag specified in SOME_IMAGE_NAME and SOME_IMAGE_TAG (very simplified depiction):

if test "${SOME_IMAGE_NAME}" != "" -a "${SOME_IMAGE_TAG}" != ""; then
   kustomize edit set image ${SOME_IMAGE_NAME}=${SOME_IMAGE_NAME}:${SOME_IMAGE_TAG}
fi

[tuananh]

I'm having the same issue when i use argocd-vault-plugin. i only see this when i set log level to trace but not debug

is there a workaround for now @jannfis ?

[tuananh]

@jannfis looks like the force-update doesn't work for plugin type too.

[jannfis]

This is because plugins are not supported. From the first paragraph of the README:

Currently it will only work with applications that are built using Kustomize or Helm tooling. Applications built from plain YAML or custom tools are not supported yet (and maybe never will).

[tuananh]

Thanks @jannfis. I'm curious what's blocking it?

[jannfis]

I'm curious what's blocking it?

https://github.com/argoproj-labs/argocd-image-updater/issues/168#issuecomment-803644040

[tuananh]

I find a workaround so that i can use vault for secret management with image updater

there's ibm/argocd-vault-plugin but it's a plugin so image updater is out of the question for now.

So the workaround is to use a custom repo server image with all the tools you needed installed. in my case, i'm using helm-secrets plugin.

and then you will create your app as a Helm app. but the trick is to create a helm wrapper so that argocd repo server still think that it's using helm but in fact, it's using other tool for manifest generation (in my case, helm-secrets).

the output has to be yaml compatible so anything custom you do in the helm wrapper has to be clean up or just pipe to > /dev/null 2>&1

@jannfis would you like to document this in the docs as a workaround?

[RixTmobilender]

I'm also very interested in this feature, I'm using grafana tanka inside a custom image as a plugin that renders my Application (src) and I'd love to be able to maintain the freedom and low-lock in that using a customPlugin brings to the table.

[oleg-glushak]

Waiting for that a lot. Our use case is acdk8s application integrated as a plugin with ArgoCD. As a workaround we have to use keel.sh

[Jojoooo1]

Any new on that ?

[TheAnachronism]

Also interested if there are any developments on this part here. Would be nice to combine this tool with lets say argocd-vault-plugin.

[nabadger]

There's a slight workaround here for some of us perhaps (works for my use-case anyway - combined kustomize+tanka+envsubst).

I use a custom plugin which is essentially kustomize+envsubst (since kustomize doesn't really support vars from the env).

In the current image-updater releases there's no way to allow my applications into the allowed list of apps to consider...but on master there is this ( https://github.com/argoproj-labs/argocd-image-updater/blob/master/pkg/argocd/argocd.go#L522 ) (https://github.com/argoproj-labs/argocd-image-updater/pull/309 )

So essentially I can have a custom plugin and set the following annotations:

argocd-image-updater.argoproj.io/write-back-target: kustomization
argocd-image-updater.argoproj.io/write-back-method: git:secret:argocd/argocd-git-repo-image-updater

For completeness, my app looks like:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: my-app
  namespace: argocd
  annotations:
    argocd-image-updater.argoproj.io/image-list: app=my-app
    argocd-image-updater.argoproj.io/app.update-strategy: semver
    argocd-image-updater.argoproj.io/write-back-method: git:secret:argocd/argocd-git-repo-image-updater
    argocd-image-updater.argoproj.io/write-back-target: kustomization
spec:
  destination:
    namespace: sandbox
    server: https://kubernetes.default.svc
  project: sre
  source:
    path: rendered/my-app
    plugin:
      env:
      - name: CLUSTER_ENV
        value: ${CLUSTER_ENV}
      - name: CLUSTER_NAME
        value: ${CLUSTER_NAME}
      - name: CLUSTER_REGION
        value: ${CLUSTER_REGION}
      name: kustomize-genvsub
    repoURL: [email protected]:example-path/my-app.git

I suspect this is only good for anyone doing custom plugins with kustomize...

Note, our actual workflow actually focuses on tanka, but that can simply be wrapped by kustomize after running a tk export (kustomize edit add resource ./rendered/*.yaml). I guess this could be done as part of the plugin for those that are interested, but in our case, we store rendered manifests in Git, so the plugin is essentially a kustomize build with output piped through envsubst.

I'm unsure whether this is seen as a hack or not (given that the actual source-type is Plugin...and this forces it to Kustomize)

[lindsaygrace]

There's a slight workaround here for some of us perhaps (works for my use-case anyway - combined kustomize+tanka+envsubst).

I use a custom plugin which is essentially kustomize+envsubst (since kustomize doesn't really support vars from the env).

In the current image-updater releases there's no way to allow my applications into the allowed list of apps to consider...but on master there is this ( https://github.com/argoproj-labs/argocd-image-updater/blob/master/pkg/argocd/argocd.go#L522 ) (#309 )

So essentially I can have a custom plugin and set the following annotations:

argocd-image-updater.argoproj.io/write-back-target: kustomization
argocd-image-updater.argoproj.io/write-back-method: git:secret:argocd/argocd-git-repo-image-updater

For completeness, my app looks like:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: my-app
  namespace: argocd
  annotations:
    argocd-image-updater.argoproj.io/image-list: app=my-app
    argocd-image-updater.argoproj.io/app.update-strategy: semver
    argocd-image-updater.argoproj.io/write-back-method: git:secret:argocd/argocd-git-repo-image-updater
    argocd-image-updater.argoproj.io/write-back-target: kustomization
spec:
  destination:
    namespace: sandbox
    server: https://kubernetes.default.svc
  project: sre
  source:
    path: rendered/my-app
    plugin:
      env:
      - name: CLUSTER_ENV
        value: ${CLUSTER_ENV}
      - name: CLUSTER_NAME
        value: ${CLUSTER_NAME}
      - name: CLUSTER_REGION
        value: ${CLUSTER_REGION}
      name: kustomize-genvsub
    repoURL: [email protected]:example-path/my-app.git

I suspect this is only good for anyone doing custom plugins with kustomize...

Note, our actual workflow actually focuses on tanka, but that can simply be wrapped by kustomize after running a tk export (kustomize edit add resource ./rendered/*.yaml). I guess this could be done as part of the plugin for those that are interested, but in our case, we store rendered manifests in Git, so the plugin is essentially a kustomize build with output piped through envsubst.

I'm unsure whether this is seen as a hack or not (given that the actual source-type is Plugin...and this forces it to Kustomize)

Our flow is actually extremely similar, except that we do the env var templating just before the tanka export step. We wrote a go binary that goes through the libsonnet files treating them as go templates, before then invoking tk export.

This means that the rendered yamls that are wrapped by kustomize are completely vanilla, and don't require any argocd plugins etc.

[bluebrown]

How do you get it to write back? For me, it still says that It's skipping even though I have write-back set to git. If it wrote back, I could make my plugin use the file.

I see this in the logs:

time="2022-11-10T18:07:50Z" level=warning msg="skipping app 'opa-bundles' of type 'Plugin' because it's not of supported source type" application=opa-bundles

And this is my config:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: opa-bundles
  namespace: argocd
  annotations:
    argocd-image-updater.argoproj.io/image-list: app=imageimage:latest
    argocd-image-updater.argoproj.io/app.update-strategy: digest
    argocd-image-updater.argoproj.io/write-back-method: git
...

[gabrielfsousa]

Same problem with me, would luv to use argocd-image-updater with plugins !

[tesharp]

Had same challenge with cdk8s and found a workaround until argocd image updater can support it properly.

Setting write-back to kustomization as others have suggested works as long as there is a kustomization.yaml file, so I added the annotations and an "empty" kustomization file

argocd-image-updater.argoproj.io/image-list: image=myimage
argocd-image-updater.argoproj.io/write-back-method: git
argocd-image-updater.argoproj.io/write-back-target: kustomization

kustomization.yaml

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
images:
- name: myimage
  newTag: master-1234567

This file is not used by argocd since it has plugin defined and its getting the manifests from that. However, in cdk8s I then just read the kustomization.yaml file and replace all image tag versions from kustomization.yaml file. Then the generated manifests from cdk8s contains the image tag from kustomization.yaml file.

[bluebrown]

I created a thing that works as standalone. It can commit/pr to your repo as webhook endpoint. https://github.com/bluebrown/kobold.

[dagdynamik]

I created a thing that works as standalone. It can commit/pr to your repo as webhook endpoint. https://github.com/bluebrown/kobold.

I have also been using this which also now supports updating argo helm chart. note you need to use valuesObject for that. but works great lots of flexibility