#terragrunt (2020-03)

hi, I’ve banging my head against terragrunt to get an environment up and running, with some common variables (eg environment = “staging”)

in a resource I refer to this variable as

var.common_vars["environment"]

, and it works ok until…

until I try using it in the resource name definition like:

resource "aws_vpc" "vpc_"var.common_vars["environment"] {

now tell me that variables are not allowed in resource name definitions, so that I’m doomed…

the purpose here, is to get

resource "aws_vpc" "vpc_staging" {

if you have any tips please give me a shout, thanks

I dont use environment specific resource names, especially as I want my code to be the same for all environnements. Instead I use those environment specific values inside resource definitions, e.g for vpc names etc.

Mmm ok - I suppose I’ll have to change my strategy as I move from tf files to tf modules (with terragrunt in the mix), removing the env. from the resource names… hopefully I won’t find anymore “surprises”

Thanks @wattiez.morgan for the input

Has anyone regularly used --terragrunt-include-dir? I am struggling to get it to work, but my expectations may be incorrect

Exclude worked for me as expected

terragrunt-info has this for the working dir:

  "WorkingDir": "<redacted>/terraform-infra-live/internal-devops"

$ pwd
<redacted as above>/terraform-infra-live/internal-devops
$ ls -l 
total 16
-rw-r--r--  1 user  staff   744 Jan 30 23:57 README.md
-rw-r--r--  1 user  staff  2570 Mar  5 11:22 terragrunt.hcl
drwxr-xr-x  6 user  staff   192 Mar  5 11:22 us-east-1
$ ls -l us-east-1/
total 8
drwxr-xr-x  7 user  staff  224 Mar  5 11:22 cloud
drwxr-xr-x  7 user  staff  224 Mar  5 11:22 dev
-rw-r--r--  1 user  staff  860 Mar  5 11:22 region.yaml

When I attempt to run

terragrunt plan-all --terragrunt-exclude-dir "us-east-1/cloud/**"

Everything in cloud is still excluded.

We’re following the Terragrunt example repos model pretty closely

Does anyone know if I can use a module output in the terragrunt hcl file, right I’ve got

remote_state {
  backend = "s3"

  config = {
    bucket         = "${local.prefix}-state"
    dynamodb_table = "${local.prefix}-locks"
    key            = "terraform.tfstate"
    region         = local.region
    encrypt        = true
  }
}

is it possible to pass in module.something.something instead?

i just tried and it said it wasnt expecting module here

You can, but terragrunt handles this slightly differently than terraform would.

Check out https://terragrunt.gruntwork.io/docs/features/execute-terraform-commands-on-multiple-modules-at-once/#passing-outputs-between-modules and let me know if you still have any questions

Hi all, how does Terragrunt call into modules with multiple providers? I’m going with the approach of keeping the code DRY and keeping only terragrunt.hcl files in my directories, which is partitioned by environment and component.

For example, AWS VPC peering is a common component that requires 2 providers as there’s both a requester and a provider. In regular Terraform, I’d do something like

module "vpc_peering" {
  source = "../path/vpc-peer"
  ... (arguments)

  providers = {
    aws.requester = aws.default
    aws.accepter = aws.peer
  }
}

However, if I’m using a root level terragrunt.hcl and then a directory level terragrunt.hcl that includes the root level one and has terraform and input blocks, I’d have something like:

# root level terragrunt.hcl
remote_state {
  backend "s3"
  (some config)
}

generate "provider" {
  (provider config for both aws.default and aws.peer)
}

# directory level terragrunt.hcl
terraform {
  source = "../path/vpc-peer"
}

include {
  path = find_in_parent_folders()
}

inputs = {
  (arguments)
}

How would one pass multiple providers to the module?

you just set the alias name in your provider config and it just works

are you running into an actual error, or just asking for confirmation that this should work?

i’m running into an error because i was hoping i’d be able to rename the provider alias, such as how in standard terraform you can do aws.requester = aws.default. so you’re saying if i’m to use Terragrunt, then the provider would have to have an alias of requester already, instead of default? the reason why i wanted to keep the name default is because i have other modules that use the same provider

How have people managed terragrunt commands taking a really long time to run? Some of my plans take >10 minutes because the module dependency tree gets really large, where the module may depend on 10 other modules each of which has a few dependencies of their own.

As an example, running terragrunt plan > test.out 2>&1 on one of my modules, then cat test.out | grep 'output -json' | wc -l tells me that it runs terraform output -json on 53 modules before actually doing the final terraform plan. Some of these modules are quite a ways down the chain and I feel like should not be necessary to lookup the state of. In fact, I’m not sure I understand why anything other than top level dependencies have their state looked up (though I very well may be missing something).

I’ve cached all my providers so that is not an issue

Adding @discourse_forum bot

@discourse_forum has joined the channel

I just wrote and released https://github.com/transcend-io/terragrunt-atlantis-config if anyone is interested. It generates atlantis.yaml content for terragrunt repos by analyzing the dependency blocks (and some other stuff)

Hopefully someone else finds it useful, I’ll gladly take feature requests