65 lines
3.1 KiB
Markdown
65 lines
3.1 KiB
Markdown
---
|
|
layout: "language"
|
|
page_title: "State: Remote Storage"
|
|
sidebar_current: "docs-state-remote"
|
|
description: |-
|
|
Terraform can store the state remotely, making it easier to version and work with in a team.
|
|
---
|
|
|
|
# Remote State
|
|
|
|
By default, Terraform stores state locally in a file named `terraform.tfstate`.
|
|
When working with Terraform in a team, use of a local file makes Terraform
|
|
usage complicated because each user must make sure they always have the latest
|
|
state data before running Terraform and make sure that nobody else runs
|
|
Terraform at the same time.
|
|
|
|
With _remote_ state, Terraform writes the state data to a remote data store,
|
|
which can then be shared between all members of a team. Terraform supports
|
|
storing state in [Terraform Cloud](https://www.hashicorp.com/products/terraform/),
|
|
[HashiCorp Consul](https://www.consul.io/), Amazon S3, Azure Blob Storage, Google Cloud Storage, Alibaba Cloud OSS, and more.
|
|
|
|
Remote state is a feature of [backends](/docs/backends/), which you can activate
|
|
in your configuration's root module.
|
|
|
|
## Delegation and Teamwork
|
|
|
|
Remote state allows you to share
|
|
[output values](/docs/configuration/outputs.html) with other configurations.
|
|
This allows your infrastructure to be decomposed into smaller components.
|
|
|
|
Put another way, remote state also allows teams to share infrastructure
|
|
resources in a read-only way without relying on any additional configuration
|
|
store.
|
|
|
|
For example, a core infrastructure team can handle building the core
|
|
machines, networking, etc. and can expose some information to other
|
|
teams to run their own infrastructure. As a more specific example with AWS:
|
|
you can expose things such as VPC IDs, subnets, NAT instance IDs, etc. through
|
|
remote state and have other Terraform states consume that.
|
|
|
|
For example usage, see
|
|
[the `terraform_remote_state` data source](/docs/providers/terraform/d/remote_state.html).
|
|
|
|
While remote state can be a convenient, built-in mechanism for sharing data
|
|
between configurations, you may prefer to use more general stores to
|
|
pass settings both to other configurations and to other consumers. For example,
|
|
if your environment has [HashiCorp Consul](https://www.consul.io/) then you
|
|
can have one Terraform configuration that writes to Consul using
|
|
[`consul_key_prefix`](https://registry.terraform.io/providers/hashicorp/consul/latest/docs/resources/key_prefix) and then
|
|
another that consumes those values using
|
|
[the `consul_keys` data source](https://registry.terraform.io/providers/hashicorp/consul/latest/docs/data-sources/keys).
|
|
|
|
## Locking and Teamwork
|
|
|
|
For fully-featured remote backends, Terraform can also use
|
|
[state locking](/docs/state/locking.html) to prevent concurrent runs of
|
|
Terraform against the same state.
|
|
|
|
[Terraform Cloud by HashiCorp](https://www.hashicorp.com/products/terraform/)
|
|
is a commercial offering that supports an even stronger locking concept that
|
|
can also detect attempts to create a new plan when an existing plan is already
|
|
awaiting approval, by queuing Terraform operations in a central location.
|
|
This allows teams to more easily coordinate and communicate about changes to
|
|
infrastructure.
|