https://cloudposse.com logo
Join Slack
Powered by
Hello so many new things added to atmos! As I'm se...
# atmos
c
Hello so many new things added to atmos! As I'm setting up a new atmos repo for my org I was putting a lot of thought into whether we would adopt your 
null-label
or 
<http://context.tf|context.tf>
mixin in all our components. I figured it was a must have until I stumbled on this new recommendation: https://atmos.tools/cli/configuration/stacks/#stack-naming-with-name_template-recommended If I understand that correctly then if we make sure we include a common set of our own variables in all components we can actually define/name our stacks using our own naming vars instead of just [namespace, tenant, stage, environment]? Are there any major gotchas to heading down this path?
a
yes, it's exactly how you described it
if you want to name your stacks using your own context variables, you can do it
note that these two concepts are not directly related to each other (but often work together): • naming your stacks using 
name_template
and any attributes from any Atmos section - note that you can use 
.settings.xyz
and not 
.vars.xyz
, in which case you don't need to have a set of context variables in all your components (which brings us to the next section) • Yes, you can have your own terraform components with your own set of context variables, in which case by using 
name_template
for the stack names you can (re)use the context variables to constract the stack names as well
also, the two features above usually work together with the 3rd one: • Using the context variables in all TF components, and a naming convention similar to CP 
null-label
(or your own) allows to uniquely and consistently name ALL AWS (and other clouds) resources (e.g. all S3 buckets, all VPCs, etc.)
the main purpose of the three features (if combined together) is: • Use a standard naming pattern to assign unique and consistent names/IDs to all cloud resources • Consistency name all Atmos stacks (and hence Terraform workspaces)
c
Yeah I'm just realizing that... If we roll our own we need to be careful to tackle all of that esp that writing proper resuable components is soo much easier with that well defined 
<http://context.tf|context.tf>
or null-label always available. Thanks!
this 1
a
I'd say there is another feature (#4) which works together with the three features described above: consistent tagging of all cloud resources
our 
null-label
pattern adds the context variables as tags to all resources - easy to see and manage
also, you can do the following:
in your Org-wide 
_defaults.yaml
Copy code
tags:
      # <https://atmos.tools/core-concepts/stacks/templates>
      # atmos describe component <component> -s <stack> -> returns all Atmos sections
      atmos_component: "{{ .atmos_component }}"
      atmos_stack: "{{ .atmos_stack }}"
      terraform_component: "{{ .component }}"
      terraform_workspace: "{{ .workspace }}"
      # Example of using the Sprig and Gomplate functions
      # <https://masterminds.github.io/sprig/os.html>
      # provisioned_by_user: '{{ env "USER" }}'
just a few lines of config, and all cloud resources will be tagged with Atmos component and Atmos stack
this is useful for Security and Compliance - if you provision AWS Config and AWS Security Hub, they will show you the findings - you look at the findings and see the tags. And by knowing the Atmos component and stack, you know right away what component in what stacks provisioned the resources
so it's much easier and faster to remediate
❤️ 1
c
Yes that is pretty wild. I have used 
null-label
before and was a huge fan. But I was foreseeing my current org struggling with the environment/region name definitions. Now I have even more to think about. Thanks!
2 Views
Open in Slack
PreviousNext
Powered by