#terragrunt

Hi Guys, Should this create tags for backend resoruces (dynamodb and s3)? s3 and dynamodb are created with terragrunt, but without tags

Possibly a dumb question: I import aws resources that were manually created into terraform configs, and generally have gotten decent at it. (It helps that the latest terraform state show prints things out in hcl format.) The concept of importing things into terragrunt seems nearly impossible to get right. Would I be off base for settling on this:

1. New resources: use terragrunt and terraform modules for all new resources.
2. Existing resources: use straight terraform when need to import existing infrastructure.
3. New resources: terragrunt is acceptable when work flow is to create and destroy resources but without service disruption.

You can use functions like list() or element() inside of inputs to modify as what you want from the outputs.

Hi guys

Is there anyway I can use terragrunt.hcl with a module that contains a module inside it ?

for example:

In the terragrunt.hcl

terraform_version_constraint = "<0.12"
include {
  path = find_in_parent_folders()
}

terraform {  
  source = "git:<i class="em em-<ssh"></i>//xxx/custom_ecs_cluster.git?ref=terraform_0.11>"
}

inputs = {
  name                          = "xxx"
  profile                       = "xxx"  
  region                        = "xxx"
}

The module custom_ecs_cluster http://main.tf’s content:

module "aws_ecs_cluster" {
  source = "git:<i class="em em-<ssh"></i>//xxx:aws-ecs-cluster.git?ref=terraform_0.11>"

also, does anyone know how to transfer output of other dependency as list value ? as I declare the output in the module and testing with showing output successfully.But when running the terragrunt apply. it keep show the error as “ Underlying error: invalid primitive type name “list” example:

dependency "vpc" {
  config_path = "../vpc"
}
terraform_version_constraint = "<0.12"
include {
  path = find_in_parent_folders()
}

terraform {  
  source = "git:<i class="em em-<ssh"></i>//[email protected]/redcrane/sandbox/terraform-modules/linux-bastion.git?ref=staging>"
}


inputs = {
  profile                       = "xxx-sg1"  
  region                        = "ap-southeast-1"
  name                          = "xxx"
  environment             = "staging"
  number_hosts           = "1"
  instance_type            = "t2.micro"
  key_name                   = "xxx-staging"
  security_groups         [dependency.vpc.outputs.sg_id] <== this part is that allowed ? Or is there anyway that I can parse the output as list value to this   
}

quick question

• terragrunt –version /var/lib/jenkins/workspace/[email protected]/durable-dfb884a1/script.sh: line 1: terragrunt: command not found [Pipeline] } —- Have this error in my Jenkins build…. have any one come across this ever ?

@Sharanya is terragrunt in your path ?

in the PATH or is installed

+1

i dont think terragrunt in installed on the server

You will need to install it

Hi guys!, does anyone know how to solve dependencies between modules without having to run a terragrunt plan-all from the root directory? This is our current directory structure

root
├── dynamodb
│   ├── TableOneDir
│   │   └── terragrunt.hcl
│   ├── TableTwoDir
│   │   └── terragrunt.hcl
├── lambda
│   ├── LambdaOneDir
│   │   └── terragrunt.hcl
│   ├── LambdaTwoDir
│   │   └── terragrunt.hcl
├── secrets
│   └── terragrunt.hcl
├── sns
│   └── terragrunt.hcl
└── terragrunt.hcl

We need to run plan only in the LambdaOne directory and auto resolve a dependecy of a TableOneDir existing.

Also this are out hcl examples

terraform {
  source = "git:<i class="em [email protected]"></i>Company/core-of-sources.git//lambda/LambdaOneDir?ref=branch-one"
}

# Include all settings from the root terragrunt.hcl file
include {
  path = find_in_parent_folders()
}

# Dependencies
dependencies {
  paths = ["../../dynamodb/TableOneDir"]
}

