#geodesic (2021-09)

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’ve moved away from tfenv/direnv b/c it was not very conducive for gitops.

we document our current approach here https://docs.cloudposse.com/

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

https://www.leapp.cloud/

as for assuming roles, we’re doing that in the terraform directly, so we don’t need to have the command itself

See what you mean about the sso stuff; we use aws sso (backed by them) I totally missed the cli support coming in and how much less mess it is than dealing with assuming roles across accounts. Makes messing with boto simpler too

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

that’s why 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

ok. I think I found what I was looking for here https://github.com/roboll/helmfile/pull/906.

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

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.

This is means the stack yaml parser are the same for atmos and cloudposse/utils TF provider. Right?

It’s the same

The new atmos has a few improvements

So we need to use the code from atmos in the provider and not repeat it in two places

Update to the provider is coming

That is great! Love the work.

I need to figure out why the TF workspace names are different the two version. The new v1, is naming the workspace as {environment}-{stage}-{base-component-name} but the older atmos would name it {environment}-{stage}-{component-name} . The prefix works the same with both. Only the workspace name is affected.

Once I can figure it out, I am moving everything to v1.

oh, the new one uses ``{environment}-{stage}-{base-component-name}` as the prefix?

this is an oversight, will fix for backwards compatibility (although the name does not matter for new deployments)

Yes. I tried to re-deploy something I had previously deployed. I noticed it was trying to create all the resources because it was using different workspace (s3) name.

A new release is coming today

other nice enhancements are: • nested component folders • nested stack configs • new top level commands like atmos describe component

• fixed backend.tf generation

@Andriy Knysh (Cloud Posse) I do think we should update the main README with all the new commands and features

yes we should (will do it in the course of a few days)

@Brian Ojeda https://github.com/cloudposse/atmos/releases/tag/1.1.0

(fixed what you found with TF workspace for the derived components, not it works as the old atmos)

Thank you. I’ll be checking it out later today.

Works perfectly sir.

Also, we fixed our packages repository (deb, rpm, apk) and it now has the latest versions

are the modules terraform-aws-components going to be updated for 1.0?

someday

first we want to solve vendoring with atmos. once we do that I think we’re closer to supporting it.

we want to make it easier to upstream and downstream components via git

makes sense

what’s the issue with vendoring now?

internally, there’s a huge desire to support vendering. it comes up every single week. it’s been held up on the atmos rewrite, which is now done. So I hope it unlocks that functionality sooner rather than later.

we want to support vendoring natively in atmos as a core functionality.

so stack configs can specify an upstream origin and version

then run an atmos command to pull from there (and eventually push via a PR)

basically, when you run terraform init that is vendoring the providers locally

we want something like that in atmos for components

slick

then imagine things like atmos terraform upgrade eks (not sure the interface yet… maybe atmos upgrade component eks

yeah, is there a way to test any of the interdependencies?

no, i don’t see that ever being in scope

(too complex to merit the investment)

yeah

I do see us adding terratests to components

also, i see us adding support to import any module and make it a component dynamically

e.g. atmos terraform generate component vpn <https://github.com/cloudposse/terraform-aws-ec2-client-vpn> --version 0.2.0

(terraform components are opinionated terraform root modules that wrap other modules and have a state backend defined, which child modules do not have)

would that set up the providers as well

that’s already handled by terraform, so we don’t need to do anything about that

(we wouldn’t advise committing providers to source control)

our objective here is to support gitops best practices, vendoring and committing the source into the repo

for providers, i was referencing the way the modules are set up in terrafrom-aws-components

I’m not following

sorry, had a standup! here’s an example https://github.com/cloudposse/terraform-aws-components/blob/master/modules/iam-primary-roles/providers.tf

You guys are on point. Love the addition with v1.2; especially ATMOS_LOGS_VERBOSE . I have been using it daily since v1.1. I think the only thing missing is atmos workflow . Once it is available, assuming it will be, I can push it out to all our CI and teams.

Workflows are coming soon, thanks again for testing