Skip to content

4 tips to manage multiple Terraform versions

How to manage multiple Terraform versions? Holding office hours and ask me anything sessions, we got to hear a lot of questions around how to keep clean Terraform environments. Here are a few very basic tips for keeping it clean and organized.

Manage multiple Terraform versions

How to manage multiple Terraform versions locally and keep track of all environments?

This article is an transcript from a video interview series : Ask Me Anything on Infrastructure as Code with the Author of “Infrastructure as Code – Cook book”

Why you may need to manage multiple Terraform versions

There are a lot of reasons why you may need to use multiple versions of Terraform locally, like having different environments (structured deployments) with separate versions : working of several projects for different customers, ensuring backward compatibility of your code by running it with several versions, etc…  

To manage multiple Terraform versions, you can start by using locally an environment / Terraform version manager

Using a version manager makes it way less painful to deal with multiple Terraform versions locally, and will make sure that:

  • switching between projects is quick,
  • the development environment is the closest possible to production.

tfenv is a good one, inspired by rbenv. Basically, tfenv will allow you to install a specific version of Terraform and switch to it by default. It will also enable you to list and keep track of all Terraform versions installed on your laptop. Plus it has a few convenient commands, such as tfenv install min-required that will recursively go through your terraform files to determine the minimally required version.

Explicitly set your Terraform versions

When they happen, Terraform upgrades can hurt. They hurt even more when you have some random exception that you don’t understand, and discover that they are happening because you are running the wrong Terraform version on that specific machine.

By explicitly setting the required Terraform version, you will get a clean, explicit error if you try to run an apply with the wrong environment.

terraform {
required_version = "0.12.10"
} 
Manage multiple Terraform versions

Set module versions as well

Moving parts are one of the programer’s worst enemies, and that applies to infrastructure code too. Terraform modules bring a lot of reusability and composability, but they can also become messy to handle.

Setting module versions makes it easier to control when what part of your infrastructure will change if there is a module upgrade. You get a guarantee that for a given commit in your codebase, you always deploy the same thing.

module “blabla” {
source = “module_name”
version = “1.2.3”
} 

It also enables to progressively roll out module upgrades: you can have the old version in production, create a dev branch where you upgrade the module, test in your dev environment, then merge on master if it passes testing.

The more modules you use, the more likely it is than one of them causes an issue at some point — so this becomes more and more critical as your codebase grows.

Don't forget your workflow : prevent local apply / deter commits on master

Running apply locally can be dangerous as soon as two users collaborate on the same Terraform file: if two updates happen shortly one after the user, the first one may be overridden by the second one. Besides, you never know what can happen on your laptop, and we’ve heard stories of big state files getting messed up by a lost WiFi connection.

This is why a more production-ready workflow encourages running apply only from a central, versioned system such as through a CI/CD.

The next step though, is to build that behavior into the process. For example, a user’s access rights will not enable them to make changes directly in production. Rather, only the CI/CD keys will have the rights to do that.

Similarly, it is very tempting to merge to master, even though we know it’s not a best practice. Locking master will encourage users to go through the better, safer, pull-request then review process. Unless you are superhuman, and always read the Terraform plan and never make a mistake.

Some teams add additional steps there, such as linting or checking for docs updates that are a small investment in keeping the code clean in the long run.

Key metrics for infrastructure automation

Check your progress in your infrastructure automation journey with metrics that matter.

Maintain reliability and security while moving at developers speed.

Track inconsistencies that were invisible so far.