#atmos - February 2023

15 messages

👽️

February 2023
rss
rssalmost 4 years ago(edited)
v1.26.0
what
Update atmos describe affected command
Add --repo-path flag to atmos describe affected command
Update docs https://atmos.tools/cli/commands/describe/affected
why
The --repo-path flag specifies the filesystem path to the already cloned target repository with which to compare the current branch, and it can be used when working with private repositories
Working with Private Repositories
There are a few ways to...
rss
rssalmost 4 years ago
v1.26.0
what
Update atmos describe affected command
Add --repo-path flag to atmos describe affected command
Update docs https://atmos.tools/cli/commands/describe/affected
why
The --repo-path flag specifies the filesystem path to the already cloned target repository with which to compare the current branch, and it can be used when working with private repositories
Working with Private Repositories
There are a few ways to...
rss
rssalmost 4 years ago(edited)
v1.26.1
what
Update Go templates in stack configs
why
If a context is not provided (as if using import with context), don't process Go templates in the imported configurations (templating can be used for Datadog, ArgoCD etc. w/o requiring Atmos to process them)
rss
rssalmost 4 years ago
v1.26.1
what
Update Go templates in stack configs
why
If a context is not provided (as if using import with context), don't process Go templates in the imported configurations (templating can be used for Datadog, ArgoCD etc. w/o requiring Atmos to process them)
rss
rssover 3 years ago(edited)
v1.27.0
what && why
Algolia search integration for Atmos docs
rss
rssover 3 years ago
v1.27.0
what && why
Algolia search integration for Atmos docs
Matthew Reggler
Matthew Regglerover 3 years ago(edited)
Hi, I’m, using Atmos in a test deployment to improve my understanding of the cloudposse terraform modules, and run into a problem when backfilling the access_roles for the tfstate-backend after the bucket has been created (and post-deployment of account + account-map )

Although I can view the outputs of the account-map module from a local command (atmos terraform output account-map -s core-gbl-root), attempts to access this data via component remote state are failing.
atmos terraform plan tfstate-backend -s core-ue1-root

...

│ Error: Attempt to get attribute from null value
│ 
│   on ../account-map/modules/roles-to-principals/outputs.tf line 12, in output "full_account_map":
│   12:   value       = module.account_map.outputs.full_account_map
│     ├────────────────
│     │ module.account_map.outputs is null
│ 
│ This value is null, so it does not have any attributes.

I can’t quite see how the tenant, env and stage passed to the remote state module in roles-to-principles differs from that used in the command line, so is there configuration elsewhere that I’ve missed?
rss
rssover 3 years ago(edited)
v1.28.0
what
Add component_path to the outputs of atmos describe affected command
why
Output the path to the terraform or helmfile component
Useful when we want to run certain workflows (e.g. in GitHub actions) for specific components and need to know what the component path is for each
Viacheslav
Viacheslavover 3 years ago(edited)
Hi,

I want to extract some JSON properties from terraform output, but have some troubles with it. When I am trying to save terraform output to the file:
atmos terraform "output -json > output.json" main -s security --skip-init

I got a error message, because Atmos recognize it as a single terraform command, not as a command and argument:
│ Error: Unexpected argument
│ 
│ The output command expects exactly one argument with the name of an output variable or no arguments to show all outputs.

Alternative option also doesn't fit my requirements:
atmos terraform "output -json" main -s security --skip-init > output.json

because output contains not only terraform outputs, but also atmos logs like
...
Executing command:
/usr/bin/terraform output -json
...

Is there a way to pass > output.json argument to the terraform in Atmos, or maybe turn off stdout of Atmos for a specific workflow step? Does Atmos native way allow it?
Final goal is to read the service principal password, created in terraform and call az login command to switch the user before running the next step.
rss
rssover 3 years ago(edited)
v1.29.0
what
Add --redirect-stderr flag to atmos commands
If --redirect-stderr flag is not passed, always redirect stderr to stdout for terraform workspace select command
why
The flag specifies the file descriptor to redirect stderr to when atmos executes subcommands like atmos terraform and atmos helmfile
Errors can be redirected to any file or any standard file descriptor (including /dev/null and /dev/stdout)
Useful in GitHub actions to prevent failures when any error sent to stderr makes the...
rss
rssover 3 years ago
v1.29.0
what
Add --redirect-stderr flag to atmos commands
If --redirect-stderr flag is not passed, always redirect stderr to stdout for terraform workspace select command
why
The flag specifies the file descriptor to redirect stderr to when atmos executes subcommands like atmos terraform and atmos helmfile
Errors can be redirected to any file or any standard file descriptor (including /dev/null and /dev/stdout)
Useful in GitHub actions to prevent failures when any error sent to stderr makes the...
Matthew Reggler
Matthew Regglerover 3 years ago(edited)
I’ve got a bit stuck with how the aws-sso component provisions identity account permission sets, can anyone spot what I’ve missed here:

