Coming rapidly on the heels of the 1.4 release of Vault and the 1.8 beta release of Consul, HashiCorp today announced that version 0.13 of Terraform is imminent, with a public beta dropping on the 3rd of June, followed by a second beta on the 17th of June. They have not as yet announced the release candidates or GA release dates but I expect them to be fairly quickly if the beta builds are solid. For a full list of current changes in 0.13 read the changelog.
The main changes to version 0.13
Terraform will now allow the installation of 3rd party providers to the “required_providers” stanza according to this article, similar to the way that the Yum Repository on a Linux server can be extended to add repositories to third-party applications.
As of 0.12.20 providers have been added to Terraform registry and you can set the version that is required using the “required_providers” tag. The source of the provider is implied as registry.terraform.io or releases.hashicorp.com. However, with the release of version 0.13 extra functionality is being added to allow the extension of the namespace to environments outside of the HashiCorp namespace to allow community providers to be automatically installed with the addition of some “source” to the Random key.
Let’s examine these changes in a Terraform configuration using both the existing and new syntax:
terraform { required_providers { # This is the current syntax, which is still supported random = ">= 2.7.0" # This is the new syntax. "source" and "version" are both # optional, though in the future "source" will be required for # any provider that isn't maintained by HashiCorp. random = { source = "registry.terraform.io/hashicorp/random" version = "2.1.0" } } }
One of the benefits of this change is that it simplifies the installation and use of providers for all workflows including those NOT a part of the official HashiCorp repository. This is a massive move forward for Terraform as it will allow the easy delivery of 3rd party providers, and private custom providers to be easily integrated. From the perspective of security this is a massive move forward as there will be no requirement for punching a hole in your external firewall to allow the download of providers. This is a massive leap forward for those that due to their elevated security posture have to work in air-gapped environments.
The second major change again for the better is the introduction of count, for_each and hopefully depends_on features. The Terraform community has been crying out for these features; a “while” feature would be nice too; but the addition of these three features moves HCL forward dramatically.
One thing that is still missing however is a proper error handling feature for internal errors in code. Terraform coders are an inventive bunch, but it is getting old having to revisit the workarounds put in place because error handling is very basic in the core program language; see this post for an example of what we are talking about.
It is expected that the upgrade to version 0.13 will require an update to the underlying providers and this appears to the case as the AWS provider has a version 3.0 that is partway through the release cycle.
So once again it is expected that there will be a requirement for a major rewrite of code as quite a few commands have been depreciated and several actually removed so remember to run your current code through the upgrade command terraform 0.13 upgrade, macOS users have a major upgrade coming up especially if you are still on El Capitan; as 0.13 will be the last Terraform version that support it. There is a recommendation to update to MacOS Sierra or later. Also those who use FreeBSD will need to run at least 11.2 or later.
Summary
As said in the introduction HashiCorp as in an update frenzy, the release of Terraform 0.13 into public Beta is a massive step forward, This upgrades regarding the installation of provisioners into a deployment environment will aid adoption into secure sites as they can download the required provisioners into a sand-box environment and move them to their secure enclaves.
The introduction of the ability to count and use for_each means that HCL code will be significantly cleaner, with the removal of dirty workarounds. We recommend that when it is released join the public beta and join in the fun. But remember this is a Beta and as such any features that are in it are not guaranteed to be in the General Availability version so do not use this for production deployments.