Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage News HashiCorp Terraform 0.9. Released with State Locking, State Environments, and Destroy Provisioners

HashiCorp Terraform 0.9. Released with State Locking, State Environments, and Destroy Provisioners

This item in japanese

HashiCorp have released Terraform 0.9, which includes: significant improvements to how remote state is managed, including state locking, 'state environments', and a new centralised initialisation command 'terraform init'; destroy provisioners, which can be configured to run before a resource is destroyed; and 'resource interrupts' on selected resources, allowing immediate operator interrupts to be handled with custom logic.

Although care has been taken to ensure backwards compatibility with existing remote state, it should be noted that support for legacy-configured remote state will be removed in Terraform 0.11. The first major improvement is native state-locking in supported backends to prevent multiple concurrent writes. Backends that support state locking in Terraform 0.9 include local, AWS S3, and Consul.

The HashiCorp blog discusses how state locking makes Terraform safer to use in team environments by reducing the risk of one team member accidentally overwriting the work of another. State locking happens automatically on all operations that could write state, and if state locking fails, Terraform will not continue. State locking can be disabled for most commands with the '-lock' flag, however this it is not recommended. If unlocking fails, Terraform will provide a lock ID and metadata that can be used to 'force-unlock' if necessary. More information on state locking can be found in the documentation.

Remote state is now part of 'backends', a new abstraction in Terraform to encapsulate various pluggable functionality, such as 'state environments'. A state environment is a state namespace that allows a single folder of Terraform configurations to manage multiple distinct sets of infrastructure resources. State environments are similar to branches in a version control system, except state environments cannot be merged. Environments are useful for isolating a set of resources to test changes during development, after which any required changes will have to be re-applied to any other environments. State environments are managed using the CLI:

The HashiCorp blog states that a state environment alone should not be used to manage the difference between development, staging, and production. As Terraform configurations get larger, it is "much more manageable and safer to split one large configuration into many smaller ones linked together with terraform_remote_state data sources", as this allows teams to delegate ownership and reduce impact of changes. More information about state environments can be found in the documentation page.

Terraform 0.9 also introduces a new command 'terraform init' that is responsible for initialisation and setup of Terraform configuration. As part of initialisation, Terraform detects any changes to backend configuration and offers to migrate existing state, allowing a developer to move from one backend type to another and have Terraform automatically manage this change. This new command should be an essential part of any Terraform workflow:

[The 'terraform init'] command should become the go-to setup command for every team member to run for every Terraform configuration. It is safe to run multiple times and ensures your backend is properly configured.

All Terraform commands now work seamlessly with remote state, from primary commands such as 'terraform plan' to helper commands like 'terraform taint' or 'terraform console'. When one of these commands is run from a local machine, it automatically runs against the remote state rather than local state. According to HashiCorp "this way users can use the CLI they are comfortable with, but still gain the benefits of remote state storage in team settings". Additional information can be found in the full backend documentation.

Terraform 0.9 also includes support for running provisioners when a resource is destroyed. Starting from the initial 0.1 release, Terraform has supported provisioners as a mechanism for performing provisioning actions as part of resource creation, such as running commands locally or remotely. Destroy provisioners enhance this functionality to do the same as part of resource destruction if the parameter "when = 'destroy'" is specified. The provisioner will run before the resource it is defined within is destroyed. If this fails, Terraform will error and rerun the provisioners again on the next 'terraform apply'. Due to this default behaviour, care should be taken for destroy provisioners to be safe to run multiple times.

Several minor enhancements have also been included in the 0.9 release. Interrupts can now be detected and handled with custom logic in resources that provide support. Terraform 0.9 also adds support for many new providers and hundreds of new resources. There has been significant improvements to existing resources, including: AWS instances can be resized without forced destruction; full IPv6 support for EC2; and the DNSimple provider was updated to use APIv2 while only requiring a new auth token.

Terraform 0.9 has no core backwards incompatibilities, but includes deprecations and changes as documented in the upgrade guide. Additional information on the Terraform 0.9 release can be found on the HashiCorp blog.

Rate this Article