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 that can be configured run before a resource is destroyed; and resource…
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 run before a resource is destroyed; and ‘resource interrupts’ on selected resources, allowing immediate operator interrupts to be handled with custom logic.
Terraform 0.9 introduces significant improvements to how remote state is managed. 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 ‘.