following earlier conversations in this channel, for my atmos experiments I’m using the {tenant}-{stage} format for account names in account along with a global descriptor_formats addition (described here link to comment) resulting in account_map outputs like the following:

terraform_roles = {
  "core-auto" = "arn:aws:iam::{acc_id}:role/eg-core-gbl-auto-terraform"
  "core-identity" = "arn:aws:iam::{acc_id}:role/eg-core-gbl-identity-admin"
  ...
}

While this has worked well elsewhere, in aws-sso the policy-Identity-role-RoleAccess.tf uses stage alone to perform a full_account_map lookup, which is an invalid index (“identity” vs “core-identity”)

My solution was to implement a lookup like that described by @Jeremy G in the link comment above:

locals {
  # add this local to convert from "identity" to "core-identity"
  account_name = lookup(module.this.descriptors, "account_name", var.iam_primary_roles_stage_name)

  # edit this lookup to use my new local
  identity_account = module.account_map.outputs.full_account_map[local.account_name]
}

module "role_prefix" {
  source  = "cloudposse/label/null"
  version = "0.25.0"

  stage = var.iam_primary_roles_stage_name

  context = module.this.context
}

The alternative, setting var.iam_primary_roles_stage_name to the full “core-identity” string results in a bad role name later on as it is passed to to “stage” in the role_prefix null label module (you end up with arns like arn:aws:iam::{acc_id}:role/eg-core-gbl-core-identity-admin)

Is adding module.this.descriptors lookups to solve these kinds of issues the correct move here?
Igor
Igorover 3 years ago
Hi everyone. Are there any examples of directory structure that would be recommended for multi-cloud, multi-tenant environments using Atmos + Terragrunt + Terraform? I am interested in learning more about using Atmos to deploy multi-tenant, multi-cloud environments across AWS and GCP . Dev, Test, Prod can have multiple tenants that are almost identical but can run in separate cloud accounts across clouds. For example, for Prod we may have 2 tenants on aws and 5 tenants on GCP. The number of tenants is under 20, not in the 100s. (We are already using Terragrunt and looking for a better way to refactor our code to keep it DRY and easy to maintain across multiple environments/tenants).
Viacheslav
Viacheslavover 3 years ago
Hi everyone, can somebody advise me please?

I have a helmfile component helmfile in ./components/helmfile/ directory. The component contains a helmfile.d folder inside as well as environments and bases directories, there are no helmfile.yaml and this structure works well with standalone helmfile execution.

In Atmos I have a stack mid with some variables. When I execute atmos helmfile template helmfile -s mid, varfile ./components/helmfile/mid-helmfile.helmfile.vars.yaml created, but I get following error:

Executing command:
/usr/local/bin/helmfile --state-values-file mid-helmfile.helmfile.vars.yaml template
in helmfile.d/00-cluster-addons.yaml: environment values file matching "mid-helmfile.helmfile.vars.yaml" does not exist in "."

When I move this file from the root of component to the ./components/helmfile/helmfile/helmfile.d/directory, then it works well. But I don't get how to tell Atmos that it should use a state file is located in the root of the components folder, where it was generated, but not in helmfile.d/ ?

I know that I can run separate command atmos helmfile generate varfile with --file option, but will be nice if I can set the default destination of a state file or to change a path where helmfile is looking for the state file (in the root of component folder, not in helmfile.d).
Thanks!
rss
rssover 3 years ago(edited)
v1.30.0
what
Update and enhance Atlantis Integration
Update and overhaul the Atlantis Integration docs https://atmos.tools/integrations/atlantis/
Add --format and --file flags to atmos describe component command
why

Allow configuring Atlantis Integration in the settings.atlantis section in the YAML stack configs (instead, or in addition to, configuring it in integrations.atlantis in atmos.yaml)
Configuring the Atlantis...