thank you

the validation is per component, and it also participate in the whole inheritance chain. You can define settings.validation at any level (component, base component, catalog, stack, region, stage, etc.) and then import it. It will be deep-merged into the final config. This way, you can define it once and then reuse w/o specifying the same config in all components

we’ve added some preliminary quick start here https://github.com/cloudposse/atmos#validation

(still working on a docs site, a lot of atmos features that need to be described)

Just want to say thank you again. This validation feature adds a ton of value to atmos.

We have already started using both json-schema and OPA methods. It has already helped us find several issues with existing stacks. Additionally, I know without any doubt it will save time because we validate all stacks and respective components during the PR workflow.

It’s nice this feature came about at the same time TF finalized the optional object-property type constraints in v1.3. These features complement either other.

yes, 1 sec

run

atmos terraform --help

oooh I see, so I’d use the deploy command?

awesome. thank you, Andriy!

here we have a few diff things:

1. Branded/vanity domain vs. service-discovery domain. Branded domain is what your business uses on the internet. Service-discovery domain is what you use in your infra to provision services. Then, let’s say you have a service discovery domain for prod, e.g. [prod.mycompany.io](http://prod.mycompany.io) and your brand domain [mycompany.com](http://mycompany.com). In the DNS zone [mycompany.com](http://mycompany.com) you add a record pointing it to the service-discovery domain ``prod.mycompany.io`

1. Primary DNS zone vs delegated DNS zone. Primary zone is where you provision the service discovery domains. For example, you can provision [mycompany.io](http://mycompany.io) service discovery domain in the dns account, and then provision [prod.mycompany.io](http://prod.mycompany.io) in the prod account delegating DNS to the primary DNS zone

See https://serverfault.com/questions/530415/what-is-dns-delegation

so in the dns account, you can manage both branded/vanity domains and service-discovery domains, but they serve diff purpose

you can also provision service discovery domains in the corresponding account, e.g. [mycompany.io](http://mycompany.io) domain for prod provision in prod account

it all depends on your architecture and requirements

@Roman Orlovskiy

(this is not related to atmos (which is a CLI tool) so should be in a diff channel)

@Andriy Knysh (Cloud Posse), my apologies for using the wrong chat and thanks a lot for the detailed response, appreciate it!

I think I get it, but I have one more question. At which point exactly does it makes sense to have a separate domain for service discovery?

In my case, I don’t plan on having it currently, only a branded domain [example.com](http://example.com). So based on what you mentioned, it would make more sense to deploy the primary zone for it in the prod account instead of the dns account, and then use it for dns-delegated terraform component to create [dev.example.com](http://dev.example.com)/[test.example.com](http://test.example.com) delegated subdomains in separate AWS accounts, and [prod.example.com](http://prod.example.com) in the prod AWS account.

I will still be able to use terraform/ExternalDNS to automate creation of Route53 records in the delegated zones dev/test/prod, and then just point [example.com](http://example.com) to [prod.example.com](http://prod.example.com). in prod account.

What would be the benefits of the service discovery domain? I assume security would be the main one, but I am failing to find something on the web regarding this.

to have a separate domain for service discovery, and to have a separate dns account to manage all TLDs - depends on the organization and level of access you want to provide to diff people

you create a separate dns account if you want to completely separate the TLDs management, and want to give a serparate group of people that cn manage domains access to only the dns account

similar with branded vs. service discovery domain: branded domains can be managed only by a separate group of people (ideally in a separate dns account). Service-discovery domains are DevOps playground and the DevOps engineers manage them. So this is a separation of concerns and access level

if your scale is small (a few people managing all of that), then for sure you can use just one TLD (e.g. example.com) , provision the zone in prod, provision all prod subdomains in prod, provision dev subdomains in dev and delegate the dev zone to the prod TLD zone (by updating the name servers)

so it all depends on the org scale, security and level of access you want to give to diff people

That makes a lot of sense, thanks.

Btw, what is a recommended approach for pointing [example.com](http://example.com) to [prod.example.com](http://prod.example.com) ? CNAME cant be created for the apex domain, and Route53 Alias record can only point to a record in the same hosted zone, while [prod.example.com](http://prod.example.com) Alias record will be created using ExternalDNS in [prod.example.com](http://prod.example.com) hosted zone.

I wanted to avoid having to create additional resources in between like ALBs or maybe AWS Global Accelerator, and then just create A records with static ips, but this might be an overkill in my case. I am considering just giving ExternalDNS access to [example.com](http://example.com) DNS zone for it to create the Alias record pointing to k8s ALB by itself, but that is not ideal as I understand.

in your case yes, having just one zone and allowing external-dns to control it is the easiest solution. And you don’t have branded vs service discovery domains, it’s just one domain with subdomains (so don’t complicate it with DNS delegation and pointing the domain to one of its subdomains for which CNAME will not work and you’ll need something like Global Accelerator with a static IP)

Thank you! Really appreciate your help. You guys are doing amazing work. Cheers!

i guess something like that can be done with atmos. Many of those items we already implement using root components (which use modules, remote or local), and stacks

Yes, this could be brought together.

But I would suggest reducing the number of repos; at a minimum combining repos to some group of accounts, if not all of them. The stack git repos, are really just YAML stacks in our model. We would avoid the terraliths if possible.

The aws account git repos are just another component deployed that provisions and manages the accounts. We do not recommend a separate git repo per account (we used to do that ~4 years ago), but no longer recommend it. It’s not a gitops friendly solution.

My client’s customers each have access to the git repo for their aws account and stack instances, so we can’t combine them (git does not support that level of access control, and client’s must only have access to their own stuff).

Example to illustrate my original post:

• terraform root modules, 1 git repo per module: ◦ module-1 ◦ module-2 ◦ module-3

• stacks (1 git repo per stack, all stacks have their tfstate in s3, each stack is for a separate customer of my client) ◦ stack-1 ▪︎ dev folder (dev “instance” for this stack) • copies from HEAD of modules 1 and 2 • references remote state of account 1 • use aws creds for role created for and by account 1 ▪︎ staging folder (staging “instance” for this stack) • copies from release candidate commits/tags of modules 1 and 2 • references remote state of account 2 • use aws creds for role created for and by account 2 ◦ stack-2 ▪︎ dev folder (dev “instance” for this stack) • copies from HEAD of modules 2 and 3 • references remote state of account 3 • use aws creds for role created for and by account 3 ◦ stack-3 (has dev, staging and prod folders like the other stacks, with different combinations of modules)

• aws accounts (1 git repo per aws account, all have their tfstate in s3, each stack is for a separate customer of my client, account tf require significantly more sensitive permissions than stacks such as IAM role create/delete): ◦ aws-account-1 (customer 1) ◦ aws-account-2 (customer 2) ◦ aws-account-3 (in-house)

If we cannot combine the above into smaller number of git repos due to customer privacy concerns, what friction do you foresee if I try using atmos to drive this with above set of git repos?

better to schedule a call with me and review

ah I think it’s because I had auto_generate_backend_file set to false, since I copied it from the example

yes, set it to true

if you set it to false you can run ``atmos terraform generate backend vpc -s xxx`

thanks! I’m working through deploying the vpc component in two separate accounts (authenticating with AWS SSO) and I’m trying to get atmos to switch between them automatically. I think it should work if the backend file is generated automatically each time

yes, if you configure diff backend.s3 sections in diff accounts (diff YAML files). Also, the aes provider needs to use a dynamic role or profile to assume into the diff accounts

usually we do it like this

provider "aws" {
  region = var.region

  assume_role {
    role_arn = module.iam_roles.terraform_role_arn
  }
}

module "iam_roles" {
  source  = "../account-map/modules/iam-roles"
  context = module.this.context
}

so the role_arn is dynamic as well

gotcha, so does that require an identity role that you assume first that has permissions to assume the roles specified in module.iam_roles in each account?

also, does this setup play nicely with Leapp?

we assume identity role first, and we use Leapp. You can def do this, or use separate roles without going thru primary-delegated roles

gotcha, that makes sense. thanks! The other piece I was missing was passing the profile variable into the aws provider to make sure it’s always assuming the same profile that the backend is using.

atmos.yaml is required for running atmos for the following reasons:

1. It contains the paths to components and stacks, and all companies have diff config for that, so we can’t hardcode it in Go code

1. It contains definitions for atmos custom commands, which get parsed before atmos executes them (and they are available in atmos help

thanks you for pointing that out, the tutorial needs to be updated

@gabe are you using the tutorial docker image?

cc @Dan Miller (Cloud Posse)

@Dan Miller (Cloud Posse) just updated them, so they should be working.

it would be rad to add a GHA to validate them.

looks like the latest version of atmos has a requirement for the atmos.yaml config script, which wasnt required when the tutorial was updated. We should be pinning the atmos version for the tutorial’s Dockerfile, so that updates to atmos can’t break them / add additional steps. I’ll add a PR shortly for that

updated now. The latest version of the repo and the image should have the atmos version pinned to 1.4.20

Thanks Dan. Let me run through it.

Running through the tutorials, it looks like there are still some updates that need to be accounted for. Atmos v1.4.20 requires a name_pattern for stacks which the example.yaml stack does not adhere to, which results in the following error when running through the Getting Started with Atmos tutorial /tutorials/02-atmos

stack name pattern must be provided in 'stacks.name_pattern' config or 'ATMOS_STACKS_NAME_PATTERN' ENV variable

you can use https://github.com/cloudposse/atmos/blob/master/atmos.yaml - this is the latest CLI config

Yes, we can use an atmos configuration file, but the example stack in the tutorial is not currently setup with a tenant environment or stage so the tutorial example needs to be updated.

The stack name pattern '{environment}-{stage}' specifies 'environment`, but the stack 'example' does not have an environment defined

yes, the tutorial needs to be updated

fyi, this is a complete working example, it’s used in all atmos tests https://github.com/cloudposse/atmos/tree/master/examples/complete

agreed the tutorial still needs to be updated. I just wanted to raise that @Dan Miller (Cloud Posse) and @Erik Osterman (Cloud Posse) as Dan updated the tutorial to pin the version of atmos but there are additional items that need to be addressed and corrected within the tutorial.

ty. I’ll confirm later today and update if necessary

let me know if it makes better sense to log an issue on GitHub - happy to do that

~I’m not able to reproduce the error when running from Geodesic with atmos version 1.4.20. I’ve verified that no atmos.yaml exists on the image as well, yet I’m not getting any errors.~~~ ~@gabe when youre in the Geodesic container, what does atmos version return?~~~

I can reproduce it now. Will update shortly