)
)
If you are new here, or just finding us, Terramate is a tool created to augment the functionality of Terraform to add code generation, stacks, orchestration, change detection, data sharing, and more. If you use Terraform, then most likely you’ve run into some issues that Terraform doesn’t handle natively very well, or at all.
What’s the problem?
In our last blog, we broke down one of the most common problems, by talking about why you should break up your code into more manageable stacks. While there are native ways to solve this problem, they can come along with their own issues, such as code duplication. One key area where this problem shows up is in the terraform provider and backend configuration. These are usually hard-coded into the Terraform files. When working with multiple stacks, this can be tricky to manage at scale when it comes time to update or change that configuration.
Luckily, we have a solution for you. With Terramate Code Generation you can abstract this into configuration files so that for each stack in your Terramate project, those files will be automatically generated for you.
Why use Terramate Code Generation?
It is pretty easy to see why using Terramate Code Generation is helpful in general. It saves you a lot of time from having to write your Terraform HCL by hand. But why use it for the specific purpose of managing and updating provider and backend configurations? The simple answer is DRY. Don’t Repeat Yourself. This process allows you to have less code to manage, which saves you time. You can use the Terramate Globals to programmatically adjust the value on different levels in the hierarchy. This means that when you update the Terraform version at the root of the project, all the stacks below will be automatically updated.
How to do it
So, how do we do this? First off, let’s make it easy and start with an example repository. Nothing is better than some files to clone, break, and play with, right?
If we first look at the /imports folder, we can find the files that help us generate the _terramate_generated_backend.tf and _terramate_generated_provider.tf files.
These files are generated with the terramate generate command, which is why we prefix them with terramate_generate_* . These files shouldn’t be touched by the user. Note: Terramate also has a terramate fmt command, which formats all *.tm.hcl files recursively in a project.
Those files work together with the config.tm.hcl file that is in the root of the repository, which has all of the global configurations. Globals can always be extended, inherited, or overwritten. For more info on globals, check out this documentation.
When you run terramate generate , it uses the files in the imports folder to then dynamically create the backend and provider configuration files for all of the stacks. Another benefit is that when you use terramate create to create new stacks with this setup, it will use these files to automatically generate the backend and provider configuration files in the new stack. Cool, right?
Conclusion
As you can see, using Terraform Code Generation is a fairly simple and straightforward process that has a lot of benefits. First, and foremost, it saves you a lot of time by keeping your backend and provider configuration as DRY as possible. From updating your existing stacks, to creating new ones, all you have to do is update a single file at the root of the repo, and it’s done. For more information on Terramate, feel free to check out the website.
Also, if you seek help with this example or if you want to talk all things Terraform and Terramate, join us on our community Discord.