Terraform 2020: Taking a Look Back at Updates
By: Raphael Socher
Tags: Hashicorp, Devops Training, DevOps, Terraform, Infrastructure As Code

While 2020 has been focused on the world-wide pandemic, DevOps has continued to grow and change, despite difficult circumstances. New releases for Terraform, released by Hashicorp, could impact the way that you work in the future. In this article, we’ll dive into Versions 0.13 and 0.14, and what could come next in 2021.

Did we skip an update? Do you want to discuss a specific part of this article further? Join us on Slack to meet both Terraform experts and learners, and continue learning.​

For reference, the latest version of Terraform v0.14.0 was released on December 2nd, and we’ll take a look at all of the major changes related to that version. But first, let’s go back a bit, and go through the major updates from Version 0.13.0, and why they matter.

Terraform v0.13.0: Terraform Module Changes

Version 0.13.0 was released on August 10, 2020, and introduced impactful changes. The most significant changes that were offered are as follows:

count and for_each : One of the major concerns until this version was released, was that we would have to write multiple Terraform module blocks if multiple instances of the same block were required. “Count” and “for_each” were restricted to data blocks and resource blocks. However, with fewer restrictions on “count” and “for_each,” we can now create multiple instances with just one module block.

: One of the major concerns until this version was released, was that we would have to write multiple Terraform module blocks if multiple instances of the same block were required. “Count” and “for_each” were restricted to data blocks and resource blocks. However, with fewer restrictions on “count” and “for_each,” we can now create multiple instances with just one module block. Terraform module dependency : Another important update in this version was the introduction of “depends_on” for modules. This means that we can define the dependency of one module on another. When we say that a module “A” is dependent on another module “B,” then we ensure that all the changes to the module resources of “A” are applied only after the resources of “B” are deployed. Find out more about the usage by reading our blog on Terraform templates.​

: Another important update in this version was the introduction of “depends_on” for modules. This means that we can define the dependency of one module on another. When we say that a module “A” is dependent on another module “B,” then we ensure that all the changes to the module resources of “A” are applied only after the resources of “B” are deployed. Find out more about the usage by reading our blog on Terraform templates.​ Installation of Providers : Automatic installation of your providers was enabled. If your provider is part of the main public registry of the Hashicorp namespace, then the provider does not need the “source” argument to be defined in the “required_providers” block. If not then, the “source” field will have to be defined with the source address under the “required_providers” block.

: Automatic installation of your providers was enabled. If your provider is part of the main public registry of the Hashicorp namespace, then the provider does not need the “source” argument to be defined in the “required_providers” block. If not then, the “source” field will have to be defined with the source address under the “required_providers” block. Custom Validation : Remember we talked about the custom validation for input variables in our blog on Terraform variables? The custom validation was included in this version and has been beneficial for everyone.

: Remember we talked about the custom validation for input variables in our blog on Terraform variables? The custom validation was included in this version and has been beneficial for everyone. One required_providers block per module : Previously multiple “required_providers” blocks were allowed in every module. But, this was removed and the restriction of only one “required_providers” per module was introduced. This is to ensure that you don’t confuse the resources of various providers in your definition.

: Previously multiple “required_providers” blocks were allowed in every module. But, this was removed and the restriction of only one “required_providers” per module was introduced. This is to ensure that you don’t confuse the resources of various providers in your definition. Provider installation on HTTP server : Until Version 0.13.2, you could mirror the provider into your local file system. In this version, you can get the copies of the provider on an HTTP server and then use this server as a source for your providers. This became an impactful change in scenarios when directly accessing the source was not possible.

: Until Version 0.13.2, you could mirror the provider into your local file system. In this version, you can get the copies of the provider on an HTTP server and then use this server as a source for your providers. This became an impactful change in scenarios when directly accessing the source was not possible. Deprecation of built-in provisioners: Few of the provisioners were removed in the later versions and the deprecation warnings for built-in provisioners such as Chef, Habitat, Puppet, and Salt-masterless started from Version 0.13.4. The reason stated in discussions was that this decision was due to “uncertainty and complexity these provisioners added by introducing actions that cannot yet be modeled by Terraform.”

Terraform v0.14.0: A Focus on the Terraform State File

