#terragrunt (2020-04)
Terragrunt discussions
Archive: https://archive.sweetops.com/terragrunt/
2020-04-04
2020-04-14
Just a heads up for anyone else making use or considering usage of read_terragrunt_config, the function is unfortunately in a bad state.
Issue originally pointing out a concern with the function: https://github.com/gruntwork-io/terragrunt/issues/1107 Follow up issue from a maintainer pointing out that the issue is very complicated to fix: https://github.com/gruntwork-io/terragrunt/issues/1128 Issue where a maintainer recommends against using the function at the moment: https://github.com/gruntwork-io/terragrunt/issues/303
I’ve hit some nastly bugs with it that are particularly hard to debug, so this is just a friendly suggestion that you all consider those issues before deciding to make use of it
2020-04-28
How many levels of dirs are folks ending up with given example Terragrunt repo? Does this put people off?
my dev environment alone has 32 dirs….not sure how I feel about it….
test/dev
├── env.hcl
├── eu-central-1
│ ├── account-service
│ │ └── terragrunt.hcl
│ ├── compliance-service
│ │ └── terragrunt.hcl
│ ├── device-service
│ │ └── terragrunt.hcl
│ ├── graph-service
│ │ └── terragrunt.hcl
│ ├── idp-service
│ │ └── terragrunt.hcl
│ ├── profile-service
│ │ └── terragrunt.hcl
│ ├── region.hcl
│ └── resource-service
│ └── terragrunt.hcl
├── eu-west-1
│ ├── account-service
│ │ └── terragrunt.hcl
│ ├── compliance-service
│ │ └── terragrunt.hcl
│ ├── device-service
│ │ └── terragrunt.hcl
│ ├── graph-service
│ │ └── terragrunt.hcl
│ ├── idp-service
│ │ └── terragrunt.hcl
│ ├── profile-service
│ │ └── terragrunt.hcl
│ ├── region.hcl
│ └── resource-service
│ └── terragrunt.hcl
├── us-east-1
│ ├── account-service
│ │ └── terragrunt.hcl
│ ├── compliance-service
│ │ └── terragrunt.hcl
│ ├── device-service
│ │ └── terragrunt.hcl
│ ├── graph-service
│ │ └── terragrunt.hcl
│ ├── idp-service
│ │ └── terragrunt.hcl
│ ├── profile-service
│ │ └── terragrunt.hcl
│ ├── region.hcl
│ └── resource-service
│ └── terragrunt.hcl
└── us-west-2
├── account-service
│ └── terragrunt.hcl
├── compliance-service
│ └── terragrunt.hcl
├── device-service
│ └── terragrunt.hcl
├── graph-service
│ └── terragrunt.hcl
├── idp-service
│ └── terragrunt.hcl
├── profile-service
│ └── terragrunt.hcl
├── region.hcl
└── resource-service
└── terragrunt.hcl
32 directories, 33 files
Maybe @antonbabenko or others have thoughts as heavy Terragrunt users?
At my company we have hundreds of modules per env :man-shrugging:
It became 1000% more manageable for us once we got into a good CI/CD flow with atlantis. So now the flow is:
• Make changes to the underlying modules
• Run terragrunt-atlantis-config to generate atlantis config for our dependency graph
• Open a PR
• Atlantis plans everything that needs to be changed
• Approve PR, apply all the plans with one command
Sometimes those PRs can affect dozens of modules (especially because we do releases with staging and prod branches), but that’s no problem because it’s so easy to apply everything
What is your plan and apply run command?
workflows = {
stage = {
plan = {
steps = [
{
run = "terragrunt plan -no-color -out $PLANFILE"
}
]
},
apply = {
steps = [
{
run = "terragrunt apply -no-color $PLANFILE"
}
]
}
}
}
Did you try to hide all downloading message etc.?
Ours is:
workflows = {
default = {
plan = {
steps = [
# Verify that the user that commented "atlantis plan ..." is an admin
{ env = { name = "ADMINS", value = join(",", var.apply_admins) } },
{ run = "node ~/user_whitelist.js" },
# Create the plan
{ run = "node ~/terragroan.js" },
]
}
apply = {
steps = [
# Verify that the user that commented "atlantis apply ..." is an admin
{ env = { name = "ADMINS", value = join(",", var.apply_admins) } },
{ run = "node ~/user_whitelist.js" },
# Actually apply the plan
{ run = "terragrunt apply -no-color plan.out" },
]
}
}
The terragroan.js thing is the code in the gist here: https://gist.github.com/dmattia/0d17696bad1dffd90ec7c899e0343955
nice thanks
I changed it to
run = "terragrunt plan -no-color -out $PLANFILE 2> $PLANFILE.stderr || cat $PLANFILE.stderr"
maybe it will be enough
it show only stdout and stderr on exit code diff than 0
@David Thanks for the reply. Yes we do the same but the Atlantis workflow isn’t perfect (mainly saying that based off Atlantis triggers but totally depends how you have laid out the repo) - but still not sure how I feel about all these dirs…
the gruntwork folks seem open to an alternative that maps it out in a single file, if you’d prefer a flatter approach. i think they were looking for help with that pr
Hmm, maybe, not sure if that approach will play nicely with something like Atlantis though…
staging
└── terragrunt.hcl
production
└── terragrunt.hcl
Won’t work very well, a change to staging/terragrunt.hcl and Atlantis builds every staging project?
staging
├── production
│ ├── apps.hcl
│ ├── data-stores.hcl
│ └── networking.hcl
└── staging
├── apps.hcl
├── data-stores.hcl
└── networking.hcl
could work…
Comment on the issue! I don’t think they’re looking at custom hcl filenames…
apps/terragrunt.hcl, etc, might work…
The whole thing sounds very up in the air…
Argh.
Why is software so hard?
Lololol, anything software that is or looks easy has had some absolutely masterful designers and developers