This is the final post of an ongoing series of posts documenting the built-in interpolation functions in Terraform. For more information, check out the beginning post. In this post I would like to take a moment to review the project as a whole, mung together some semi-coherent thoughts about the functions, and maybe even make a plan for the future.
In June of this year, I undertook a project to examine each built-in interpolation function within Terraform. My plan was to examine a function each day - weekends excluded - and document how the function works, why it might be useful, and any interesting tidbits I discovered along the way. There were a few drivers behind the project:
I’d like to say that I had thought this whole process through and started my first post with the whole series and format laid out. I’d like to say that, but it wouldn’t be the truth. The first few posts had me working through the format of the post and the way in which I wanted to create examples. It also took me a few iterations to figure out how I wanted to structure the GitHub repo, and how to effectively create new examples with minimum effort. After the first few posts I got into a groove. I also realized that this was going to be a significant undertaking in terms of time. When I started the posts, there were about 63 functions, and now there are 65. Working at five functions a week, the whole thing should have taken about 13 weeks to complete. That’s three months of posting, five days a week. Considering I started in June and finished in September, three months was exactly right. It wasn’t till the end of the first week that I realized that I had made a three month commitment, and once I did realize that, I started to look for ways to make the process sustainable. Using a basic template for posting and examples helped a lot. I also didn’t get too ambitious with the number of examples for each function. I wouldn’t say that the process was easy, and I don’t know if I would do it again. But I will say that I learned a lot about Terraform and blogging.
If I could start the whole project over again, I would have grouped the functions by what they do, and not alphabetically. It makes sense to put all the functions dealing with strings together, and same with lists and maps. Then there are the functions that take no arguments. Basically, if you are looking for a function to assist with string manipulation, then it would be much more helpful if all of those types of functions were grouped together. So here’s my attempt at doing exactly that:
While writing all of these posts, I did discover some things I would like to see changed and improved. For instance, the documentation page for the built-in functions is listed alphabetically for the most part. But there are a few examples of it not being entirely alphabetical. That’s a minor thing to most. As the son of a librarian, that’s the type of thing that really gets stuck in my craw. More importantly, I think the functions should be grouped by loose affiliation; the way I just listed them out. There were also a few functions that I thought were either missing functionality, or could be improved in some way. I don’t want to be the person just complaining about things, I want to be part of the solution as well. The whole project is open source, including the docs. The website is written in markdown, and I can easily update the page with the built-in functions and submit a pull request. In fact, I plan to do that. The functions are written in Golang, and that makes things a little trickier since I am not a developer by trade. To that end, I have started learning Golang in order to assist with improving the functions. My first attempt was adding a function called dateadd that would add the ability to manipulate dates in the same way that timeadd deals with time. After submitting my pull request, I had some good conversations with one of the maintainers about whether that should be a separate function or added to the timeadd function. We agreed on adding it to the timeadd function and I am working on learning enough Go to make that a reality.
Terraform v0.12 will be dropping in the near future. It is going to bring with it a lot of enhancements to the Hashicorp Configuration Language, and the way that Terraform functions overall. There will be breaking changes, but it will all be in the name of creating a better product. Terraform is becoming more widely adopted by the moment, and it’s probably best to make the necessary changes now before this juggernaut picks up any more steam. I’m sure once the new version drops I will need to revise my courses on Pluralsight and maybe review some new functions here. I’m excited for the future and what it might bring!
Resourcely Guardrails and Blueprints
November 15, 2024
Deploying Azure Landing Zones with Terraform
November 12, 2024
October 18, 2024
What's New in the AzureRM Provider Version 4?
August 27, 2024
