RE: I think my message may have come across more panic toned which caused confusion.
Naw, didn’t interpret a panic tone. We’re all just figuring things out. On the flip-side, hopefully, I didn’t come off too strongly worded. The internet has its ways of not relaying the tone of messages properly, sometimes Terraspace can be a fit, and sometimes it may not be. That’s ok. Am uncertain here if it’s a fit. Think Terraspace can definitely help here, but is not a cure-all.
RE: Local Laptop vs Remote TFC
Wondering which TFC workflow you’re using:
- The CLI-driven Workflow
- The VCS-driven Workflow
Unsure which workflow is being used. If it’s the CLI-drven workflow, then think
gcloud auth application-default login should work. At least, in the test above was using it. It’s on the “Click to See Output of terraspace up”. It’s the VCS-workflow where the remote machine won’t have the
terraform apply won’t work.
RE: The problem we are facing right now, is how do we replace our tfc-workspaces project and its scaffolding of other workspaces to set the, for example, GOOGLE_CREDENTIALS envvar on the workspace?
It’s quite interesting and novel how you guys are approaching this. So it sounds like the
tfc-workspaces is a “master” terraform project that is:
- responsible for generating google credentials as well as
- scaffolding the other terraform projects.
If am understanding this right, at a high-level, you’ll probably be better off keeping some form of “master” or “orchestration” script to tie things together.
Interestingly, since Terraspace actually has access to a full programming language, Ruby, at your fingertips, you could tap into it and have terraspace to take over the full master script, but it’ll likely grow complex and get messy. So probably wouldn’t take that approach.
Would probably organize things into separate terraspace projects for each team and have each team responsible for that. There will be some shared projects and teams, and there are trade-offs. Here are also some thoughts on this: Customized layering support?
RE: I’m wondering if we had a credentials workspace, that has a sensitive output called google_credentials, if we can pass that into the new stack’s Google provider’s credentials config via remote terraform_remote_state data source. Just a random thought while typing this out… I don’t know if it is viable, or if you might have a better idea of how to go about this.
Here’s where am wondering if you are using the CLI-driven workflow or VCS-driven workflow. Sounds like you are maybe also using VCS-driven for some things and the CLI-driven for other things. In this case, the
terraform_remote_state may work. I usually don’t use
terraform_remote_state because it feels like it couples things too much. But can’t think of anything better at the moment.
RE: Side note: Would be nice if TFC offered Organization-level Env Vars that are injected to every workspace.
Yes, that would definitely be nice. Got some longer-term goals for this, but it’s a few months out, so it won’t be of immediate help to you.
RE: Since the provider is defined in config/terraform/provider.tf, we can’t have individual providers defined down in the actual stack; which makes the above not work.
The devil-is-in-the-details. Also, those docs probably need to be more clear. https://terraspace.cloud/docs/misc/multiple-providers/ The docs are talking about different cloud providers like AWS and Google with the same code, it’s possible with Terraspace it just feels a little too messy. Going multiple regions with the same cloud is straightforward and clean already.
RE: What would work is having multiple Terraspace projects for each region, and then a Terraspace project for the global pieces that need each region in place. Then for DR we just bring up things in chunks: us-central1, us-west1, global
Think you’re close to nailing it. Though, think it’s more accurate to say you need to “call” terraspace multiple times, instead of having multiple projects. Something like:
TS_ENV=global terraspace all up
TS_ENV=dev GOOGLE_REGION=us-central1 terraspace all up
TS_ENV=dev GOOGLE_REGION=us-west1 terraspace all up
Same code. Different permutation handled by different invocations of
terraspace all up. Hence, this is where would consider a “master” orchestration script. Leverage Terraspace for higher-level preassembled infrastructure. But still have an even-higher level orchestration to handle these more specific workflows.
This somewhat reminds me of Handling multiple providers/accounts/roles/regions Taking terraspace out of the picture for a moment and focusing only on terraform itself. This person would like to invoke
terraform apply only once and have it switch to 5 different AWS_PROFILES in one-go. Terraform itself won’t be able to do that in one-go. A master orchestration/wrapper script is probably a better approach.