#terragrunt (2020-12)

I use it with awscli and aws-vault

I could try to write a gist

That would be nice example to reference if you don’t mind

Thx Joe

@Mr.Devops here you go: https://gist.github.com/joe-niland/1b81ab5c8ebf7f8b5e4265af0b71f093

not sure if that’s what you’re after

I am just using the standard generate “provider” block from terragrunt docs

AWSOME thx Joe

atm i created an iam user using it’s access key/id whereas i’m calling the keys from ~/.aws/credentials file, but in my code i’m calling it via profile name

remote_state {
  backend = "s3"
  generate = {
    path      = "backend.tf"
    if_exists = "overwrite_terragrunt"
  }
  config = {
    bucket         = "non-production-xxx"
    key            = "${path_relative_to_include()}/terraform.tfstate"
    region         = "us-west-2"
    profile        = "non-prod"
    encrypt        = true
    dynamodb_table = "my-lock-table"
  }
}

i am planning to setup Atlantis with this as well

Nice! With Terragrunt, that looks like a good setup for assuming a particular profile for looking-up/updating the tfstate, but you’ll also need to assume a role using the provider block in your terraform code so that the resources you update are created using that same profile

yeah that’s the confusing part which i need help with. I never understand how to use assume roles with terraform/terragrunt

Another question which i do have is when using the remote_state backend within terragrunt.hcl. Does that need to be included into the source repo of terraform code? or just the root dir of my module?

e.g here’s my main module i will use for all env which in terragrunt.hcl it has a terraform block to call the source of my terraform module in github

Gotcha! There are likely better ways of doing this nowadays after the go aws-sdk fixed up some bugs a few months ago, but my setup that works both locally and on atlantis is:

Have a single .tf file that I inject into all modules with a generate block in the parent terragrunt files that contains:

provider "aws" {
  profile = var.profile
  region  = var.region

  assume_role {
    role_arn     = var.role_to_assume
    session_name = "terraform"
  }

  allowed_account_ids = var.allowed_account_ids
}

Then in a separate parent terragrunt file for each environment, I add an input:

role_to_assume      = get_env("DEV_IAM_ROLE", "arn:aws:iam::1234567890:role/Sandbox-Admin")

where identity is the aws-profile for the primary IAM user locally, and that role is the role that will give the local user permissions to do stuff in a given env.

Then on Atlantis, I add the envs from terraform like:

envs = {
    ...
    DEV_IAM_ROLE       = dependency.dev_role.outputs.external_role_arn
    STAGING_IAM_ROLE   = dependency.staging_role.outputs.external_role_arn
    PROD_IAM_ROLE      = dependency.prod_role.outputs.external_role_arn
    COMMONS_IAM_ROLE   = dependency.commons_role.outputs.external_role_arn
    ATLANTIS_IAM_ROLE  = dependency.atlantis_role.outputs.external_role_arn
    ...
  }

It works pretty well

tfstate stuff should only go in your parent terragrunt config, so long as you use a generate field definition inside the remote_state block of your parent terragrunt config file

this is great to see how others are using this. I now have a greater understanding. Atm my .hcl in the root/parent tree is using

remote_state {
  backend = "s3"
  generate = {
    path      = "backend.tf"
    if_exists = "overwrite_terragrunt"
  }
  config = {
    bucket         = "production-tfstate"
    key            = "${path_relative_to_include()}/terraform.tfstate"
    region         = "us-west-2"
    profile        = "non-prod"
    encrypt        = true
    dynamodb_table = "my-lock-table"
  }
}

i plan to use variables in the config

thx @David !

you are very welcome

Hi David me again. I ran into an issue

i’m following the file structure as

├── qa
│   ├── app
│   │   └── terragrunt.hcl
│   ├── mysql
│   │   └── terragrunt.hcl
│   └── vpc
│       └── terragrunt.hcl

and when i ran a plan or apply i get the error Did not find any Terraform files (*.tf) in .terragrunt-cache although there is many .tf files in my git module

Interesting, what directory are you running your terragrunt commands in?

It might be worthwhile to run a quick find . -type d -name ".terragrunt-cache" -prune -exec rm -rf {} \; from the root of your repo to clear out all the caches and make sure it isn’t just an issue with a corrupted cache

i’m running it in my app dir

after updating my source github url from [email protected]:PTATH81/terraform-aws-ec2.git//app?ref=v0.0.2 to [email protected]:PTATH81/terraform-aws-ec2.git the error went away but now i get

strange..

I can’t find much about that online unfortunately. What versions of terraform and terragrunt are you using?

Can you try clearing the cache and then running a TF_LOG=trace terragrunt init and seeing if the extra logs have any helpful hints?

terragrunt version v0.23.40

Terraform v0.14.2

let me clear cache

i also enabled TRACE for TF_LOG

here’s what i’m seeing

-----------------------------------------------------
2020/12/10 18:14:20 [DEBUG] [aws-sdk-go] {}
2020/12/10 18:14:20 [WARN] failed to fetch state md5: invalid md5
2020/12/10 18:14:20 [DEBUG] Service discovery for registry.terraform.io at <https://registry.terraform.io/.well-known/terraform.json>
2020/12/10 18:14:20 [TRACE] HTTP client GET request to <https://registry.terraform.io/.well-known/terraform.json>

