search

cloudposse / terraform-provider-utils

The Cloud Posse Terraform Provider for various utilities (e.g. deep merging, stack configuration management)
https://cloudposse.com/accelerate
Apache License 2.0
97 stars 16 forks source link

Bump github.com/cloudposse/atmos from 1.64.1 to 1.66.0 #367

Closed dependabot[bot] closed 7 months ago

dependabot[bot] commented 7 months ago

Bumps github.com/cloudposse/atmos from 1.64.1 to 1.66.0.

Release notes

Sourced from github.com/cloudposse/atmos's releases.

v1.66.0

what

why

  • Add stacks.name_template section to atmos.yaml - stacks.name_template section allows greater flexibility in defining the naming convention for the top-level Atmos stacks

    • stacks.name_pattern configures the name pattern for the top-level Atmos stacks using the context variables namespace, tenant, environment and stage as the tokens. Depending on the structure of your organization, OUs, accounts and regions, set stacks.name_pattern to the following:

      • name_pattern: {stage} - if you use just one region and a few accounts (stages) in just one organization and one OU. In this case, the top-level Atmos stacks will use just the stage (account) in their names, and to provision the Atmos components in the top-level stacks, you will be executing Atmos commands like atmos terraform apply <component> --stack dev, atmos terraform apply <component> --stack staging and atmos terraform apply <component> --stack prod

      • name_pattern: {environment}-{stage} - if you have multiple regions and accounts (stages) in just one organization and one OU. In this case, the top-level Atmos stacks will use the environment (region) and stage (account) in their names, and to provision the Atmos components in the top-level stacks, you will be executing Atmos commands like atmos terraform apply <component> --stack ue2-dev, atmos terraform apply <component> --stack uw2-staging and atmos terraform apply <component> --stack ue1-prod. Note that the name_pattern can also be defined as {stage}-{environment}, in which case the Atmos commands will look like atmos terraform apply <component> --stack dev-ue2

      • name_pattern: {tenant}-{environment}-{stage} - if you have multiple regions, OUs (tenants) and accounts (stages) in just one organization. In this case, the top-level Atmos stacks will use the tenant, environment (region) and stage (account) in their names, and to provision the Atmos components in the top-level stacks, you will be executing Atmos commands like atmos terraform apply <component> --stack plat-ue2-dev, atmos terraform apply <component> --stack core-uw2-staging and atmos terraform apply <component> --stack plat-ue1-prod, where plat and core are the OUs/tenants in your organization

      • name_pattern: {namespace}-{tenant}-{environment}-{stage} - if you have a multi-org, multi-tenant, multi-account and multi-region architecture. In this case, the top-level Atmos stacks will use the namespace, tenant, environment (region) and stage (account) in their names, and to provision the Atmos components in the top-level stacks, you will be executing Atmos commands like atmos terraform apply <component> --stack org1-plat-ue2-dev, atmos terraform apply <component> --stack org2-core-uw2-staging and atmos terraform apply <component> --stack org2-plat-ue1-prod, where org1 and org2 are the organization names (defined as namespace in the corresponding _defaults.yaml config files for the organizations)

    • stacks.name_template serves the same purpose as stacks.name_pattern (defines the naming convention for the top-level Atmos stacks), but provides much more functionality. Instead of using the predefined context variables as tokens, it uses Go templates. Sprig Functions are supported as well

      • For the Go template tokens, and you can use any Atmos sections (e.g. vars, providers, settings) that the Atmos command atmos describe component <component> -s <stack> generates for a component in a stack.

      • name_template: "{{.vars.tenant}}-{{.vars.environment}}-{{.vars.stage}}" defines the same name pattern for the top-level Atmos stacks as name_pattern: "{tenant}-{environment}-{stage}" does

      • Since stacks.name_template allows using any variables form the vars section (and other sections), you can define your own naming convention for your organization or for different clouds (AWS, Azure, GCP). For example, in the corresponding _defaults.yaml stack manifests, you can use the following variables:

        • org instead of namespace
        • division instead of tenant
        • region instead of environment
        • account instead of stage

        Then define the following stacks.name_template in atmos.yaml:

        stacks:
  name_template: "{{.vars.division}}-{{.vars.account}}-{{.vars.region}}"

        You will be able to execute all Atmos commands using the newly defined naming convention:

... (truncated)

Commits
  • 674d2d0 Add stacks.name_template section to atmos.yaml. Add Go templating to At...
  • e4136fa Add providers section to Atmos manifests. Update docs (#555)
  • f0a622b Bump github.com/open-policy-agent/opa from 0.61.0 to 0.62.0 (#554)
  • 200e7e2 Bump the website group in /website with 1 update (#550)
  • 08dac04 include some protection on the azurerm backend when global does not exist (#...
  • d040264 Add Atmos CLI command aliases (#547)
  • 9c25fb0 Bump the website group in /website with 1 update (#545)
  • 1077b77 Simplify install page (#544)
  • See full diff in compare view


Dependabot compatibility score

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot show ignore conditions` will show all of the ignore conditions of the specified dependency - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
dependabot[bot] commented 7 months ago

Looks like github.com/cloudposse/atmos is up-to-date now, so this is no longer needed.