Terraform Version 0.14.0 is the most recent version released by Hashicorp. Just like v0.13.0, this version also includes major updates. Although the major updates are very few due to the frequent releases, they are of significance nonetheless.

Sensitive Information : When it comes to security and privacy, we believe this is a very important update that Hashicorp is providing. You can now mark your input variables and module outputs as sensitive and those values will be redacted from the console. This ensures protection to your sensitive information that may be used for logging in or token information. We hope that in the future, encryption is added to these Terraform variables. However, note that this information continues to remain in plain text in the Terraform state file.

: When it comes to security and privacy, we believe this is a very important update that Hashicorp is providing. You can now mark your input variables and module outputs as sensitive and those values will be redacted from the console. This ensures protection to your sensitive information that may be used for logging in or token information. We hope that in the future, encryption is added to these Terraform variables. However, note that this information continues to remain in plain text in the Terraform state file. Lock file when you initialize a working directory : Do you have multiple members of your team working on your infrastructure? The version of the provider keeps changing with each person initializing the working directory, which can be a huge issue for any organization and its team of infrastructure engineers. In order to help resolve this issue, Hashicorp introduced the concept of a lock file that gets created automatically when you use the “init” command. The lock file creates a dependency on the current version of the provider that has been used and when you maintain this file on any of the version control systems, it ensures that the same version of the provider remains throughout. If you wish to upgrade the version of your provider, then use the “init -upgrade” option.

: Do you have multiple members of your team working on your infrastructure? The version of the provider keeps changing with each person initializing the working directory, which can be a huge issue for any organization and its team of infrastructure engineers. In order to help resolve this issue, Hashicorp introduced the concept of a lock file that gets created automatically when you use the “init” command. The lock file creates a dependency on the current version of the provider that has been used and when you maintain this file on any of the version control systems, it ensures that the same version of the provider remains throughout. If you wish to upgrade the version of your provider, then use the “init -upgrade” option. Reading and writing of Terraform state file : Reading and writing compatible Terraform state files are now supported. This means that you can share your Terraform state file, even with the future version releases of Terraform, without having to worry about it causing any breakdown in your infrastructure. Note that this is applicable only if there is no version change in the Terraform state file.

: Reading and writing compatible Terraform state files are now supported. This means that you can share your Terraform state file, even with the future version releases of Terraform, without having to worry about it causing any breakdown in your infrastructure. Note that this is applicable only if there is no version change in the Terraform state file. Versioning of Providers : Defining the version of the provider in the provider block will generate a deprecation warning. To avoid this, define the version argument in the “required_providers” block.

: Defining the version of the provider in the provider block will generate a deprecation warning. To avoid this, define the version argument in the “required_providers” block. Removal of “debug” command: The “debug” command has now been removed as it could not offer any further functionality.

Terraform 2021: What to expect?

It’s clear to anyone in DevOps that Hashicorp is really putting in the effort to make the overall experience better with each release. While there’s a lot to work on and improve, it’s a fact that Terraform is now a leading tool for Infrastructure as Code.

Of course, we can’t predict the future, but we can make an educated guess about what will be included in the next versions:

Sensitive Values : In the new version, as we have discussed, the sensitive flag can now be set even for input variables and modules. But, the fact that it’s still available as plain text in the Terraform state file is a concern that we hope can be resolved.

: In the new version, as we have discussed, the sensitive flag can now be set even for input variables and modules. But, the fact that it’s still available as plain text in the Terraform state file is a concern that we hope can be resolved. Terraform import: Even in our Terraform FAQ blog, one of the most frequently asked questions was about cloning infrastructure. The “import” command is available only for cloning the Terraform state file, and the rest of the configuration will have to be written by users. Again, this feature is available only if the previous code was also written in Terraform. Hopefully, we’ll see some updates around this issue.

If you wish to upgrade to Terraform v0.14.0 and give all of the features a try, you can download and upgrade to the version you’d like from their official site. There is an upgrade guide with all of the necessary steps required from your end, make sure you go through it before you update.

What are your thoughts about these updates? Join us on Slack to meet both Terraform experts and learners, and continue learning.

👋 Join FAUN today and receive similar stories each week in your inbox! ️ Get your weekly dose of the must-read tech stories, news, and tutorials.

Follow us on Twitter 🐦 and Facebook 👥 and Instagram 📷 and join our Facebook and Linkedin Groups 💬