Hi guys! @loren Have you found a solution to this https://github.com/gruntwork-io/terragrunt/issues/785 ? I wonder how people are solving odd (“new”) behavior of init hooks?

solve? no… workaround, yes… it’s not pretty

basically just gitignoring the copied file

in terragrunt.hcl

  after_hook "provider" {
    commands = ["init-from-module"]
    execute  = ["cp", "${get_terragrunt_dir()}/../../provider.tf", "."]
  }

in .gitignore

# Terragrunt files copied by hooks
dev/**/provider.tf

i tried your workaround of having a hook delete the file, but turns out we actually need it there because terragrunt tracks the files it copies from the terragrunt dir to its cache working dir, and purges anything from the cache working dir that it didn’t copy

Great, I ~solved~ workaround it exactly as you said. I am not sure there will be a proper fix in the near future. It starts to look a big ugly here and there with terragrunt…

yeah, i think we need the workflow to be part of terragrunt proper, rather than implemented with hooks

it’s not something the gruntwork folks do, so they just don’t see it as a real use case at the moment

As another not elegant hack I can run terragrunt plan --terragrunt-source-update to get source reinitiated every time, then I can have after_hook which will remove the file.

Right, yeah, that also works, but is slow

Can someone help with remote state references? Where to put

    data "terraform_remote_state" "vpc" {
    backend = "s3"
    config {
      bucket  = "${var.remote_state_bucket}"
      region  = "${var.aws_region}"
      key     = "${var.remote_state_key}"
      profile = "${var.aws_profile}"
    }
  }

this should goes to module configuration?

https://twitter.com/JustinWGrote/status/1159986326785015808

Hey all - has anyone figured out a way to use a before_hook to set environment variables that terragrunt can use?

I’m using direnv for directory based variables which works fantastic for single plan/applies, but it won’t work with an apply-all

Isn’t apply all a bit YOLO, considering you can’t plan-all and have it correctly reflect dependency changes as the apply on the former hasn’t run yet…?

Only looking to do it for an initial spin up

So create new aws account, run apply-all

Hey Folks, Trying to find some Terraform Modules related to AWS - app stream service ( for creating fleets and stacks) any help appreciated

Is anyone having issue with terraform 0.12 and terragrunt 0.19.8 not picking up credentials parameter when using gcs as backend ?

I am seeing this and unable to initialize

there have been a handful of changes to GCS backend in recent versions, maybe try 0.19.5? if that works, open an issue describing your config and use case

https://github.com/gruntwork-io/terragrunt/issues/767

HI all, just . quick one, I need some help installing terragrunt v18 on mac os, I’ve managed to do it via brew but that installs a dependancy of terraform v12 (i need v11). I went to releases, but not sure how to install Darwin_64 on mac? Any ideas, thanks

@Nehal You can remove terraform after it has been installed by terragrunt, or use tfenv to manage terraform installation.

thanks..didn’t know about tfenv, look into it

https://github.com/tfutils/tfenv - this is the one I am talking about

Hi @loren Have you thought best practices yet for running pre-0.19 with post 0.19 ? Seperate tree structure for post 0.19, or having both .tfvars and .hcl in one structure.

Use direnv with envrc :-)

In a geodesic shell, of course

Hi Erik! For the binaries i see that working, but not so much for the tfvars / .hcl implementqtion

Our strategy is that a given folder should only use one version of terraform. It doesn’t make sense to have 2 versions of terraform in the same project folder

I guess the problem with terragrunt is you have it operate across folders of different versions?

A project folder for us is a root module

well with terragrunt you can have a tree model with tfvars inheritance more or less, provider, account and region specific information can be autofilled this way. But this does mean that the tree is being traversed and being searched for other specific tfvars. From 0.19 this information is not in tfvars anymore but in .hcl, so in case one wants to slowly move certain root modules in this structure to v0.19/tf 0.12 that is something to be taken care of.