Initializing provider plugins...
- Finding latest version of hashicorp/aws...
2020/12/10 18:14:20 [DEBUG] GET <https://registry.terraform.io/v1/providers/hashicorp/aws/versions>
2020/12/10 18:14:20 [TRACE] HTTP client GET request to <https://registry.terraform.io/v1/providers/hashicorp/aws/versions>
2020/12/10 18:14:20 [DEBUG] GET <https://registry.terraform.io/v1/providers/hashicorp/aws/3.20.0/download/windows/amd64>
2020/12/10 18:14:20 [TRACE] HTTP client GET request to <https://registry.terraform.io/v1/providers/hashicorp/aws/3.20.0/download/windows/amd64>
2020/12/10 18:14:20 [DEBUG] GET <https://releases.hashicorp.com/terraform-provider-aws/3.20.0/terraform-provider-aws_3.20.0_SHA256SUMS>
2020/12/10 18:14:20 [TRACE] HTTP client GET request to <https://releases.hashicorp.com/terraform-provider-aws/3.20.0/terraform-provider-aws_3.20.0_SHA256SUMS>
2020/12/10 18:14:20 [DEBUG] GET <https://releases.hashicorp.com/terraform-provider-aws/3.20.0/terraform-provider-aws_3.20.0_SHA256SUMS.sig>
2020/12/10 18:14:20 [TRACE] HTTP client GET request to <https://releases.hashicorp.com/terraform-provider-aws/3.20.0/terraform-provider-aws_3.20.0_SHA256SUMS.sig>
- Installing hashicorp/aws v3.20.0...
2020/12/10 18:14:20 [TRACE] providercache.Dir.InstallPackage: installing registry.terraform.io/hashicorp/aws v3.20.0 from <https://releases.hashicorp.com/terraform-provider-aws/3.20.0/terraform-provider-aws_3.20.0_windows_amd64.zip>
2020/12/10 18:14:20 [TRACE] HTTP client GET request to <https://releases.hashicorp.com/terraform-provider-aws/3.20.0/terraform-provider-aws_3.20.0_windows_amd64.zip>
2020/12/10 18:14:21 [DEBUG] Provider signed by 51852D87348FFC4C HashiCorp Security <[email protected]>

Error: Failed to install provider

Error while installing hashicorp/aws v3.20.0: open
.terraform\providers\registry.terraform.io\hashicorp\aws.20.0\windows_amd64\terraform-provider-aws_v3.20.0_x5.exe:
The system cannot find the path specified.

[terragrunt] 2020/12/10 18:14:21 Hit multiple errors:
exit status 1

terragrunt does not, technically, yet support tf 0.14, so you may be layering one problem on another…

ah

let me rollback the ver i have

thx @loren

what ver do you recommend ?

v0.13.5 ok?

if you check their github issues, they are tracking it. it’s just a bit too new still for them to claim support. the issues indicate some folks have gotten it to work, but with caveats. i haven’t tried yet myself, so am unsure of exactly what caveats

yeah, i use terragrunt with tf 0.13.5 regularly

and if nothing else, terragrunt 0.25.0 was the first to even support terraform 0.13.x.

FWIW, I use v0.25.4 with terraform 0.14.1 with no issues, and run it against ~600 modules

sweet you guys are awsome

i will let you know how it goes

i still ran into the issue, but did notice @loren comment on this from https://github.com/gruntwork-io/terragrunt/issues/581

(updating the env TERRAGRUNT_DOWNLOAD path which does do away with the error. But once removed again the error is the same. @David what system are you running terragrunt on? I’m on windows.

cutting down the dir structure helped for now.

oh you’re on windows. yes, it is just about mandatory to set TERRAGRUNT_DOWNLOAD. it’s not bullet proof but helps a lot

an even better option is to use WSL and avoid the path issue entirely

what system are you running terragrunt on? Locally, I’m on a mac, and our Atlantis runs on AmazonLinux2. My only windows experience is some testing on the https://github.com/transcend-io/terragrunt-atlantis-config library I maintain, but I’m not super experienced with it.

Unfortunately Yes windows as we use aws workspaces and I’m afraid it doesn’t support wsl

use session manager to connect to a linux dev box or try cloud9…

or use vs code with the remote ssh plugin…

thx for the tip @loren

hi Guys sorry to bother again. What is the preferred location to store your backend terragrunt.hcl file? Should i include that in the root dir of my terraform module (this is located in it’s own separate git repo)? Or should I include it in my environment module (this is also in it’s own separate git repo)?

by “backend terragrunt.hcl file” are you referring to the parent config file that the other child modules include?

yes the parent which the child module has when using

include {
  path = find_in_parent_folders()
}

hmm, I’m not sure on the best practice here. I use a monorepo for all my config, so I have the parent files at the root of the git repo. I would think that there would be some implications with Atlantis if you put the config file in a separate repo, which might complicate things

i see - at first i was too also using monorepo which works great, but i figured “what if” i try it this way….

i wonder if folks out there may have come across the path i’m looking towards here too

thx again @David and happy Monday!