2 Features away to be the best Terraform Framework Ever

Terraspace
1

I’m opening this thread with the hope that the terraspace team understands how close they are to providing a perfect, simple, powerful framework for terraform.

If you could implement these 2 features there will be no look back for any infra engineer out there.

Here they are:

Global Resources

The first feature is to provide the ability to define global resources easily and intuitively.

Current:

At the moment when we need to define global resources such as route53 or networks (in gcp) the only weapon we have in our arsenal is to create “global” stacks and map them to a specific env ( TS_ENV=global) then, allow the stacks only when we run terraspace with that variable set.

The problem:

With the above approach, we have a few limitations that would make the feature not feasible to use.
For instance:

  • Since we are centralizing global stacks into a specific ENV we would be unable to re-use the output in other regions / envs, making it impossible to create regional sub-resources that depends on the global resource.

  • TS_ENV=dev terraspace all up would not work

  • We are forced to create a specific stack that will be considered “global” hiding implementation details

Proposal

To make this essential feature work properly I would suggest the following:

  • Allow a subfolder within a stack named global (conventional name) where it behaves like a normal stack, with the difference that will be automatically the parent dependency of the stack that is present in.

  • During terraspace build all the global folders in each stack will be processed and added top level, next to the regional folders

  • During terraspace all up the global folders will be always applied first, keeping the dependency graph as normal, for example a global resource might still be a dependency of another global resource.

  • We need to be able to reference the output of the global resource within the regional stacks something like: output('stackname.global.output_value') or output('global.stackname.output_value')

Use Cases

  • This would unlock amazing patterns such as creating a db instance hard-coding a specific region and referencing the IP in all other regions (removing the need to have multi-stack outputs).

  • It would allow us to easily manage the truly global resources and be intuitive.

Issue Ref: How to create "global" stacks - #2 by fenos

Nested Stacks

This is also a very high demanded feature from the community.

The Problem

Currently, the nested structure is not supported which forces us to bloat the top-level stacks folder making it very hard to reason about when the project grows

Proposal

We would like to be able to define nested stacks within a stack, and follow these rules:

  • Nested stacks will be automatically a dependency of the parent stack, (with the exception of the global folder mentioned above)

  • During terraspace all up the nested stacks would use the same remote terraform state file instead of creating a separate one

Use Cases

  • The biggest use case is to be able to de-clutter the stacks folder when the project is growing substantially, ultimately achieving a DRY and simple structure to follow.

Ref: Nested Stack Folders

Final Considerations

I believe that the global resources management is one of the most important features that is missing. Nowadays cloud providers are abstracting lots of infrastructures to be globally available.

In one way or another, we’ll always encounter these kinds of resources.

Thanks a lot for making terraspace, it is a super awesome framework.

2

RE: I’m opening this thread with the hope that the terraspace team understands how close they are to providing a perfect, simple, powerful framework for terraform.

Thanks for the kind words.

RE: 1. Global Resources

Yup. Would like to support global resources. Sounds like the idea to have folders like:

app/stacks/demo/global

Unsure about that. Think global resources are typically shared by multiple stacks. So it would result in something like this

app/stacks/demo1/global
app/stacks/demo2/global

Which doesn’t seem like the right fit. Glad to hear another idea though and maybe it’ll help lead an approach.

RE: 2. Nested Stacks

Yes. Would like to support this. Believe this might simply require a brute force approach to finding all areas in terraspace that makes the 1-depth level folder assumptions and tackle them. Will consider PRs.

RE: RE: 2. Nested Stacks Same State File

Unsure here. Gut says separate nested folders should have different state files. Believe the subfolders are mainly for organizational purposes. So for larger terraspace project app/stacks don’t end up with too many folders. Making up a possible example:

app/stacks/network/vpc
app/stacks/network/security_groups
app/stacks/shared/rds
app/stacks/shared/ecs
app/stacks/shared/eks

Believe app/stacks/shared/ecs and app/stacks/shared/eks should would be able to deploy independently and still have different terraform state files. Maybe:

terraspace up shared/ecs
terraspace up shared/eks

Dunno. Figuring it out. :face_with_monocle:

Cross link to GitHub Issue https://github.com/boltops-tools/terraspace/issues/257

Wish had some more direction but unsure on the approach currently. Maybe it’s one of those things were will need to let it simmer on the brain. :thinking: Think will continue discussion here until there’s something more concrete that can be implemented.