I wanted to be able to update quickly to tf 0.12 but with backwards compatible module changes, then leisurely update modules to take advantage of new syntax. Unfortunately there are just way too many, very basic (IMO) backwards incompatible changes in tf 0.12

So now it’s likely to be quite a while before we update active root configs to tf 0.12 since we have to go all in to do it

Also means probably won’t be using terragrunt 0.19 until then, and when we do we will also begin using it across all configs in the project simultaneously

Sucks because I want to use tf 0.12 now, but the backwards incompatibility means we won’t be able to adopt it for quite some time

So I guess, to answer the actual question, no, I haven’t thought about how to use tg 0.19 and tg <0.19 in the same project since at the moment I’m expecting eventually we’ll update everything at once

Thanks, sounds like you’re stuck with the same problem, and probably means we need to start with 0.12

Shipped today, https://github.com/gruntwork-io/terragrunt/releases/tag/v0.19.0

0.12 support on the way… https://github.com/gruntwork-io/terragrunt/pull/731

Thanks for the feedbacl & Rex. Good call on these

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

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

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)

https://github.com/cloudposse/tfenv

here’s how we put it together:

https://github.com/cloudposse/testing.cloudposse.co/tree/master/conf/acm

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

https://www.reddit.com/r/Terraform/comments/afznb2/terraform_without_wrappers_is_awesome/

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.

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

https://github.com/cloudposse/geodesic

we also use variant to define cli tools specific to our organization.

https://github.com/mumoshu/variant

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

Good afternoon #terragrunt - I have an odd situation I can’t explain and was wondering if one of you had any insight.

~Any ideas why plan-all in the root wants to create resources that already exist?~ This turned out to be a stupid mistake where I had created a new component in the live directory and it had a copy of the wave terraform.tfvars in it …

@Erik Osterman set the channel purpose: Terragrunt discussions Archive: https://archive.sweetops.com/terragrunt/

@Erik Osterman how are we suppose to use terragrunt in your new setup. I see eligible terraform.tfvars only in atlantis-repo sub-module.

https://github.com/cloudposse/root.cloudposse.co/blob/master/conf/users/terraform.tfvars

this is all you need

that said, I see no strong use-case for it anymore

I think make is a better task runner

and tfenv let’s use define module imports

https://github.com/cloudposse/testing.cloudposse.co/blob/master/conf/ecs/.envrc#L2

want to avoid tfenv, it seems over populating the environment by appending all current env variables with TF_VAR

with tfenv, we don’t need any wrappers to call terraform

fair enough

https://github.com/cloudposse/root.cloudposse.co/blob/master/conf/users/terraform.tfvars#L10-L13

i just don’t like this

overloading .tfvars with a non-portable terraform code that is vendor specific to terragrunt

also i am thinking may be its kind of simpler if we have a whitelisting variables rather then excluding regex

while envs are universal across apps

TFENV_WHITELIST is supported

I saw that, I was saying more about ideology. The whitelist value is .*.

what i don’t like is terraform telling me how envs should look in the first place. just like i don’t like chamber telling me that envs must be upper case (which doesn’t work with terraform)

so we have env warfare

Should be something like geodesic whitelist, and customer whitelist. Where we convert all the values required for geodesic modules. SPECIALLY the ones which we are currently getting

I just wish terraform and terragrunt would not stipulate a convention on envs and then things would just work. so tfenv is an ambassador. it does the dirty work.

the approach makes sense in the current context, its just having too much env variables makes my life hard

just set TFENV_WHITELIST and TFENV_BLACKLIST in your environment however you want

we were so busy mapping envs from one tool to the next. that’s what we wanted to avoid.

too much work to make a module get up. Its as good as doing a export variable in a tfenv.sh

so setting too many envs makes everyones life hard

but the env always has many envs, that’s just a fact-of-linux

on OSX, I have 87 envs that i never set

i have total 57, out of which I know about atleast 40

so in our Dockerfile we had SOOOOOO many envs. it was unmanageable.

