Customize Component Behavior
In Atmos, every component is associated with a command. The command is what drives or provisions that component. For example, Terraform "root modules" can be used as components in Atmos. To instruct Atmos how to interact with that component, we must specify the command to run and and where the code for the component is located. Then, depending on the type of component, certain behaviors can be configured.
The components section of the atmos.yaml is how we do it. It defines how Atmos locates and executes your components.
Think of it as the bootstrapping configuration. This is where we can define the the command to run,
the base_path location of the components, and so forth.
Do not confuse this configuration with configuring components in stacks.
This configuration below is defined in the atmos.yaml and meant for specifying default behaviors for components,
such as what command to use when running Terraform commands, the base path for Terraform, and more.
Terraform Component Behaviorβ
For additional details on configuring Terraform components, refer to the Terraform and OpenTofu documentation.
The term βTerraformβ is used in this documentation to refer to generic concepts such as providers, modules, stacks, the HCL-based domain-specific language and its interpreter. Atmos works with OpenTofu.
atmos.yaml
commandSpecifies the executable to be called by
atmoswhen running Terraform/OpenTofu commands. If not defined,terraformis used. Can also be set usingATMOS_COMPONENTS_TERRAFORM_COMMANDENV var, or--terraform-commandcommand-line argument.Example values:
terraform,/usr/local/bin/terraform,tofu,/usr/local/bin/tofu-1.7.1.base_pathBase path to the Terraform/OpenTofu components.
Example value: "components/terraform". Can also be set using
ATMOS_COMPONENTS_TERRAFORM_BASE_PATHENV var, or--terraform-dircommand-line argument. Supports both absolute and relative paths.apply_auto_approveIf set to
true, Atmos automatically adds the-auto-approveoption to instruct Terraform to apply the plan without asking for confirmation when executingterraform applycommanddeploy_run_initIf set to
true, Atmos runsterraform initbefore executingatmos terraform deploycommandinit_run_reconfigureIf set to
true, Atmos automatically adds the-reconfigureoption to update the backend configuration when executingterraform initcommandauto_generate_backend_fileIf set to
true, Atmos automatically generates the Terraform backend file from the component configuration when executingterraform planandterraform applycommandsinit.pass_varsIf set to
true, Atmos automatically passes the generated varfile to thetofu initcommand using the--var-fileflag. OpenTofu supports passing a varfile toinitto dynamically configure backends
Helmfile Component Behaviorβ
atmos.yaml
commandSpecifies the executable to be called by
atmoswhen running Helmfile commands. If not defined,helmfileis used. Can also be set usingATMOS_COMPONENTS_HELMFILE_COMMANDENV var, or--helmfile-commandcommand-line argument.Example values:
helmfile,/usr/local/bin/helmfile.base_pathBase path to the Helmfile components.
Example value: "components/helmfile". Can also be set using
ATMOS_COMPONENTS_HELMFILE_BASE_PATHENV var, or--helmfile-dircommand-line argument. Supports both absolute and relative paths.use_eksIf not specified, defaults to
true. Can also be set usingATMOS_COMPONENTS_HELMFILE_USE_EKSENV var.kubeconfig_pathCan also be set using
ATMOS_COMPONENTS_HELMFILE_KUBECONFIG_PATHENV var. Example value:/dev/shm.helm_aws_profile_patternCan also be set using
ATMOS_COMPONENTS_HELMFILE_HELM_AWS_PROFILE_PATTERNENV var. Example value:{namespace}-{tenant}-{gbl}-{stage}-helmcluster_name_patternCan also be set using ATMOS_COMPONENTS_HELMFILE_CLUSTER_NAME_PATTERN` ENV var. Example value:
{namespace}-{tenant}-{environment}-{stage}-eks-cluster`