https://cloudposse.com logo
Join Slack
Powered by
I am a bit confused on Helmfile integration on Atm...
# atmos
p
I am a bit confused on Helmfile integration on Atmos. What is the use case vs Terraform provider Helmfile? There seems to be some integration to EKS. Has anyone gotten this to work with GKE, so that clusters created on Terraform side are handed over to Helmfile side? I am not sure how to approach kubeconfig, seems like it must be written to a file somewhere? Or maybe try somehow fetching it from outputs, and putting it to ENV variable before Helmfile invocation? Example would be great. 🙂
Atmos helmfile integration writes these vars.yaml files to the component directory. Should these be committed to git?
e
Honestly, it stems a little bit from our origin story.
We used helmfile long before we had atmos.
Yet we had a lot of customers still using helmfile, and we needed to standardize delivery.
So we added support for helmfile in atmos to accommodate that, but it also helped us think about the framework in a way that was tool-agnostic.
And this is what's enabled us now to add support for Packer and Ansible.
So to answer your question, we ourselves use the Terraform Helm provider predominantly.
I think what would make more sense is if atmos supported helmfile directly or kubernetes manifests.
But there are still some use cases for helmfile. For example, if you want to use helmfile together with Kustomize, it makes sense. But I would challenge anyone doing that to consider if it's absolutely necessary, because the level of abstraction is pretty high at that point.
p
I suppose since Kubernetes itself is a desired state store, a point could be made that why anything should be stored in terraform state file at all.
But yeah, probably provisioning in terraform (like provider helm or similar), might be better than using Atmos Helmfile thing
I had good experience of kbst/kustomization provider for TF. It actually renders all manifests to state file, and can do proper diff. This is only for installing necessary manifests to boostrap some other way (read: argo-cd) way of managing K8S 😄
👍 1
e
Yes, exactly. It's not an alternative yet to using something like Argo CD, but if you need to bring up Argo CD, then this is perfect.
a
Atmos treats Helmfile as its own independent component sitting alongside Terraform, so you can deploy or roll back Helm charts without touching your infra layer. The Terraform Helmfile provider runs everything through Terraform's lifecycle which gets messy when you just want to update a chart version. For GKE the handoff works fine in practice, after Terraform creates the cluster, grab the cluster name and region from its outputs and run gcloud container clusters get-credentials in a pre-hook before Helmfile kicks in. This writes the kubeconfig to a temp file like /tmp/kubeconfig-dev, you point the KUBECONFIG env var at it, and Helmfile just works from there. Same idea as the EKS examples, just swap aws eks update-kubeconfig for the gcloud equivalent.
👍 1
a
I see a use case for product team / product development, where we'd want to sync a product infra change with a chart update that refers to the changed or added infra. and I see that use case because we're also using ArgoCD, so we don't want TF with helm provider to directly interact with clusters, and we'd rather use atmos helmfile, but in a way that is not supported out of the box yet: just to generate the values.yaml file, run helmfile template, and push the generated manifests to the ArgoCD monitored repository. Cf. Add "atmos helmfile template" command · Issue #2069 · cloudposse/atmos
👍 1
2 Views
Open in Slack
PreviousNext
Powered by