I have a massive terraform state I maintain for work. After learning about reusing resources using modules I adopted the same rule for terraform I have for other PLs “only call functions in the main func”. Meaning I’m only allowed to declare modules that reference resources at the top level.
My problem is that I have modules calling modules all over the place, the average length of any of my resources is 8 names. I have values I want to share across multiple different kinds of modules that do different things. Currently I have a top level module called “constants” with output blocks to store every constant I need. It works to an extent.
The thing is that I had a similar problem when web developing in React. Prop drilling is a coding style in React where a component receives a prop just for the purpose of passing the prop to a child component, the receiving component doesn’t actually need that prop for itself. React solves this by the context api which lets one component pass a value to any child component of any depth. How can we have something similar in Terraform? Even though every resource I have is defined once in code, it declares the same resources hundreds of times with different appropriate values.
I wish I could pass things like the dockerSecret to a kubernetes deployment 6 modules deep in such a way that that dependant component of a module waits for the docker secret to be created while other resources that don’t depend on it can be scheduled to be created later. Prop drilling doesn’t work all that well and it forces you to copy alot of code. Maybe modules aren’t the best way to reuse resources.
I feel like HCL doesn’t have syntax that would support such a thing idomatically. Maybe something like decorator syntax or a special type of block where you write a proper data, resource, or module block?
What do you guys think?
I like to think of Terraform like a deployment engine rather than a language on its own, even though it really wants to be.
With that kind of view, just generating the Terraform using a higher level language starts making sense, and that’s kind of what they’re going for with CDKTK except the AWS CDK in itself kinda smells. But it’s a valid route, it supports JSON as config files for a reason: machine to machine.
Just generate a bunch of objects in the language of your choice and serialize it to JSON and voilà!