23 messages
π½οΈ
Andrew Eellsalmost 3 years ago(edited)
hello all π we are currently deploying AWS components (such as VPC/EC2 etc) in a stack from the atmos CLI, something like this:
is there a way to deploy all components in that same stack with a single CLI command?
otherwise, our CI/CD system has to define some sort of list and loop over all components and π
atmos terraform plan vpc -s <id-env-region>
is there a way to deploy all components in that same stack with a single CLI command?
otherwise, our CI/CD system has to define some sort of list and loop over all components and π
rssalmost 3 years ago(edited)
v1.32.5
what && why
Add docs for the new Atmos GitHub Actions
references
https://github.com/cloudposse/github-action-atmos-affected-stacks
https://github.com/cloudposse/github-action-atmos-component-updater
what && why
Add docs for the new Atmos GitHub Actions
references
https://github.com/cloudposse/github-action-atmos-affected-stacks
https://github.com/cloudposse/github-action-atmos-component-updater
johncblandiialmost 3 years ago
wild thought/idea incoming. π
are there plans for dynamically referencing remote state without updating a TF module to specifically call out remote state? Many times we just need the ARN anyway, but sometimes we need the name or similar.
Potential example:
Just like
So another thought is one component Atmos calls to get the remote values then takes those values and passes it to the expected component as it normally does (tfvars). That component just loops over all options provided, returns them to Atmos via TF outputs, Atmos replaces references in YAML, and creates the tfvars.
This slows down since you have to plan/apply 2 projects, but it allows us an easy path to referencing outputs without writing TF to reference them.
if no
are there plans for dynamically referencing remote state without updating a TF module to specifically call out remote state? Many times we just need the ARN anyway, but sometimes we need the name or similar.
Potential example:
map_environment:
APP_NAME: echoserver
S3_BUCKET: "{{ remote-state.s3-access-logs.bucket_id }}"Just like
context.tf, we could use remote_state (or similar) as a variable in a generic stacks-state.tf or whatever (since components already have a remote-state.tf) copied to a component. Then it looks up state, takes the values it requested, and uses them (the biggest caveat of how to use them; don't want coalesce(remote.blah, var.blah) littered on every possible value.So another thought is one component Atmos calls to get the remote values then takes those values and passes it to the expected component as it normally does (tfvars). That component just loops over all options provided, returns them to Atmos via TF outputs, Atmos replaces references in YAML, and creates the tfvars.
This slows down since you have to plan/apply 2 projects, but it allows us an easy path to referencing outputs without writing TF to reference them.
atmos terraform plan xyz -s my-stack -> runs terraform plan remote-state -s my-stack -> processes outputs -> creates tfvars file/backend json -> runs terraform plan xyz -s my-stackif no
remote-state references exist, it does what it does now.rssalmost 3 years ago(edited)
v1.33.0
what
Update Atmos logs
Add logs.file and logs.level to atmos.yaml
Update docs https://atmos.tools/cli/configuration
why
Allow specifying a file for Atmos to write logs to
Allow specifying a log level to control the amount of Atmos logging
Logs
Atmos logs are configured in the logs section:
logs:
file: "/dev/stdout"
# Supported log levels: Trace, Debug, Info, Warning, Off (Off is the default and is used if logs.level is not...
what
Update Atmos logs
Add logs.file and logs.level to atmos.yaml
Update docs https://atmos.tools/cli/configuration
why
Allow specifying a file for Atmos to write logs to
Allow specifying a log level to control the amount of Atmos logging
Logs
Atmos logs are configured in the logs section:
logs:
file: "/dev/stdout"
# Supported log levels: Trace, Debug, Info, Warning, Off (Off is the default and is used if logs.level is not...
Michael Dizonalmost 3 years ago
quick question about
but when I pull, I get this error:
how should the url be formatted?
atmos vendor. my component.yaml looks like thisuri: <http://github.com/cloudposse/terraform-aws-ec2-instance.git/?ref={{.Version}}|github.com/cloudposse/terraform-aws-ec2-instance.git/?ref={{.Version}}>
version: 0.47.1but when I pull, I get this error:
subdir "%253Fref=0.47.1" not foundhow should the url be formatted?
rssalmost 3 years ago(edited)
v1.33.1
Update documentation and examples for vendoring modules as components (β¦
β¦#364)
* Update documentation and examples to include instructions on vendoring components from github
* update: removed update from component.yaml
* update: provide more thorough instructions
* Update...
Update documentation and examples for vendoring modules as components (β¦
β¦#364)
* Update documentation and examples to include instructions on vendoring components from github
* update: removed update from component.yaml
* update: provide more thorough instructions
* Update...
Erik Osterman (Cloud Posse)almost 3 years ago
βοΈ explains how any module can now be used as a component without needing to write a component that wraps it.
Erik Osterman (Cloud Posse)almost 3 years ago
Basically any module can be used as a root module within the atmos framework.
rssalmost 3 years ago(edited)
v1.33.2
what
Rename atmos describe dependants to atmos describe dependents
Add alias to allow atmos describe dependants
why
There are two acceptable ways to spell dependent depending (no pun intended) on whether you are speaking American English (dependent) or British English (dependant)
what
Rename atmos describe dependants to atmos describe dependents
Add alias to allow atmos describe dependants
why
There are two acceptable ways to spell dependent depending (no pun intended) on whether you are speaking American English (dependent) or British English (dependant)
rssalmost 3 years ago
v1.33.2
what
Rename atmos describe dependants to atmos describe dependents
Add alias to allow atmos describe dependants
why
There are two acceptable ways to spell dependent depending (no pun intended) on whether you are speaking American English (dependent) or British English (dependant)
what
Rename atmos describe dependants to atmos describe dependents
Add alias to allow atmos describe dependants
why
There are two acceptable ways to spell dependent depending (no pun intended) on whether you are speaking American English (dependent) or British English (dependant)
rssalmost 3 years ago(edited)
v1.34.0
what
Update env stack config section
Allow using null to unset the ENV var
why
If it's set to null, it will not be set as ENV var in the executing process (will be just skipped)
Setting it to null will override all other values set in the stack configs for the component
This is useful if an ENV var is set globally in top-level stacks for the entire configuration, but needs to be unset for some specific components
test
Set TEST_ENV_VAR4 to some value
components:
terraform:...
what
Update env stack config section
Allow using null to unset the ENV var
why
If it's set to null, it will not be set as ENV var in the executing process (will be just skipped)
Setting it to null will override all other values set in the stack configs for the component
This is useful if an ENV var is set globally in top-level stacks for the entire configuration, but needs to be unset for some specific components
test
Set TEST_ENV_VAR4 to some value
components:
terraform:...
Austin Blythealmost 3 years ago
Can Atmos + Terraform be used to create new AWS accounts in an organization and provision resources into that new account as a single operation? Iβm assuming the account creation is asynchronous, but the Terraform resource docs donβt specify.
Girishalmost 3 years ago(edited)
@here Hi, everyone. i am trying to apply the resources through the bitbucket pipeline using atmos. using atmos workflows to do the plan and apply multiple components at a time and i am just wondering is there a way where i can apply only the output of the Affected components(
atmos affected describe) to atmos apply instead of going to whole workflow everytime. cheers π.
Amosalmost 3 years ago(edited)
Hi everyone,
I'm currently playing around with Atmos and as far as I understand, the components modules composed in way to provide naming convention within
Since I haven't see any terraform data source definition in vpc module by cloudposse,
I wonder how are you facing a scenario when you need to use an existing vpc instead of creating one with atmos components.
Is mixins the right solution for such cases?
I'm currently playing around with Atmos and as far as I understand, the components modules composed in way to provide naming convention within
context.tf and remote-state.tf for fetching outputs of other components.Since I haven't see any terraform data source definition in vpc module by cloudposse,
I wonder how are you facing a scenario when you need to use an existing vpc instead of creating one with atmos components.
Is mixins the right solution for such cases?
Abhijit Shingatealmost 3 years ago
Hi All, Is there a way to bypass atmos and use terraform module using plan terraform commands without stacks??
Abhijit Shingatealmost 3 years ago
I am trying to use the cloudposse/components/aws//modules/cognito module using plain terraform plan command
Abhijit Shingatealmost 3 years ago
but it gives me following error
Abhijit Shingatealmost 3 years ago
Error:
β 'atmos.yaml' CLI config files not found in any of the searched paths: system dir, home dir, current dir, ENV vars.
β You can download a sample config and adapt it to your requirements from <https://raw.githubusercontent.com/cloudposse/atmos/master/examples/complete/atmos.yaml>
β
β with module.website_cognito_setup.module.iam_roles.module.account_map.data.utils_component_config.config,
β on .terraform/modules/website_cognito_setup.iam_roles.account_map/modules/remote-state/main.tf line 1, in data "utils_component_config" "config":
β 1: data "utils_component_config" "config" {P
PePe Amengualalmost 3 years ago
Girishalmost 3 years ago
Hi @everyone, i am having an issue while running the
atmos describe affected --verbose=true in bitbucket pipelines. the repo was already cloned into the container in that particular step of the pipeline, but it giving an errors like below. Thank you πExecuting command:
/usr/bin/atmos describe affected --file affected.json --verbose=true --repo-path $BITBUCKET_CLONE_DIR
the target remote repo is not a Git repository. Check that it was initialized and has '.git' folder: repository does not exist
exit status 1
--------------
/usr/bin/atmos describe affected --file affected.json --verbose=true --sha $BITBUCKET_COMMIT
Cloning repo '<http://bitbucket.org/**********/********>' into the temp dir '/tmp/168236982171'
Checking out the HEAD of the default branch ...
authentication required
exit status 1
-------------------
Executing command:
/usr/bin/atmos describe affected --file affected.json --verbose=true --ref "refs/heads/$BITBUCKET_BRANCH"
Cloning repo '<http://bitbucket.org/*********/********>' into the temp dir '/tmp/16823701031153'
Checking out Git ref '"refs/heads/$BITBUCKET_BRANCH"' ...
authentication required
exit status 1
-------------------rssalmost 3 years ago(edited)
v1.34.1
what
Add ExecuteDescribeStacks function to pkg package and wrap the same function from the internal package
Add tests
why
We need to use the ExecuteDescribeStacks in the terraform utils provider, but all code in the internal package is not visible to the calling code. internal package is used to reduce the public API surface. Packages within an internal/directory are therefore said to be internal packages
references
<a href="https://go.dev/doc/go1.4#internalpackages"...
what
Add ExecuteDescribeStacks function to pkg package and wrap the same function from the internal package
Add tests
why
We need to use the ExecuteDescribeStacks in the terraform utils provider, but all code in the internal package is not visible to the calling code. internal package is used to reduce the public API surface. Packages within an internal/directory are therefore said to be internal packages
references
<a href="https://go.dev/doc/go1.4#internalpackages"...
rssalmost 3 years ago(edited)
v1.34.2
what
Add workspace to the outputs of atmos describe stacks command
why
We often need to know the terraform workspace for each component (taking into account that Terraform workspaces can be overridden per component, so they are not always the same as the stack names)
test
tenant1-ue2-dev:
components:
terraform:
top-level-component1:
workspace: tenant1-ue2-dev
test/test-component-override-3:
workspace: test-component-override-3-workspace
what
Add workspace to the outputs of atmos describe stacks command
why
We often need to know the terraform workspace for each component (taking into account that Terraform workspaces can be overridden per component, so they are not always the same as the stack names)
test
tenant1-ue2-dev:
components:
terraform:
top-level-component1:
workspace: tenant1-ue2-dev
test/test-component-override-3:
workspace: test-component-override-3-workspace
rssalmost 3 years ago
v1.34.2
what
Add workspace to the outputs of atmos describe stacks command
why
We often need to know the terraform workspace for each component (taking into account that Terraform workspaces can be overridden per component, so they are not always the same as the stack names)
test
tenant1-ue2-dev:
components:
terraform:
top-level-component1:
workspace: tenant1-ue2-dev
test/test-component-override-3:
workspace: test-component-override-3-workspace
what
Add workspace to the outputs of atmos describe stacks command
why
We often need to know the terraform workspace for each component (taking into account that Terraform workspaces can be overridden per component, so they are not always the same as the stack names)
test
tenant1-ue2-dev:
components:
terraform:
top-level-component1:
workspace: tenant1-ue2-dev
test/test-component-override-3:
workspace: test-component-override-3-workspace