Just add provider: Terraform reworks third-party intricacies, enhances module workflows

Terraform Enterprise

Infrastructure tooling company HashiCorp has pushed out version 0.13 of its infra as code helper Terraform – along with an improved registry for Terraform providers and modules.

Terraform Registry is directly integrated into Terraform and serves as “the main directory of publicly available Terraform providers, and hosts providers for most major infrastructure platforms”. Providers is Terraform’s term for plugins, and they are mainly used by the tool to interact with other systems.

Since there’s a huge variety of providers, the registry, which is a successor of the provider list formerly present on the Terraform website, comes tiered into official, verified, and community plugins. While providers with an official badge, such as the GitHub and Active directory ones, are maintained and owned by HashiCorp itself, verified offerings are supplied by company technology partners such as Cloudflare and DigitalOcean and are signed by HashiCorp to signal trustworthiness. 

Once they’ve signed into the Terraform Registry, community members can use the platform to share their providers for better visibility as well. A prerequisite for this is that the provider in question lives in a public GitHub repository whose name matches the terraform-provider-{NAME} pattern. Since the Registry has become an official provider source in Terraform 0.13, this is well worth considering, especially for companies that haven’t partnered with Terraform but would like a comfortable way to share plugins with customers. 

After all it means that terraform init is able to automatically download and install providers that have been released into the registry, no matter the tier. On the downside, it means users might have to be a bit more careful when adding required providers to their list.

Another focal point for the Terraform team was the improvement of module-centric workflows. New arguments count and for_each can for example help to create multiple instances of a module, while depends_on ensures that module resource changes “will be applied after any changes to the depends_on targets have been applied.” Users working with Kubernetes will also be interested in the newly available remote state storage backend, which can be used to store state snapshots as Kubernetes secrets.

HashiCorp has also been busy enhancing Terraforms command line interface, which now displays trust signature information when installing providers, allows the specification of installation methods for different providers, and is able to import provider configurations containing references to other objects. It also includes a terraform state replace-provider subcommand which lets users change the provider for an existing resource instance in the Terraform state. New terraform providers mirror automatically constructs or updates a local filesystem mirror directory with the providers required for the current configuration.

Since Terraform is still pre-1.0, the update comes with a couple of breaking changes which make the release notes worth checking, especially if you’re using Amazon S3 as a backend. Users will also have to consolidate their required_providers blocks into one when having several, and add explicit source specification for any provider that is not in the “hashicorp” namespace to make sure their system keeps running as intended.