Posted on 18 January 2021, updated on 6 August 2021.
HashiCorp released a new Terraform version in December: 0.14. We migrated from 0.13 to 0.14 one month ago. Therefore, I would like to share with you my experience with this new release. At time of writing, I use Terraform 0.14.2.
Migrating from 0.13 to 0.14
For my project, the migration from 0.13 to 0.14 was very smooth. We met only one problem with this migration to the release 0.14, but running `terraform fmt` resolved the issue immediately. By the way, we will see the new features in this command, which are pretty cool.
New feature: A lock file
A significant new feature in release 0.14 is the lock file. Terraform now creates a lock file to avoid new potential issues with providers. Before, if you did not have provider version constraints in your backend file, every `terraform init
` command could upgrade a provider version. This could cause issues (like breaking changes) in your infrastructure and be very painful.
I believe having version constraints is an excellent practice, and I recommend having them as much as possible to have the exact versions you want.
If you want to keep the same behavior from Terraform 0.13, you can use `terraform init -upgrade
`.
Enhancement: Clearer diffs for "terraform plan”
In Terraform 0.13, I did not like the diffs result for `terraform plan
` and `terraform apply
`. Many modifications can make this representation unclear. I wished for an improvement and Terraform has made it reality: a lighter and clearer output. I like this enhancement from release 0.14. It does not display the unchanged configuration, like in this snippet :
This diffs result is better than the release 0.13, but further improvements are still possible. I would like to see a recap at the end of the diff listing all resources destroyed, added, and changed. This recap would highlight the changes and especially potential unwanted changes in the Terraform state modifications.
New feature: Sensitive input variables
Terraform 0.14 allows you to input variables as sensitive, so that they are not logged. All you need to do is add the parameter “sensitive” like this :
This new feature is pretty cool to avoid displaying sensitive data, particularly in a CI/CD pipeline applying Terraform states.
Enhancement: Improved linting for `terraform fmt`
Like I said above, when migrating from 0.13 to 0.14, we ran `terraform fmt
` let us discover some interesting features. The new `terraform fmt
` command now:
- Removes deprecated syntax
This Terraform command removes all “${}” surrounding variables if it is not necessary. For example, you have a google_compute_health_check
resource with the following configuration :
The command `terraform fmt
` removes the “${}” around the variable healthcheck_name
and the output will be :
It is a nice new feature in Terraform 0.14, particularly if you have many files with this deprecated syntax.
- Disambiguate types for map and list variables
The fmt command adds the type “any” for every map and list from the new Terraform release. It is an excellent initiative to show us a best practice: specify a type for all variables. To avoid unwanted errors, I think you should always add an exact type for every variable.
Issue: Truncated integer IDs
I met one issue with a google_compute_url_map
resource. The google provider provides this resource. The plan was inconsistent, and so we can not modify the resource.
Confirming the “apply” produced this error. We used the google provider version 3.51.0. After investigating it, we found it is a known issue. Truncation of significant numbers from Terraform 0.14 produced this inconsistent plan. It was very problematic in my project, but thankfully the bug was fixed very quickly in the new version of the Google provider: 3.51.1.
Recommendation: Should you migrate?
The migration from release 0.13 to 0.14 is not complicated, and this new version has some excellent new features. I think you should go ahead and migrate your infrastructure to Terraform 0.14 today!