so we’ve gotten rid of most of them (compared to before)

then moved to .envrc (direnv) so we localize these settings

yeah regarding that, I saw below snippet in rc.d terraform

# Translate environment variables to terraform arguments
	[ -z "${TF_FROM_MODULE}" ] \|\| export TF_CLI_INIT_FROM_MODULE="${TF_FROM_MODULE}"
	[ -z "${TF_STATE_FILE}" ] \|\| export TF_CLI_INIT_BACKEND_CONFIG_KEY="${TF_BUCKET_PREFIX}/${TF_STATE_FILE}"
	[ -z "${TF_BUCKET}" ] \|\| export TF_CLI_INIT_BACKEND_CONFIG_BUCKET="${TF_BUCKET}"
	[ -z "${TF_BUCKET_REGION}" ] \|\| export TF_CLI_INIT_BACKEND_CONFIG_REGION="${TF_BUCKET_REGION}"
	[ -z "${TF_DYNAMODB_TABLE}" ] \|\| export TF_CLI_INIT_BACKEND_CONFIG_DYNAMODB_TABLE="${TF_DYNAMODB_TABLE}"
	[ -z "${AWS_PROFILE}" ] \|\| export TF_CLI_INIT_BACKEND_CONFIG_PROFILE="${AWS_PROFILE}"
	[ -z "${AWS_ROLE_ARN}" ] \|\| export TF_CLI_INIT_BACKEND_CONFIG_ROLE_ARN="${AWS_ROLE_ARN}"

yea, that’s strictly for backwards compatibility

I didn’t want to tell everyone to rewrite their envs

the TF_CLI_* convention is canonical

which i assume should be good enough if we have all variables in left hand side set

~the ones on the LHS are the legacy ones we’ve had in our docs~

yeah, my point even if we are using the legacy variables, things should work

I mean the ones in the [ ... ] conditionals

e.g TF_BUCKET_REGION

yep, so using that mapping they will continue to work

but TF_CLI_INIT_BACKEND_CONFIG_REGION is canonical

in that it maps precisely and consistently to the TF_CLI_ARGS_init=-backend-config=region=blah which is the terraform native convention

technically, even tfenv isn’t needed. it’s just a convenience.

so we can set k/v pairs as ENVs

rather than mucking with the tf flags in compacted envs

this is what I am doing currently

the compacted envs?

I don’t like terraform native envs

that’s what it looks like.

PIA to toggle individual fields

so we just came up with a convention to not do that. but that’s opinionated and might not suit all parties.

I like it b/c you can set envs at different levels (E.g. Dockerfile, project, parent folder, etc)

i was doing something like export TF_CLI_INIT_BACKEND_CONFIG_BUCKET=niki-root-terraform-state

that looks good

but its still asking me for bucket name

TF_CLI_INIT_BACKEND_CONFIG_BUCKET="cpco-testing-terraform-state"

that’s what we are doing

this definitely works with every terraform * command

if you use tfenv to cast it to the TF_CLI_ARGS_blah=....

in short with my legacy variables, use_terraform and terraform init should give me required resuly

true

i can’t use use_terraform also

is what we have in our docker file

has to source it manually

https://github.com/cloudposse/geodesic/blob/master/rootfs/etc/profile.d/direnv.sh

https://github.com/cloudposse/geodesic/blob/master/Dockerfile#L220

something like this is happening

https://github.com/cloudposse/geodesic/tree/master/rootfs/etc/direnv

zoom?

https://zoom.us/j/4155358615

sure

any best practices on how to reference between terraform dependencies on different terragrunt modules. eg. I have vpc as a module and bastion as another module (terragrunt modules both) and I need to reference the vpc-id (and subnet-ids) from vpc in bastion

yes, use SSM

https://www.terraform.io/docs/providers/aws/r/ssm_parameter.html

or use remote state provider

https://www.terraform.io/docs/providers/terraform/d/remote_state.html

