terragrunt-infrastructure-live-example
terragrunt-atlantis-config
terragrunt-infrastructure-live-example | terragrunt-atlantis-config | |
---|---|---|
23 | 8 | |
731 | 567 | |
2.5% | 2.8% | |
2.8 | 7.8 | |
about 2 months ago | 8 days ago | |
HCL | HCL | |
Apache License 2.0 | MIT License |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
terragrunt-infrastructure-live-example
-
Terragrunt for Multi-Region/Multi-Account Deployments
In the official Terragrunt documentation there is a good article about how to set up a Terragrunt project and where to place modules. In fact, there is also a repository on GitHub providing an example project on how the creators recommend setting up Terragrunt. I certainly recommend going through that repository, because it is a good reference for a starting point. Having that said, I like to structure mine a little bit differently. My recommendation is to have different AWS accounts for each environment. Getting a new account usually is relatively easy to accomplish even if we are working in a corporate environment (your workplace most likely is using AWS Organizations to manage accounts). The existence of multiple accounts does not require additional costs, we only pay for what we use.
-
Seamless Cloud Infrastructure: Integrating Terragrunt and Terraform with AWS
NOTE: More information about the terragrunt.hcl file can be found in this example repository.
-
Manage multiple terraform environments in a single terraform workspace state file
Here's a pointer to an example repository with a Terragrunt monorepo (good, easy to manage), and each module called gets its unique statefile (good, smaller blast radius) where the tradeoff is learning a new tool and paradigm: https://github.com/gruntwork-io/terragrunt-infrastructure-live-example.
-
Migrate from terragrunt to terraform
I also highly recommend to check out how terragrunt recommends structuring your repo and even further details on this documentation page.
-
Conditionally set resource provider
https://github.com/gruntwork-io/terragrunt-infrastructure-live-example/blob/master/_envcommon/mysql.hcl https://terragrunt.gruntwork.io/docs/features/keep-your-terraform-code-dry/
-
Deploying globally (to all regions) on AWS with terragrunt
did you have a look at this example? https://github.com/gruntwork-io/terragrunt-infrastructure-live-example/blob/master/terragrunt.hcl
- How to structure Terraform with multi-env + multi-regions for TBD in monorepo
-
How to you segregate your dev and prod environments in the repository
Terragrunt! Using a scaffolding approach like this for inspiration https://github.com/gruntwork-io/terragrunt-infrastructure-live-example
-
Terraform / Terragrunt multi-environment - Pass in environment name
I would recommend taking a look at the example repo here: https://github.com/gruntwork-io/terragrunt-infrastructure-live-example. The layout you have doesn't look like a structure that would work well with terragrunt.
-
How you structure your terraform state?
A good example is in gruntwork-io / terragrunt-infrastructure-live-example repository and further documentation on Terragrunt's own documentation page.
terragrunt-atlantis-config
-
Pulumi Insights β AI generated IaC programs
I've also made the switch from managing a few thousand Terraform modules to handling most app-code things in Pulumi and have run into some of these limitations.
With Terraform + Terragrunt + Atlantis, we created https://github.com/transcend-io/terragrunt-atlantis-config and had an extremely robust and easy to use flow for updating all infra code.
We've since moved to an approach where more of our infra/security things are managed in Terraform (like Guardduty, SSO, Github repo settings, etc.) maintained by more devops folks, and our app code is mostly in Pulumi (lambdas, Fargate, CloudFront/CloudFlare CDNs, etc.). To accomplish this without something like Atlantis, we moved the app code infra deployments from being deployed continuously pre-merge via Atlantis to being deployed via `pulumi up` calls in our normal CI flows, so like right next to where we build the docker images and restart ECS services, as an example.
Overall I actually really love this flow. It is so, so much easier to create multi-regional infra in Pulumi with a quick for loop, and it's also much easier to do things like run esbuild over our code in typescript, and then bundle the output of that call and send it up to a Lambda function all from pulumi/typescript without needing separate build steps or to do things like using terragrunt pre-hooks or Docker build steps inside terraform provisioners, which I always found slow and clunky.
I would agree that Pulumi's plans are a disappointment though, exactly as you said.
Overall I've been happy with the change, and we've seen some improvements I think in the velocity that developers can launch services that meet our requirements.
-
Any examples of Terragrunt used in Github Actions?
I recommend atlantis with terragrunt-atlantis-config.
- Atlantis with Terragrunt
-
Error on terragrunt-atlantis-config on project generation
I know this is a bit too specific, it is about the ` terragrunt-atlantis-config tool, but in case anyone has come across this issue any help would be highly appreciated.
-
Do you use Atlantis for Terraform dev collaboration?
I've managed to make it work but it was really hard for me to set it up correctly. My biggest issue was that I didn't want every Terragrunt module to be run when I've opened a PR. Have a look at this project which helped me to run only the modules witch changes in every PR. Note that, I last used Atlantis a year ago so I don't know if they recently made changes for better Terragrunt support.
- Automating AWS Organizations & Best practices around using CI/CD for IaaC deployments
- Enhancing the Terraform Experience: Why we use Terragrunt
-
Terragrunt β Becoming one with its internal behaviors
The most recent release of Atlantis includes a new feature that allows you to register a hook before atlantis reads its atlantis.yaml config. You can now dynamically build your atlantis.yaml file in the atlantis itself. I think using something like terragrunt-atlantis-config can make working with terragrunt easier.
What are some alternatives?
terragrunt-infrastructure-modules-example - A repo used to show examples file/folder structures you can use with Terragrunt and Terraform
terraform-aws-ecs-atlantis - Terraform module for deploying Atlantis as an ECS Task
atlantis - Terraform Pull Request Automation
terraform-aws-atlantis - Terraform module to deploy Atlantis on AWS Fargate πΊπ¦
terraform-yaml-stack-config - Terraform module that loads an opinionated 'stack' configuration from local or remote YAML sources. It supports deep-merged variables, settings, ENV variables, backend config, and remote state outputs for Terraform and helmfile components.
org-formation-cli - Better than landingzones!
terraform-aws-eks - Terraform module to create AWS Elastic Kubernetes (EKS) resources πΊπ¦
modules.tf-demo - Real modules.tf demo (updated May 2021)
terraform-starter - Starter repository to play with Spacelift
terraform - Terraform enables you to safely and predictably create, change, and improve infrastructure. It is a source-available tool that codifies APIs into declarative configuration files that can be shared amongst team members, treated as code, edited, reviewed, and versioned.