hi there. Was wondering how people use chamber and atmos together. For example, how to get parameters from terraform (urls, keys) into helmfile or other tools. From what I saw it’s purely static config and does not support variable substituation, e.g to inject env variables dynamically. The same goes for secrets management. Or is the current understanding to just leave the env variable substitution logic inside TF and helmfile?
the design philosophy there to not make anything dynamic in the stack configs. otherwise we’re just creating a language on top of a language.
instead, it’s the responsibility for your terraform components (root modules) to read from SSM
chamber is no longer needed, since terraform reads from SSM flawlessly.
make your component as declarative as possible. if you need a secret, the path to the secret in SSM should be the parameter, not the value.
thanks for the quick reply. this sounds like the way to go to read a secret stored in SSM from terraform. my challenge is in reading a secret stored in SSM from helm/helmfile. for example previously I had terraform write the secret and then chamber injecting for helmfile to consume through env vars to create a k8s secret.
i haven’t checked yet but maybe there is a way already to consume secrets from ssm in helmfile
yes, you can read from SSM directly in helmfile
you can also use the
terraform-provider-helmfile which we are using for customers that have a lot of complicated helmfiles
for customers that have easier helm deployments, we’ve started using the native helm provider in terraform.
we also have this module https://github.com/cloudposse/terraform-aws-helm-release
Create helm release and common aws resources like an eks iam role - GitHub - cloudposse/terraform-aws-helm-release: Create helm release and common aws resources like an eks iam role
so if you use any of the terraform methods, you can access SSM that way, or as you mentioned you can read from SSM natively in helmfile
thanks for the pointers and generally for the help. I would like to use atmos in the short to midterm and execute helmfile straight from there. In particular the stack concept would fit well in my use case.
Is there anything like a migration guide for going from geodesic to new geodesic
unfortunately, no, however, remember it’s just a toolbox. so if any tools go away in the base image, just re-install. if any script/profile.d functionality goes away, just copy it in.
Aye we pretty much maintain the current version tooling wise anyway. Good to know for definite though
we’re kinda rolling on a custom build of 0.136.1 (as we mostly use it for the tfenv / structure / tools and keep terraform up to date via the docker file)
later versions assume-role vanishes etc guessing there was a major change of direction
We’ve moved to Leapp b/c we work predominantly with various SSO providers and this is the best tool we’ve found so far
as for assuming roles, we’re doing that in the terraform directly, so we don’t need to have the command itself