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?

#168 (comment)

[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
) (#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: git@gitlab.com: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)