#terragrunt (2021-06)
Terragrunt discussions
Archive: https://archive.sweetops.com/terragrunt/
2021-06-15
2021-06-18
Anyone feel like sharing some terragrunt insight? I have a solid project design using the 4 layers structure from Cloudposse but i’m confused on why all of a sudden my terragrunt isn’t detecting changes.
Also, would love to see more examples of structure in terragrunt, if anyone combines multiple modules into one hcl file (with a tf file in the same directory?) if it would simplify things over 1 hcl = one remote module each time instead of a composite of a couple. I get i can use dependencies for that, but it does add some complication when dealing with running directories in order at times.
You can put a [main.tf](http://main.tf) file in the same directory as your terragrunt.hcl file and put multiple modules in it, which often works well for us. This does require duplicating a few vars and outputs, but it’s often less copy-paste than you may imagine.
But more often we will leave having each terragrunt.hcl manage a single module, while having our CI manage making sure they are applied in the correct order. There are a few options here, but we use Atlantis (https://www.runatlantis.io/) with terragrunt-atlantis-config (https://github.com/transcend-io/terragrunt-atlantis-config) so that when we update a terragrunt module, our CI will automatically determine which other modules in our repo need to be updated/applied based on the listed dependencies.
In full disclosure, I did create terragrunt-atlantis-config and currently maintain it, so YMMV, but I did create it to solve almost the exact problem you’re talking about here.
let me know if you have any questions!
I wanted to try atlantis but didn’t have any Azure DevOps single click solution so didn’t have a chance to try and figure out how to do it all with atlantis and Azure DevOps in secure way and domain and all.
Looking at updated docs now as maybe a PR was created recently for Azure DevOps as shows integration.
Not sure yet if PR integration is included yet.
Will review your config too.
Normally I see single hcl + pointing to a local module directory but it gets complicated sometime. If instead it’s all in the current directory when I need to do a set of very tightly linked things maybe this will help.
Example…. ECS task with 4 containers. That means 4 folders or more with each task definition being built, but in reality i want them all together only. Would be a lot easier if the local hcl just was input for the current directory with the entire 4 + ecs task definition as they don’t stand alone.
Based your feedback I might try this and see if it helps simplify things.
https://github.com/terraform-aws-modules/terraform-aws-atlantis/pull/140 looks like the module still was pending thsi merge.
Didn’t know if made sense to pursue atlantis right now with all the other tools out there, but maybe it is if you are seeing great value from it
I’m dealing with a full buildout of all layers and if not for the clean input structure and lack of need to duplicate all my variable files from modules, I’d sure love native terraform. Terragrunt can be tricky to debug. However, the benefit of a clean terragrunt directory is pretty clear when I need to reproduce my prod deployment
2021-06-29
I’ve never used configured terragrunt to use an SSH key that wasn’t my default key. What is a sane way to set this up on a linux environment without mangling the URL committed to the repo? ( Which is what happens when the .ssh/config file is used to manage which SSH key is used when git is called. )
Have you tried setting GIT_SSH_COMMAND ?
Not sure if it’ll work with terragrunt and terraform, but it appears to be a thing.
I did a fair amount of googling into this yesterday. It seems like the most accepted answer is to go ahead and mangle the repo’s path. GIT_SSH_COMMAND did come up, during the googling, but it felt like more of a hack. Some of the considerations I found were that if you include more than one identify file in the SSH config for a given host, it can cause account bans, and in the case of git, which I wanted it for anyway, tended to fail because of the way git communicates to the hosts. I don’t recall exactly how GIT_SSH_COMMAND worked, but I really needed something that did different things based on URL itself, and while I did find something like an option for setting a git config property to rewite the URL with insteadof, it seemed like that was kind of backward for what I wanted. I finally conceded and just stuck with using .ssh/config to specify unique hosts that used specific keys – this guarantees that the right key is attempted for the right URL, the first time, without excessive configuration. It does mean that ‘fake’ URLs are committed to the repo, but it seems to the best practice, so I would expect others to recognize the pattern with the URL that is committed to the repo …