Discussions related to https://github.com/cloudposse/geodesic
Hello, I’ve just come across the Atmos project, it looks great! I had a question which I couldnt find any details on. Is it possible to access the outputs of a components from another components?
The use case I see is, if I use a terraform module to create say an IAM role and then I need to use the output (arn) in a helm chart, is there an easy way to do that?
yes, you can use the output
a component is basically a terraform module
you can use a single bucket for all the state and you can share the state too or use the outputs
so I can use the terraform output as input to a helm variable? Do you know if there are some examples that show how thats done?
yes, look into how we use
Opinionated, self-contained Terraform root modules that each solve one, specific problem - terraform-aws-components/remote-state.tf at bd8bfc64305d92607701050b9060d23713798ab9 · cloudposse/terrafor…
Here we look up the outputs from the
within Terraform I understand, my question is more between terraform and helm… If I have a resource created in terraform, how do I use the output of that in helm? or do I have to wait till that is provisioned and then manually copy the output value into the var for the helm file
I’m talking about Atmos specifically
I do not think you can use tf outputs as helm inputs
so by design, we do not intend to make atmos do any form of interpretation of the values in stack configs
instead, make your components more declarative
e.g. if you need component a to use values from components b, then then make a read the outputs of b
if you have a helmfile that needs outputs from terraform, have terraform write your outputs to SSM, then read those values natively in your helmfiles which supports the
helm does not have the concept of outputs, hwoever the terraform helm provider has outputs, but those are not controlled by the user
Thanks Erik, thats what I was looking for I hadn’t thought about using SSM for outputs. That will do the job
Is there an upgrade path from the older variant based version to the current golang rewrite of Atmos?
I have an existing project that has been using an older version of Atmos, I can’t tell which version but when I’m trying to build the project it appears to reference artifacts that no longer exist.
failed to get .variant files: stat: stat .variant2/cache/[email protected]_com_cloudposse_atmos.ref=master/atmos/modules/utils: no such file or directory
we’ll be working on README and help for the new atmos - all of that is missing
for now, this example is a complete working example that shows all the setup https://github.com/cloudposse/atmos/tree/master/examples/complete
Universal Tool for DevOps and Cloud Automation (works with terraform, helm, helmfile, istioctl, etc) - atmos/examples/complete at master · cloudposse/atmos
and this is a command set that the new atmos supports
# CLI config atmos version atmos describe config # Describe components and stacks atmos describe component <component> -s <stack> atmos describe component <component> --stack <stack> # Generate atmos terraform generate backend <component> -s <stack> atmos terraform write varfile <component> -s <stack> # this command will be changed to `terraform generate varfile` atmos terraform write varfile <component> -s <stack> -f ./varfile.json # supports output file # Terraform # (almost) all native Terraform commands supported # <https://www.terraform.io/docs/cli/commands/index.html> atmos terraform plan <component> -s <stack> atmos terraform apply <component> -s <stack> -auto-approve atmos terraform apply <component> -s <stack> --from-plan atmos terraform deploy <component> -s <stack> atmos terraform deploy <component> -s <stack> --from-plan atmos terraform deploy <component> -s <stack> -deploy-run-init=true atmos terraform workspace <component> -s <stack> atmos terraform validate <component> -s <stack> atmos terraform output <component> -s <stack> atmos terraform graph <component> -s <stack> atmos terraform show <component> -s <stack> atmos terraform clean <component> -s <stack> # Helmfile # All native helmfile commands supported including [global options] # <https://github.com/roboll/helmfile#cli-reference> atmos helmfile diff <component> -s <stack> atmos helmfile apply <component> -s <stack> # Helmfile with [global options] atmos helmfile diff <component> -s <stack> --global-options "--no-color --namespace=test" atmos helmfile diff <component> -s <stack> --global-options="--no-color --namespace test"
Thanks for the new version and related examples, but could you please explain how one can migrate from v0.22 to v1.0.0+? Is it just a question of remapping the files from the old directory structure to the new one? Any need to update other CLI tools (terraform, helmfile, …) at the same time?
Hey folks, I was looking back into geodesic and it appears things have changed. It looks like
[root.cloudposse.co](http://root.cloudposse.co) is deprecated now, but
[testing.cloudposse.co](http://testing.cloudposse.co) isn’t. However, the latter still references
root in the instructions.
Oh yes, we have the public docs which are pretty up to date
Also, we have commercial docs for customers :-)
The testing repo still runs some of our automation
root is obsolete now, how do you replace it? Also, you’ve deprecated
aws-vault – what is suggested as the replacement?
@Erik Osterman (Cloud Posse)?
What is deprecated is a foundational infrastructure spanning a dozen or more GitHub repos
Instead we moved to a mono repo approach
Are there newer instructions about how to setup your account or how geodesic has changed?