We’re experimenting with TFC and have encountered a couple counterintuitive things that make me wonder if we’re using it right. I’ve searched around for clarification, but hoping someone can shed some light on it for me.
The biggest issue is the way variables are maintained in the UI with no means of grouping or even alphabetical ordering. Is the idea that we should create a separate workspace for any resource that will use variables and just be super rigorous about what order we enter them into the UI?
Otherwise, this just seems to become a giant unmanageable pile of variables. It also seems counterintuitive that this set of variables becomes totally untethered to VCS. At this point, we’ve just gone to using *.auto.tfvars files instead. Is that what most people do? I suspect I misunderstand how variables are meant to be used, and it would be great if someone could point me to some elucidating materials.
Also worth noting that on the variables UI page, under the Terraform Variables section, it states:
These [Terraform variables] are set using a terraform.tfvars file. To use interpolation or set a non-string value for a variable, click its HCL checkbox.
But, that isn’t actually the case using Terraform Cloud. I realize that there are more explicit statements in the documentation that we were able to figure out, but it might be helpful to clarify that statement. For those of us used to actually using terraform.tfvars to manage variables, it’s pretty confusing at first blush.
Finally, I’m getting some pushback from my team about being able to run plans, but not applies, from their shell for VCS connected workspaces. Can someone help me understand what the rationale is for that?
Thanks very much for any feedback!
There is indeed no way to order the variables in the Variables UI at this time; a good thing to bring up though, I’ll enter it in as feedback!
Otherwise, this just seems to become a giant unmanageable pile of variables. It also seems counterintuitive that this set of variables becomes totally untethered to VCS.
Not necessarily - for many things such as credentials, you’d likely want to be separated from VCS, just as environment variables. But if you’re looking for more rigorous control, ordering, and VCS goodness, I’d direct you to the following two options:
These [Terraform variables] are set using a terraform.tfvars file…But, that isn’t actually the case using Terraform Cloud.
It is - this text is stating that the variables are literally being injected in to the Terraform process by Terraform Cloud through the use of a terraform.tfvars file created from your entered variables. I agree though, that’s more of an implementation detail than actually useful as a user, and I think that can be clarified better!
Finally, I’m getting some pushback from my team about being able to run plans , but not applies , from their shell for VCS connected workspaces. Can someone help me understand what the rationale is for that?
Yes - using VCS connected workspaces, users may run speculative plans on the CLI; it’s intended to be a way to try our to test changes to a configuration during editing, etc.
An apply operation is not allowed on VCS-connected workspaces because it defeats the purpose - with workspaces connected to VCS, webhooks are registered and it’s Terraform Cloud’s job to keep in sync with that VCS. The configuration always comes from VCS, and always from a specific commit. If you want to run applies from your local machine, what you’re really asking for is to also manage where the configuration you’re wanting to apply is coming from (VCS? Local file system? Wherever you want.) And if you want that, that’s what the Local execution mode on a workspace is for (Terraform Cloud is used as your state storage and not for the actual plan/apply operations - those you do on your local machine).
Hope this helps!
Def having some of the same questions here. Decoupling vars from VCS seems like it skirts our usual change control process (PR reviews).
I agree for secrets its preferable to set them in the workspace, but still wondering how the normal PR process could be better integrated for normal var changes.
I’ve thought about the *.auto.tfvars a bit and wondering if there’s a way to separate by workspace. In our current workflow we might have one configuration repo for multiple envs (e.g. dev/prod) and the only difference are variable values specific to that env. The intent being to keep things as similar as possible.
With *.auto.tfvars though it seems like its not possible to apply say dev.auto.tfvars in the dev workspace and prod.auto.tfvars in the prod workspace.
Is that correct?
