Written by Labesse Kevin

It’s been one year since I joined the DevOps team at AB Tasty, and one of the things that struck me the most when I arrived is the number of open source tools we use on a daily basis. Many tech companies would rather use private tools — that they pay for by the way.

But the price is not our main reason: open source projects benefit from a huge community of developers who work on regular improvements and ensure the maintainability of the code. Moreover, open source tools give their users the opportunity to make their own modifications rather than send a feature request to a limited team of developers and hope they will include it in their product roadmap.

That’s what happened with Terraform.

Why do we use Terraform?

Terraform is an open source tool for building, changing, and versioning infrastructure safely and efficiently. It stores the history of our modifications, allowing teams to know who made what, when and why — which is especially important if you have a substantial infrastructure.

Today, we handle over 50 projects on Terraform with 3 different cloud providers: AWS, GCP, and Azure. Thanks to Terraform, we are able to easily review each others’ code before implementing a new element. Moreover, each project is described on Terraform, which helps us replicate them in different environments (dev, staging, and prod).

Terraform is one of the standards for Infrastructure as code (IaC), one of the most flexible solutions out there benefitting from a huge community using and improving it. But if 99.9% of what we needed was already supported by Terraform, we still needed some changes in order to be able to fully use it.

Contributing to an open source project

One of the key ways we are using Terraform is to retrieve sensitive data, such as passwords and ssh keys from Amazon Secrets Manager. To be more precise, Terraform helps us generate unique access to our database for each developer: creating new credentials requires to connect to our database, and this is why we need ssh keys. The problem was: we needed to retrieve ssh keys stored in a binary format instead of the text format already managed by Terraform.

Another user had already raised the issue a few months earlier, but it had been left open.

I’m probably not the only developer who has ever wondered whether or not to embark on a pull request journey on an open source project. Will my request ever be reviewed? Or will it just stay buried in the pile of already submitted merge requests?

But the idea of making the project move forward for the good of the community convinced me to take the plunge. Plus, we really needed this functionality internally.

Making my first pull request

I started analyzing the code and what needed to be done. Like most serious open source projects, Terraform is well documented. I was able to dig in the code of similar projects in order to grasp their method and stay coherent.

I quickly identified what I needed to do: modify the data source “aws_secretsmanager_secret_version » and add a “secret_binary” key. I also adapted the associated resource to make it coherent with this modified data source.

Thanks to Terraform documentation, I was able to follow their format, prepare unit tests to analyze my modification, and document it. Overall, I took me less than half a day to have it ready to submit. I had no idea how long it would take to get it accepted, but at least we could start using it for our own needs.

The submission process actually happened way faster than I thought it would.

On the very day I submitted it, I received a comment from a maintainer of the project. I was amazed by the fact that he had already taken the time to review my modification, the test and the documentation attached. He pointed out the one improvement in order to validate the pull request: storing binary values on Terraform could corrupt the tfstate and make the stack unusable under certain circumstances. Following his suggestion, I used base64 as an intermediary format to store our ssh keys. My pull request was ready for submission!

The rest went smoothly, my pull request was approved in no more than 4 days — and released 2 days after.

From a simple user to a partner of the project

By contributing to this open source project, I realized that it was much simpler than I thought. I am proud I could do my bit, I feel like I became somehow a small partner of the project.

Since then, our team has worked on two other pull requests on Terraform:

• a modification to be able to retrieve certificates in Amazon Certificate Manager thanks to their tags: #6387
• a new resource to be able to create a garbage collection policy inside BigTable, allowing us to add a lifecycle rule for our data: #3293

and on other open source projects too.

And it’s not going to stop anytime soon!