#terragrunt (2019-05)
Terragrunt discussions
Archive: https://archive.sweetops.com/terragrunt/
2019-05-08
Is it me or do the terragrunt docs seem lacking? I’ve been having to dig through git issues to find out more. Any external doc references are appreciated
Maybe try https://community.gruntwork.io/
thank you
we (cloudposse) don’t use terragrunt
I really think the tool is great for what it’s trying to do, it’s just a bit frustrating
yeah - having used terragrunt where i’m currently working, i can’t recommend it again. it’s very opinionated in how modules are created and used with the “source=” stuff in the tfvars file.
trying to have more than 1 module in a state when not everything is copied to the “.terragrunt-cache” directory really annoyed me.
@Jonathan Le I thought each module in terragrunt was supposed to have it’s own state file? What were you trying to accomplish with multiple modules in a single state file?
You are right - each state should be it’s own module. Like 1 module per app/stack.
For me, TG and this method caused me to have a lot of copy/paste between modules though.
Like, there’d be a basic model of what an EC2 instance was to me and it would have been great to have this as a module like I had without TG.
I had to copy/paste between the resource configuration between similar TG modules to pull them off and the tradeoff really annoyed me.
It was great to have cool stuff like the following to try to keep things “dry”:
but the very similar resource config across TG modules was super duper annoying.
yeah that doesn’t look fun
are you talking about sharing stuff between modules too?
not sure what you mean about “sharing stuff between modules”. if you mean about datasources between the different module states, that works fine with TG.
if you mean about trying to stay DRY, i didn’t feel i was able to with TG.
e.g, I have very similar looking resource config for ec2 instances across various modules:
ahhhh we’re using a segregated ec2 module, we’re not embedding it into other modules as part of a full “service”
what do you guys use?
terraform natively supports intialization of projects using the -from-module parameter
you can pass that as an environment variable too
TF_CLI_ARGS_init=-from=module=....
so we define all of our root module invocations here: https://github.com/cloudposse/terraform-root-modules
we wrote an “env mapper” to make setting envs for terraform easier (but it’s not required)
here’s how we put it together:
the .envrc indicates the module we want to use
then we just call terraform init and it automatically imports the remote module
no wrappers required
damn that’s nice
I was worried about what happens when terraform is updated when using terragrunt
I’m gonna need to dig through all of this
yea, that’s what i like about this.
what about all the state stuff that terragrunt does for you, how are you guys handling that?
terragrunt is basically a task runner
there are a lot of task runners out there.
we use make predominantly with terraform
terragrunt helps keep your code DRY, but if you decompose thee different things that terragrunt does, you can easily accomplish it other ways
we use direnv to keep project level settings
we use make for a task runner
we use tfenv to make mapping envs easier (totally optional)
we use terraform init -from-module=... (using the TF_CLI_ARGS_init=-from-module=... env), to keep things DRY.
Whats the use for -from-modules= I never understood this workflow. Could you elaborate?
This allows you to bootstrap modules. Terragrunt uses it (if you look under the hood) too.
So in our case, we have a central catalog of “root” modules. Every time we merge to master, we cut a release.
When we want to use that module for an environment (e.g. prod) we call terraform init with -from-module to download it. That way we never copy/paste the code. It also allows us to have different environments pinned to different versions.
Terragrunt does the same thing. Only it writes it to a cache folder
Thanks, that part was clear tho, but why not just
module "this" {
source = "sourcelink"
vars = "that"
}
sort of thing
what is the advantage?
the combination of these things create a generalizable pattern that works formore than terraform
for example, we use helm and helmfile
we package all the tools in geodesic, which is our cloud automation image
we also use variant to define cli tools specific to our organization.
1
We have lots of examples of variant in use here: https://github.com/cloudposse/geodesic/tree/master/rootfs/usr/local/bin
this is all really good stuff to take back to my team
cool! happy to share more or answer any questions.
this is a great start, thank you
2019-05-31
Thanks for the feedbacl & Rex. Good call on these