Argo-cd: helmfile support

[estahn]

Is your feature request related to a problem? Please describe.
Similar to helm, helmfile support would be great.

Describe the solution you'd like
Support for helmfile.

[adamjohnson01]

@estahn, we created a helmfile config managment plugin in order to use helmfile

- name: helmfile
  init:
    command: ["sh", "-c"]
    args: ["helm init --client-only && helmfile repos"]
  generate:
    command: ["sh", "-c"]
    args: ["helmfile template --skip-deps"]  # need --skip-deps to avoid "No requirements found in ..." from helm on stdout

You will need to add a volume to the repo-server

volumes:
  - name: custom-tools
    emptyDir: {}

Then add an init container in order to download helmfile.

  - name: download-tools
    image: alpine:3.8
    command: [sh, -c]
    args:
    - wget -qO /custom-tools/helmfile https://github.com/roboll/helmfile/releases/download/v0.61.1/helmfile_linux_amd64 &&
      chmod +x /custom-tools/*
    volumeMounts:
    - mountPath: /custom-tools
      name: custom-tools

And finally add a volumeMount to mount the helmfile binary

volumeMounts:
  - name: custom-tools
    mountPath: /usr/local/bin/helmfile
    subPath: helmfile

[estahn]

@adamjohnson01 It sounds like you created something helmfile specific, but I assume you're just referencing the custom tools documented here. Correct?

[adamjohnson01]

@estahn, yes. That is correct.

[travisghansen]

I'm interested in this as well. How has your experience been so far @adamjohnson01 and @estahn?

• Do you use ENV vars (https://argoproj.github.io/argo-cd/user-guide/config-management-plugins/#environment ... specifically defined in the spec) in your helmfile?
• Have you run into any issues where separate helmfiles use the same repo name but point to differing repos?
• How do you handle --kube-version (helm v2) or --api-versions (helm v3)?
• Do custom config management plugins have access in some shape or form to the application data such as cluster endpoint etc (I'd like to be able to run kubectl api-versions for example to alter the command...see above question)?

I would be interested in making this a 'first class' plugin. Anyone else interested in collaborating on that effort?

[estahn]

We have gone ahead and moved things out of the helmfile into Argo apps.
Each helmfile entry is an Argo app in our case.

Overall we wanted to reduce the tooling and ArgoCD replaced 3 tools for us
(helm/tiller, helmfile, another internal tool).

Enrico

On Thu, 2 Jan 2020 at 4:52 am, Travis Glenn Hansen [e-mail]
wrote:

I'm interested in this as well. How has your experience been so far
@adamjohnson01 https://github.com/adamjohnson01 and @estahn
https://github.com/estahn?

• Do you use ENV vars (
  https://argoproj.github.io/argo-cd/user-guide/config-management-plugins/#environment
  ... specifically defined in the spec) in your helmfile?
• Have you run into any issues where separate helmfiles use the same
  repo name but point to differing repos?
• How do you handle --kube-version (helm v2) or --api-versions (helm
  v3)?
• Do custom config management plugins have access in some shape or
  form to the application data such as cluster endpoint etc (I'd like to
  be able to run kubectl api-versions for example to alter the
  command...see above question)?

I would be interested in making this a 'first class' plugin. Anyone else
interested in collaborating on that effort?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/argoproj/argo-cd/issues/2143?email_source=notifications&email_token=AACYNPQETQLIRGP4Z6G7RG3Q3S32VA5CNFSM4ILHQYY2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEH5HSNQ#issuecomment-570063158,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AACYNPR7XKERABE6YCF6HPLQ3S32VANCNFSM4ILHQYYQ
.

[travisghansen]

Ok thanks for the feedback.

[travisghansen]

Out of curiosity what is an Argo app?

[estahn]

ArgoCD groups resources that belong together as applications. It’s similar
to the release of a helm chart.

See
https://argoproj.github.io/argo-cd/operator-manual/declarative-setup/#applications

Sorry for the short response, I’m on holiday atm :)

On Fri, 3 Jan 2020 at 8:20 am, Travis Glenn Hansen [e-mail]
wrote:

Out of curiosity what is an Argo app?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/argoproj/argo-cd/issues/2143?email_source=notifications&email_token=AACYNPVO4R43X6B4RCQHJPTQ3Y47XA5CNFSM4ILHQYY2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEH7ESHQ#issuecomment-570312990,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AACYNPTSDXJVKVQGEXMHDALQ3Y47XANCNFSM4ILHQYYQ
.

[travisghansen]

Ah ok sure. I misunderstood your comment as using some argo-created templating engine. You still need ksonnet/jsonnet/helm/etc as templating/packaging engine. Support for helmfile in argo simply let's you more easily declare multiple helm releases (as it were) to be a single argo app.

In any case I appreciate the feedback. The most recent helm work in argo still doesn't feel quite right to me (I'm pretty new so I could be missing something). Proper helmfile support seems like the ideal solution (for me):

1. separation of config files from chart(s) (for 2 reasons, not storing config in the chart repo AND makes it easier to consume 3rd-party charts since you don't have to duplicate chart source code)
2. ability to manage apps via gitops (the new helm support isn't really gitops unfortunately)
3. ability to deploy more than 1 chart as part of an app as you mentioned above

After running through several edge-cases and toying around with argo generally, I think it's a great approach and tool. I really like what I'm seeing so far, just the helm support isn't sitting quite right yet for my various use-cases. Legit support for helmfile would knock those out real quick while also going well beyond in terms of capabilities.

[estahn]

We have been fairly extensive users of helmfile before ArgoCD. With ArgoCD
now supporting helm natively there is simply no need for helmfile in my
opinion.

We’re using the app of apps pattern to replicate the helmfile setup. The
values go into the application CR, so it has a good separation without lots
of files flying around. Each repo has a .argocd.yaml (containing the app
CR) which is applied by our CI tools.

As for 2, I don’t see how it’s not gitops but then in my opinion gitops is
being dogmatised to some extend.

As for 3, you can achieve this with helm
umbrella charts or app of apps.

Travis, if you wish I can elaborate more on this on Monday.

Enrico

On Fri, 3 Jan 2020 at 7:32 pm, Travis Glenn Hansen [e-mail]
wrote:

Ah ok sure. I misunderstood your comment as using some argo-created
templating engine. You still need ksonnet/jsonnet/helm/etc as
templating/packaging engine. Support for helmfile in argo simply let's
you more easily declare multiple helm releases (as it were) to be a
single argo app.

In any case I appreciate the feedback. The most recent helm work in argo
still doesn't feel quite right to me (I'm pretty new so I could be missing
something). Proper helmfile support seems like the ideal solution (for
me):

1. separation of config files from chart(s) (for 2 reasons, not
   storing config in the chart repo AND makes it easier to consume 3rd-party
   charts since you don't have to duplicate chart source code)
2. ability to manage apps via gitops (the new helm support isn't
   really gitops unfortunately)
3. ability to deploy more than 1 chart as part of an app as you
   mentioned above

After running through several edge-cases and toying around with argo
generally, I think it's a great approach and tool. I really like what I'm
seeing so far, just the helm support isn't sitting quite right yet for my
various use-cases. Legit support for helmfile would knock those out real
quick while also going well beyond in terms of capabilities.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/argoproj/argo-cd/issues/2143?email_source=notifications&email_token=AACYNPVEHKKB22SJZTC3WBTQ33LWRA5CNFSM4ILHQYY2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEIAM56I#issuecomment-570478329,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AACYNPRPVARCUXB5LYVRFMDQ33LWRANCNFSM4ILHQYYQ
.

[travisghansen]

For any future folks stumbling upon this I've created a small project over here starting to integrate helmfile a little more than skin deep: https://github.com/travisghansen/argo-cd-helmfile

It has full support for environments/selectors (including setting them dynamically via ENV vars) and completely specifying a helmfile.yaml as an ENV var.

Anyone wishing to collaborate is welcome :) After it settles a bit I may look into building it out as a first class plugin to the project.

[abdennour]

awesome community !
I want to give you more... and i want to know if really ArgoCD can replace helmfile or they can work together ?

This is what i achieved/

I let developers use the same helmfile to run their apps locally.

I let .env file is the single source of truth for both:

• docker-compose : which natively read from .env file
• helm : which get the .env with --set-file , and all charts are designed to convert the .env format into Secret resource.
• helmfile : is able to use --set-file with remote files, also i can override some .env and getting the new value from .Envrionment.Values which already fetched from Vault in Ci/CD pipeline.

This is a real example of my approach : https://github.com/abdennour/go-to-do-app

I am with reducing tools @estahn and i agree with you.
However, how can we have this great feature with ArgoCD.
I mean the feature of forcing developers to maintain use the same charts locally with DRY.