Hi,
Terrafom ( <= 0.14) automatically read variables from a “terraform.tfvars” file located at the project’s root directory, a feature which is quite useful.
I’d like to propose an extension to this feature: automatically pick a terraform-.tfvars file.
Variables in this file would override any values already defined in “terraform.tfvars”, so we’d have a simple override mechanism when using a single branch strategy to work with multiple target environments.
Terraform will already pickup any *.auto.tfvars as well as terraform.tfvars (plus the .json variants of both). Additionally you can read extra files via the -var-file command line option.
Hi, stuart-c,
Thanks for pointing the available options. My suggestion would just add (in my opinion) a more convenient way to deal with scenarios where you have multiple workspaces (e.g: w1,w2,w2), each with different settings.
Currently, the usual approach is something like that:
The issue here is the possibility that one picks the wrong var filein step 2, maybe with nasty results.
By having a workspace-specific terraform-.tfvars this kind of mistake could be reduced somehow.
Anyway, is just a small usability feature which only makes sense when using TF manually…
Hi @psevestre! Thanks for this suggestion.
Just to set expectations, the “workspaces” idea in Terraform CLI is essentially frozen because the concept is not fit for purpose for most use-cases. I would suggest adopting a different strategy such as those described in the documentation I linked to if you’re thinking of a use-case of multiple long-lived sets of infrastructure, as opposed to short-lived, throwaway development environments.
We do intend to redesign the workspaces mechanism eventually, including making it integrate better with Terraform Cloud, but since our current focus is on stabilizing the current behavior in preparation for a v1.0 later this year it’s unlikely that we’ll be able to make any meaningful improvements to the design of workspaces in the near future.
Hi @apparentlymart !
I have a little different opinions.
The doc has provided a great example, I use terraform to manage multiple deployments of the same infrastructure serving different development stages (e.g. staging vs. production).
My solution is like that:
.tf files that define the base infrastructure. It read the configurable field such as instance name, class from variables.{env}.tfvars file that contains the all of non-sensitive variables.secret.tfvars contains the sensitive variable such as api key, password. It’s ignored in git.secret.tfvars.template that managed by git, it will tell users which sensitive variables should be set.I just migrated to Terraform Cloud from local CLI version.
I push the code to a git repo, and make each environment (workspace) be a Terraform Cloud Workspace that work with this repo.
Then I set the sensitive variables in Terraform Cloud. But I won’t migrate each {env}.tfvars to Terraform Cloud. There are several reasons. First, it’s a little complex because there are so many variables. Then I want keep the history of these variables in VCS.
So, I think the best solution is providing an option to set which tfvars should be loaded in Terraform Cloud. Just like -var-file= argument in CLI.
Ps. I know I can make a separated branch for each environment, and rename the corresponding {env}.tfvars to {env}.auto.tfvars. But I still want the above feature, it make people easier to use and keep the repo be concise and maintainable.
A example of the structure:
- root
|- provider.tf
|- instance.tf
|- vpc.tf
|- ...
|- dev.tfvars
|- staging.tfvars
|- production.tfvars
|- secret.tfvars // ignored in git
`- secret.tfvars.template
The example of dev.tfvars:
region = "us-east-1"
instance_type = "t2.micro"
...