we have examples of both in this repo https://github.com/cloudposse/terraform-root-modules

@Samuli Are these modules being run in the same Terraform run? (do they share state)

It would be straight forward if they did but with terragrunt modules they are not. So I went with remote_state..

I noticed terragrunt compatibility for the first time here: https://github.com/cloudposse/root.cloudposse.co/blob/master/conf/terraform.tfvars

Is this something you work to support in addition Geodesic?

yes, so I wanted to demonstrate that geodesic is a superset of tools including terragrunt

for now, we’re still not sold on adopting terragrunt (for our purposes)

but I understand people have a large investment in terragrunt (@antonbabenko) so figured we should have a story for showing how it’s done with geodesic.

https://github.com/cloudposse/docs/issues/351

So, I’m just starting out with Terraform. There is not a lot of complexity in our stack, but I want to get off on the right foot and keep things simple. So far, I’m not a big fan of having nearly identical backend configs everywhere, and also I don’t really feel comfortable with the notion of workspaces. Seems like Terragrunt could address these concerns, but it’s a wrapper and I don’t know if it’s a good idea for me to be starting off with it. Thoughts? Should I try to incorporate Terragrunt in to the solution, or keep to Terraform for now and come back when I have more experience and legitimate issues that need to be solved?

Good questions… so I think that it’s a good idea to first master the fundamentals of terraform before relying on terragrunt. It’s possible to keep things dry without needing to use the wrapper approach. I’m also not keen on relying on terragrunt as a wrapper, but have used it in a few circumstances.

I don’t like how the varfiles are overloaded with interpolations which make them non-portable

Have you seen https://github.com/uber/astro?

We’re not currently using it, but it’s an interesting alternative

We’re using mostly Makefiles if we need any more complex orchestration

I’m not a big fan of having nearly identical backend configs everywhere

We’re using this script to initialize state: https://github.com/cloudposse/geodesic/blob/master/rootfs/usr/local/bin/init-terraform

that way we don’t need to hardcode any backend configs in source control

Also terragrunt it might take some time before terragrunt supports terraform 0.12 , but that might not matter

Thanks, this is helpful. There is this temptation to try to set everything up perfectly from the get-go, but ultimately it’s a process, and I feel like it’s not healthy to try to skip too many steps in the evolution.

Haha, I can relate to that.

I don’t think you can necessarily go wrong with using terragrunt.

The good thing is you’ll decompose everything nicely into lots of modules and organize things as you should.

You can remove terragrunt as well, down the road.

….that said, have you seen our strategy?

We use docker and multi-stage builds to keep things dry

run everything in containers

…that is, we run even our “infrastructure as code” in containers

https://github.com/cloudposse/geodesic

Great, more late night reading material for the holidays! Haha, thanks for that, it looks interesting. And thanks for addressing my Terragrunt question; I agree - seems like the key is to get the modules in place and I’ll have flexibility to adjust my approach in the future.

exactly - that’s the most important thing

write small reusable, composable modules that build on each other

do not embed any stage or environment specific settings - those should be inputs (variables)

consider using terraform-null-label to consistently generate resource name

look into chamber for secrets

look into aws-vault for assuming roles

also, recommend studying a lot of other modules to see how they are organized and broken down

Yes, great advice, much appreciated.

There’s a #terragrunt channel!!

But of course! We don’t discriminate :P

LOL

@Erik Osterman set the channel topic:

The icon is Gruntwork logo, not terragrunt product ;) There is an open issue about missing logo for terragrunt

Haha yea

I guess I should rename the icon

It was a compromise

Yeah, np really

Do you need icon for http://modules.tf ? I will make one :))

haha, go for it

@joshmyers has joined the channel

@jerry has joined the channel

Hello everyone, I am trying to run terragrunt plan using circleci and I am getting the following error

 [terragrunt] [/root/project/cloudfront_frontend] 2018/11/26 03<i class="em em-21"></i>58 The non-interactive flag is set to true, so assuming 'yes' for all prompts
[terragrunt] [/root/project/cloudfront_frontend] 2018/11/26 03<i class="em em-21"></i>58 Creating S3 bucket cb-terraform-infra-state-sit
[terragrunt] 2018/11/26 03<i class="em em-21"></i>59 AccessDenied: Access Denied
	status code: 403, request id: 35E32BD7CF45BED5, host id: f3c85r+xX5QKBmRdlhW8JCQyj+AqUtKGZWwLvbuo/YkjErGKUuVJ6kAs0NIjooDC83uXs1JkjXc=
[terragrunt] 2018/11/26 03<i class="em em-21"></i>59 Unable to determine underlying exit code, so Terragrunt will exit with error code 1
Exited with code 1

I have the credentials in place ~/.aws/credentials . It works perfectly in local. Not sure how to fix it

I am using the following docker image antonbabenko/terracing:v0.0.6

It looks like permission issue but I have given fullAdminAccess to the user.

hrm… so shouldn’t need to write credentials to ~/.aws/credentials

using the standard AWS envs should be sufficient

AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY

in fact, i’d try to get it working with ENVs locally (for testing)

then once you find the working combination, that’s what you’ll set in circle

@Bogdan has joined the channel

Hi guys! If you want to check how I do dynamic parameters in static terraform.tfvars with Terragrunt and tell me if you know better solution, you should read my blog post (and try it) - https://medium.com/@anton.babenko/modules-tf-convert-visual-aws-diagram-into-terraform-configurations-e61fb0574b10

@ has joined the channel

What is the usecase for terragrunt with workspaces module etc?

@Erik Osterman not yet, but should do it after AWS re:invent.

pass --terragrunt-source-update

@Vi ^^^

terragrunt uses a hash of the source url to determine whether the source has changed. if you are using tagged/versioned modules, that works great… you update the source ref, and terragrunt will detect the changed hash and automatically pull down the new version

if you are not using a version ref in your source, then you can use --terragrunt-source-update to force terragrunt to pull down the source

has anyone played around with the terraform 0.12 rc with terragrunt?

@stephen has joined the channel

@Vi has joined the channel

Hi, I was working with terragrunt and observed that terragrunt does not pick up the changes automatically for modules. Is there any way to sort this out?

@ has joined the channel

@nukepuppy has joined the channel

@ has joined the channel

here are our configs for using Terragrunt with Geodesic containers: https://github.com/cloudposse/root.cloudposse.co/blob/master/conf/terraform.tfvars

And a sample invocation: https://github.com/cloudposse/root.cloudposse.co/blob/master/conf/users/terraform.tfvars

Hi guys! Thanks @Erik Osterman for making this one. It’s been a while since I have used terragrunt for real in a big projects, so my knowledge may a bit broken now

@ has joined the channel

@ has joined the channel

@Raghu has joined the channel

@mallen has joined the channel

@Erik Osterman has joined the channel

@Erik Osterman set the channel purpose: Terragrunt discussions

@ has joined the channel

@antonbabenko has joined the channel

@loren has joined the channel

@aknysh has joined the channel

are any of you using extra_args for init and adding -no-color?

i’m using 0.17 and getting the -no-color arg duplicate with breaks auto-init

(if I run terragrunt init -no-color, it works)

@ndobbs has joined the channel

@catdevman has joined the channel

i used to do that for -no-color but moved away from it

what do you do now?

i decided i like the color on the cli, when invoked manually

oh, i like that

but i don’t want it for CI (atlantis)

for CI, i use terraform envs

ok

TF_CLI_ARGS?

or set the envs in a makefile instead

ok

either way

i tried the TF_CLI_ARGS and still got an error

TF_CLI_ARGS is broke… need to use the per command options TF_CLI_ARGS_apply

used make to work aroundn it for now