-
-
Notifications
You must be signed in to change notification settings - Fork 966
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
Don't convert inputs to env vars. Instead, generate terragrunt.tfvars.json and use as -var-file #752
Comments
Oh yes ! This is definitely the way to go for input variables. Furthermore, as discussed #737 (comment) with @brikis98 we should also stick to Terraform, by defining variables explicitly. # In root terragrunt.hcl
terraform {
extra_arguments "terragrunt_generated_vars" {
commands = "${get_terraform_commands_that_need_vars()}"
required_inputs_files = [
"${get_terragrunt_dir()}/${find_in_parent_folders("common.hcl")}",
]
}
} # stage/frontend-app/terragrunt.hcl
terraform {
source = "..."
}
# Include all settings from the root terragrunt.hcl file
include {
path = "${find_in_parent_folders()}"
}
inputs = {
aws_region = get_input("aws_region")
remote_state_bucket = get_input("remote_state_bucket")
instance_type = "t2.micro"
instance_count = 10
} This will generate Inputs should follow Terraform variable merging behavior also.
required_inputs_files = [
"${get_terragrunt_dir()}/${find_in_parent_folders("common.hcl")}",
"${get_terragrunt_dir()}/${find_in_parent_folders("region.hcl")}",
] Any inputs found in |
I agree that Terraform's parsing of env vars is not ideal... But generating files on disk is always a bit messy:
|
@brikis98 I understand your point, but with all the benefit we can get, I think it worth that Terragrunt generates tfvars.json files.
Maybe in
Yes. For consistency and to mitigate secrets exposure. Even clean before every run.
Same as today. It'll follow Terraform variable precedence PS: Even Terraform Entreprise is using this for workspace variables. |
Let's make it
Not sure about this one. Why do we need to delete it? It will be regenerated on every terragrunt run.
Well, if somebody had secrets in
To keep the previous behaviour it needs to go as the last argument.
I think same as above? Variables from Hmm, I answered almost the same as @barryib :) |
Just another point: the JSON format is meant to be machine-generated, and it's a perfect use case for terragrunt.
|
This isn't a secret in the file. It's a secret read using a Terragrunt helper that would only exist in memory... Unless we start writing var files to disk. One other thought: As of Terraform 0.12, you can no longer set a variable in |
Not sure about secrets. The same rules apply to both |
I suspect that will be a serious problem for many users... So we'd be trading one mild problem (variables without a |
How about parsing the resulting terraform files and only setting variables that are defined there? |
What if we can define env vars and var files ? Something like: env_inputs = {
password = ${get_env("MY_SECRET_PASSWORD")}
}
inputs = {
instance = "t2.nano"
region = "eu-west-1"
}
I think that reuse of values will be difficult in Terraform 0.12, because they take the decision to move to explicite variable definition. This is neither good nor bad move, it's juste a direction they take. So should we follow them or not ? I'll say yes, because Terragrunt is a wrapper. It should add value/feature but it's not meant to change Terraform behavior. This could be confusing for users. Saying that, how can Terragrunt become explicit without loosing DRY concept ? I think inputs = {
aws_region = local.region
# or
aws_region = get_input("region")
} |
The upstream issue seems to be ignored by Terraform team, which is a blocker. |
@barryib I have not had time to dig into a solution yet. Hoping to have more thoughts to share in the next couple weeks. |
Since locals (or local) has been supported in Terragrunt, how do we reference the data source?
how do we reference Reference resource's attriabutes (output) will be harder, maybe add feature to reference data sources will be easier to be implemented? |
@ozbillwang I run into the same issue few days ago. Problem is that Terragrunt only allows terragrunt.hcl file in the directory where it is run. I tried leaving a .tf file with the data sources but it didn't work. Think this will never get implemented as, lookin at what we wanted to do, Terragrunt would have to copy those data source definitions on the side and run Terraform to get the outputs, since we wanted to instruct it to assign those outputs to it's In the end we went with a new module, with only data sources defined inside of it :( ugly as hell, since you need to still pass values to the module (e.g. for google_kms_secret data source - a key and a ciphertext), but I don't think there's a better way of doing this currently. |
I don't think we will ever implement a way to reference data or resources in terragrunt directly, as that requires implementing terraform directly within terragrunt, making it more than a wrapper. With that said, I am having a hard time understanding the use case, so could help if I had a concrete example with ideal |
You can almost do this today, with the new |
Of course you'll still run into the undeclared var problem, but you can use a .tfvars file instead of ENVs... ;) |
@yorinasub17 Sorry for neglecting to respond :( I was (and still am) opposed to putting data source definitions in modules. I think of them rather as something that provides input values to a module. Our usage was to provide a list of IPs to a firewall configuration in out Terraform module. The list of IPs was being fetched using the http data source. Putting the data source in the module felt more like hardcoding, which is what we went for in the end. Looking at the new generate block, I suppose this can be handled more or less the way I wanted it initially, but I haven't tested it yet. |
@yorinasub17 Seems like a valid idea! :) |
Relabeled as a feature enhancement that needs design. The main concerns around this are documented in the discussion on this PR: #1267 |
I'd like to link an issue that could be solved by generating .tfvars with inputs: #2132 |
I guess using Terragrunt config to store variables instead of .tfvars, then load it into the Terragrunt config in |
I've been reading documentation for terraform 0.12 in regards to handling env vars, and https://www.terraform.io/docs/configuration/variables.html states that:
and
And it's so error-prone and counter-intuitive! Just take a look at #740 and #738
Instead, terraform directly supports loading variables from json files: https://www.terraform.io/docs/configuration/variables.html#variable-definitions-tfvars-files
Terraform 0.11 supports it as well, although it's not properly documented:
The main point here is that types are not lost and terraform doesn't have to "guess" them. Also, the whole logic of converting inputs to env vars can be simplified to one
json.Marshal
.Benefits:
variable {}
blocksI can make a PR should it be needed.
The text was updated successfully, but these errors were encountered: