terragrunt VS atmos

Link: https://terragrunt.gruntwork.io

name: Deploy on: push: branches: - main pull_request: branches: - main jobs: terraform: runs-on: ubuntu-latest steps: - name: Checkout repository uses: actions/checkout@v2 - name: Setup SSH uses: webfactory/[email protected] with: ssh-private-key: ${{ secrets.SSH_PRIVATE_KEY }} - name: Setup Terraform uses: hashicorp/setup-terraform@v2 with: terraform_version: 1.5.5 terraform_wrapper: false - name: Setup Terragrunt run: | curl -LO "https://github.com/gruntwork-io/terragrunt/releases/download/v0.48.1/terragrunt_linux_amd64" chmod +x terragrunt_linux_amd64 sudo mv terragrunt_linux_amd64 /usr/local/bin/terragrunt terragrunt -v - name: Apply Terraform changes run: | cd dev terragrunt run-all apply -auto-approve --terragrunt-non-interactive -var AWS_ACCESS_KEY_ID=$AWS_ACCESS_KEY_ID -var AWS_SECRET_ACCESS_KEY=$AWS_SECRET_ACCESS_KEY -var AWS_REGION=$AWS_DEFAULT_REGION cd bastion-ec2 ip=$(terragrunt output instance_public_ip) echo "$ip" echo "$ip" > public_ip.txt cat public_ip.txt pwd env: AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }} AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }} AWS_DEFAULT_REGION: ${{ secrets.AWS_DEFAULT_REGION }}

Terraform. I use it to manage infrastructure. It simplifies many things if at least a few people work on a project. As the project grows, it becomes massive, and maybe for better state management, you will need tools like Terragrunt to keep infrastructure-related code simple. If you use AWS as a cloud provider, you can also use AWS CDK. It’s a nice tool with Typescript support, but it’s available only for AWS, and if you need something from a different cloud infrastructure, the code will be much more complex than Terraform. That’s why I prefer the Terraform even for AWS.

You need to ensure your Action code is built before you attempt a terrform plan or apply. In our case we are using terragrunt which has a helpful before_hook, setup in the terragrunt.hcl file as follows:

https://github.com/hashicorp/terraform/issues/19932

My understanding is that people that have this as a first-class concern use something like Terragrunt to dynamically generate the HCL as needed.

https://terragrunt.gruntwork.io/

For Burrow here, I was was focused on shipping something and didn't want to spend time on generating that code just yet. But the project has gotten some attention so if this is a recurring request I'll probably do it.

Note that I intentionally chose the 17 AWS regions that are default enabled in every new AWS account, so it should only be if you want to customize it that this becomes important.

A Cloudformation Stacks based deployment to achieve multi-region would be another good (and perhaps better) option here. I could add that to the Makefile, with inspiration from your link there.

Terragrunt started to use OpenTofu as the default IAC tool, however, this was not a major release; instead, it was provided as a patch and users didn't expect to have any differences in the behavior. The original problem may be found here.

Next, head over to the Terragrunt GitHub page to download it.

Terragrunt is a Terraform wrapper, designed to fill in the gaps when it comes to large scale Terraform configurations.

Link: https://github.com/cloudposse/atmos

Hello from atmos | atmos

Tenv is a versatile version manager for OpenTofu, Terraform, Terragrunt, and Atmos, written in Go and developed by tofuutils team. This tool simplifies the complexity of handling different versions of these powerful tools, ensuring developers and DevOps professionals can focus on what matters most — building and deploying efficiently. Tenv is a successor of tofuenv and tfenv.

This is why we created atmos to make it easier to manage large multi-account architectures. As a result, our components are reusable across organizations, regardless of how many accounts and regions they operate, and we minimize the snowflakes. And we avoid code generation, which is hard to thoroughly test in an automated fashion. Without naming names, lots of tools for terraform rely on code generation, but I see it as an anti-pattern that should be avoided.

sorry did not find anything advanced. A better tool to make terraform scaleable is https://atmos.tools

Workspaces are incredibly practical, and we leveraging them at-scale with literally thousands of workspaces using atmos for terraform. There is so much FUD around workspaces that is either ill-informed or based on outdated information. Any company using terraform at scale will rely on tooling and conventions. It's up to that tooling to ensure you are using terraform safely. Atmos is one of those tools. I'm not saying that you have to use workspaces, but just that there's nothing wrong with workspaces themselves.

Check out atmos for a fresh take at managing terraform configurations and terraform workflows. Instead of managing HCL `.tfvar` files manually for configuration, it uses YAML, and supports concepts of imports (via deep merging), remote imports (anything supported by gogetter), mixins, inheritance, multiple-inheritance, vendoring of root modules, workflows, task runners (via custom subcommands), and much more. There's a bit of a learning curve and mind-shift required if coming from a Terragrunt background, but the experience is mindblowing after switching to it. Also, it's not limited to terraform.

We obviously don't have a project for your exact use case, but we have an open-source example repo that shows a fairly advanced scenario of using the Terraform Spacelift Provider https://github.com/spacelift-io/demo-preview-environments-manager, a simple quickstart of using it https://github.com/spacelift-io/terraform-starter and you can also see the CloudPosse Atmos project, for a very advanced scenario which generates lot's of Stacks based on your component specifications https://github.com/cloudposse/atmos.