Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Interpolation: Add split function #240

Closed
conorgil opened this issue Jun 21, 2017 · 3 comments
Closed

Interpolation: Add split function #240

conorgil opened this issue Jun 21, 2017 · 3 comments
Labels
enhancement New feature or request

Comments

@conorgil
Copy link
Contributor

Proposal
I think that it would be really useful if Terragrunt supported an interpolation function called split(). It would be very similar to Terraform's split() and may work something like this:

split(string, delimiter, index): Splits the input string along the delimiter
                                 character into a list of substrings and returns the
                                 substring at the requested index.

The reason to accept an index in this function is to prevent the need for Terragrunt to support the list type in interpolations (correct that Terragrunt does not support the list type in interpolations, right?). If list type was supported, then you could remove the index param and just do split("a/b/c", "/")[0].

You'd need appropriate escaping on the delimiter character, error handling, etc, etc.

Motivation
I am currently working on an example for #169 which demonstrates how to setup your directory hierarchy when trying to work with a single account and multiple regions. I am trying to figure out the best way to keep the configuration DRY in terms of passing the correct region to the Terraform modules. I see that there is a lot of discussion in #132 and #147 about this same question, but I could not see an approach that works yet (please share if I just missed it).

One idea I had to solve the same issue was to rely on the convention of my directory hierarchy to pull the name of the correct region. For example, the directory hierarchy might look like:

live
├── terraform.tfvars
├── eu-west-1
│   └── prod
│       ├── frontend-app
│       │   └── terraform.tfvars
│       ├── mysql
│       │   └── terraform.tfvars
│       └── vpc
│           └── terraform.tfvars
└── us-east-1
    └── prod
        ├── frontend-app
        │   └── terraform.tfvars
        ├── mysql
        │   └── terraform.tfvars
        └── vpc
            └── terraform.tfvars

and then the top level terraform.tfvars file could look like:

terragrunt = {
  remote_state {
    backend = "s3"
    config {
      bucket = "my-bucket"
      key = "${path_relative_to_include()}/terraform.tfstate"
      region = "${split(path_relative_to_include(), "/", 0)}"
      lock_table = "my-lock-table"
    }
  }
}

The interpolations would resolve to:

path_relative_to_include()                # us-east-1/prod/vpc
split(path_relative_to_include(), "/", 0) # us-east-1
split(path_relative_to_include(), "/", 1) # prod
split(path_relative_to_include(), "/", 2) # vpc

A similar approach could be used to also pull the correct account ID from the directory hierarchy when working with multiple AWS accounts.

Thoughts?

@brikis98
Copy link
Member

This is a clever idea. The key question is whether this would still be useful if we implemented something like read_var_from_file? Chances are, you'll have to define the region to deploy into in your .tfvars file anyway (e.g. to pass to the AWS provider), so it would make sense to reuse that value explicitly.

@brikis98 brikis98 added the enhancement New feature or request label Jun 21, 2017
@conorgil
Copy link
Contributor Author

Fair point about needing to define the region in the *.tfvars file anyways so that Terraform can use it in the AWS provider.

@brikis98
Copy link
Member

As of v0.19.4, Terragrunt now supports ALL built-in Terraform functions, including split.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants