Merge pull request #11976 from hashicorp/b-0-9-website

0.9 Website Content (Backends, Locking, etc.)
This commit is contained in:
Mitchell Hashimoto 2017-02-15 13:15:52 -08:00 committed by GitHub
commit 7e14184393
34 changed files with 1220 additions and 748 deletions

View File

@ -6,6 +6,7 @@ body.page-sub{
background-color: $light-black;
}
body.layout-backend-types,
body.layout-commands-state,
body.layout-alicloud,
body.layout-archive,

View File

@ -0,0 +1,96 @@
---
layout: "docs"
page_title: "Backends: Configuration"
sidebar_current: "docs-backends-config"
description: |-
Backends are configured directly in Terraform files in the `terraform` section.
---
# Backend Configuration
Backends are configured directly in Terraform files in the `terraform`
section. After configuring a backend, it has to be
[initialized](/docs/backends/init.html).
Below, we show a complete example configuring the "consul" backend:
```
terraform {
backend "consul" {
address = "demo.consul.io"
path = "tfdocs"
}
}
```
You specify the backend type as a key to the `backend` stanza. Within the
stanza are backend-specific configuration keys. The list of supported backends
and their configuration is in the sidebar to the left.
Only one backend may be specified and the configuration **may not contain
interpolations**. Terraform will validate this.
## First Time Configuration
When configuring a backend for the first time (moving from no defined backend
to explicitly configuring one), Terraform will give you the option to migrate
your state to the new backend. This lets you adopt backends without losing
any existing state.
To be extra careful, we always recommend manually backing up your state
as well. You can do this by simply copying your `terraform.tfstate` file
to another location. The initialization process should create a backup
as well, but it never hurts to be safe!
Configuring a backend for the first time is no different than changing
a configuration in the future: create the new configuration and run
`terraform init`. Terraform will guide you the rest of the way.
## Partial Configuration
You do not need to specify every required attribute in the configuration.
This may be desirable to avoid storing secrets (such as access keys) within
the configuration itself. We call this specifying only a _partial_ configuration.
With a partial configuration, the remaining configuration is expected as
part of the [initialization](/docs/backends/init.html) process. There are
two ways to supply the remaining configuration:
* **Interactively**: Terraform will interactively ask you for the required
values. Terraform will not ask you for optional values.
* **File**: A configuration file may be specified via the command line.
This file can then be sourced via some secure means (such as
[Vault](https://www.vaultproject.io)).
In both cases, the final configuration is stored on disk in the
".terraform" directory, which should be ignored from version control.
This means that sensitive information can be omitted from version control
but it ultimately still lives on disk. In the future, Terraform may provide
basic encryption on disk so that values are at least not plaintext.
## Changing Configuration
You can change your backend configuration at any time. You can change
both the configuration itself as well as the type of backend (for example
from "consul" to "s3").
Terraform will automatically detect any changes in your configuration
and request a [reinitialization](/docs/backends/init.html). As part of
the reinitialization process, Terraform will ask if you'd like to migrate
your existing state to the new configuration. This allows you to easily
switch from one backend to another.
If you're just reconfiguring the same backend, Terraform will still ask if you
want to migrate your state. You can respond "no" in this scenario.
## Unconfiguring a Backend
If you no longer want to use any backend, you can simply remove the
configuration from the file. Terraform will detect this like any other
change and prompt you to [reinitialize](/docs/backends/init.html).
As part of the reinitialization, Terraform will ask if you'd like to migrate
your state back down to normal local state. Once this is complete then
Terraform is back to behaving as it does by default.

View File

@ -0,0 +1,45 @@
---
layout: "docs"
page_title: "Backends"
sidebar_current: "docs-backends-index"
description: |-
A "backend" in Terraform determines how state is loaded and how an operation such as `apply` is executed. This abstraction enables non-local file state storage, remote execution, etc.
---
# Backends
A "backend" in Terraform determines how state is loaded and how an operation
such as `apply` is executed. This abstraction enables non-local file state
storage, remote execution, etc.
By default, Terraform uses the "local" backend, which is the normal behavior
of Terraform you're used to. This is the backend that was being invoked
throughout the [introduction](/intro/index.html).
Here are some of the benefits of backends:
* **Working in a team**: Backends can store their state remotely and
protect that state with locks to prevent corruption. Some backends
such as Terraform Enterprise even automatically store a history of
all state revisions.
* **Keeping sensitive information off disk**: State is retrieved from
backends on demand and only stored in memory. If you're using a backend
such as Amazon S3, the only location the state ever is persisted is in
S3.
* **Remote operations**: For larger infrastructures or certain changes,
`terraform apply` can take a long, long time. Some backends support
remote operations which enable the operation to execute remotely. You can
then turn off your computer and your operation will still complete. Paired
with remote state storage and locking above, this also helps in team
environments.
**Backends are completely optional**. You can successfully use Terraform without
ever having to learn or use backends. However, they do solve pain points that
afflict teams at a certain scale. If you're an individual, you can likely
get away with never using backends.
Even if you only intend to use the "local" backend, it may be useful to
learn about backends since you can also change the behavior of the local
backend.

View File

@ -0,0 +1,31 @@
---
layout: "docs"
page_title: "Backends: Init"
sidebar_current: "docs-backends-init"
description: |-
Terraform must initialize any configured backend before use. This can be done by simply running `terraform init`.
---
# Backend Initialization
Terraform must initialize any configured backend before use. This can be
done by simply running `terraform init`.
The `terraform init` command should be run by any member of your team on
any Terraform configuration as a first step. It is safe to execute multiple
times and performs all the setup actions required for a Terraform environment,
including initializing the backend.
The `init` command must be called:
* On any new environment that configures a backend
* On any change of the backend configuration (including type of backend)
* On removing backend configuration completely
You don't need to remember these exact cases. Terraform will detect when
initialization is required and error in that situation. Terraform doesn't
auto-initialize because it may require additional information from the user,
perform state migrations, etc.
The `init` command will do more than just initialize the backend. Please see
the [init documentation](/docs/commands/init.html) for more information.

View File

@ -0,0 +1,19 @@
---
layout: "docs"
page_title: "Backends: Operations (refresh, plan, apply, etc.)"
sidebar_current: "docs-backends-ops"
description: |-
Some backends support the ability to run operations (`refresh`, `plan`, `apply`, etc.) remotely. Terraform will continue to look and behave as if they're running locally while they in fact run on a remote machine.
---
# Operations (plan, apply, etc.)
Some backends support the ability to run operations (`refresh`, `plan`, `apply`,
etc.) remotely. Terraform will continue to look and behave as if they're
running locally while they in fact run on a remote machine.
Backends should not modify the actual infrastructure change behavior of
these commands. They will only modify how they're invoked.
At the time of writing, no backends support this. This shouldn't be linked
in the sidebar yet!

View File

@ -0,0 +1,73 @@
---
layout: "docs"
page_title: "Backends: State Storage and Locking"
sidebar_current: "docs-backends-state"
description: |-
Backends are configured directly in Terraform files in the `terraform` section.
---
# State Storage and Locking
Backends are responsible for storing state and providing an API for
[state locking](/docs/state/locking.html). State locking is optional.
Despite the state being stored remotely, all Terraform commands such
as `terraform console`, the `terraform state` operations, `terraform taint`,
and more will continue to work as if the state was local.
## State Storage
Backends determine where state is stored. For example, the local (default)
backend stores state in a local JSON file on disk. The Consul backend stores
the state within Consul. Both of these backends happen to provide locking:
local via system APIs and Consul via locking APIs.
When using a non-local backend, Terraform will not persist the state anywhere
on disk except in the case of a non-recoverable error where writing the state
to the backend failed. This behavior is a major benefit for backends: if
sensitive values are in your state, using a remote backend allows you to use
Terraform without that state ever being persisted to disk.
In the case of an error persisting the state to the backend, Terraform will
write the state locally. This is to prevent data loss. If this happens the
end user must manually push the state to the remote backend once the error
is resolved.
## Manual State Pull/Push
You can still manually retrieve the state from the remote state using
the `terraform state pull` command. This will load your remote state and
output it to stdout. You can choose to save that to a file or perform any
other operations.
You can also manually write state with `terraform state push`. **This
is extremely dangerous and should be avoided if possible.** This will
overwrite the remote state. This can be used to do manual fixups if necessary.
When manually pushing state, Terraform will attempt to protect you from
some potentially dangerous situations:
* **Differing lineage**: The "lineage" is a unique ID assigned to a state
when it is created. If a lineage is different, then it means the states
were created at different times and its very likely you're modifying a
different state. Terraform will not allow this.
* **Higher serial**: Every state has a monotonically increasing "serial"
number. If the destination state has a higher serial, Terraform will
not allow you to write it since it means that changes have occurred since
the state you're attempting to write.
Both of these protections can be bypassed with the `-force` flag if you're
confident you're making the right decision. Even if using the `-force` flag,
we recommend making a backup of the state with `terraform state pull`
prior to forcing the overwrite.
## State Locking
Backends are responsible for supporting [state locking](/docs/state/locking.html)
if possible. Not all backend types support state locking. In the
[list of supported backend types](/docs/backends/types) we explicitly note
whether locking is supported.
For more information on state locking, view the
[page dedicated to state locking](/docs/state/locking.html).

View File

@ -1,14 +1,17 @@
---
layout: "remotestate"
page_title: "Remote State Backend: artifactory"
sidebar_current: "docs-state-remote-artifactory"
layout: "backend-types"
page_title: "Backend Type: artifactory"
sidebar_current: "docs-backends-types-standard-artifactory"
description: |-
Terraform can store the state remotely, making it easier to version and work with in a team.
Terraform can store state in artifactory.
---
# artifactory
Stores the state as an artifact in a given repository in [Artifactory](https://www.jfrog.com/artifactory/).
**Kind: Standard (with no locking)**
Stores the state as an artifact in a given repository in
[Artifactory](https://www.jfrog.com/artifactory/).
Generic HTTP repositories are supported, and state from different
configurations may be kept at different subpaths within the repository.
@ -16,16 +19,18 @@ configurations may be kept at different subpaths within the repository.
-> **Note:** The URL must include the path to the Artifactory installation.
It will likely end in `/artifactory`.
## Example Usage
## Example Configuration
```
terraform remote config \
-backend=artifactory \
-backend-config="username=SheldonCooper" \
-backend-config="password=AmyFarrahFowler" \
-backend-config="url=https://custom.artifactoryonline.com/artifactory" \
-backend-config="repo=foo" \
-backend-config="subpath=terraform-bar"
terraform {
backend "artifactory" {
username = "SheldonCooper"
password = "AmyFarrahFowler"
url = "https://custom.artifactoryonline.com/artifactory"
repo = "foo"
subpath = "teraraform-bar"
}
}
```
## Example Referencing

View File

@ -0,0 +1,52 @@
---
layout: "backend-types"
page_title: "Backend Type: atlas"
sidebar_current: "docs-backends-types-standard-atlas"
description: |-
Terraform can store the state in Atlas.
---
# atlas
**Kind: Standard (with no locking)**
Stores the state in [Atlas](https://atlas.hashicorp.com/).
You can create a new environment in the
[Environments section](https://atlas.hashicorp.com/environments)
and generate new token in the
[Tokens page](https://atlas.hashicorp.com/settings/tokens) under Settings.
## Example Configuration
```
terraform {
backend "atlas" {
name = "bigbang/example"
access_token = "foo"
}
}
```
Note that for the access token we recommend using a
[partial configuration](/docs/backends/config.html).
## Example Referencing
```
data "terraform_remote_state" "foo" {
backend = "atlas"
config {
name = "bigbang/example"
access_token = "X2iTFefU5aWOjg.atlasv1.YaDa"
}
}
```
## Configuration variables
The following configuration options / environment variables are supported:
* `name` - (Required) Full name of the environment (`<username>/<name>`)
* `access_token` / `ATLAS_TOKEN` - (Required) Atlas API token
* `address` - (Optional) Address to alternative Atlas location (Atlas Enterprise endpoint)

View File

@ -1,30 +1,31 @@
---
layout: "remotestate"
page_title: "Remote State Backend: azure"
sidebar_current: "docs-state-remote-azure"
layout: "backend-types"
page_title: "Backend Type: azure"
sidebar_current: "docs-backends-types-standard-azure"
description: |-
Terraform can store the state remotely, making it easier to version and work with in a team.
Terraform can store state remotely in Azure Storage.
---
# azure
**Kind: Standard (with no locking)**
Stores the state as a given key in a given bucket on [Microsoft Azure Storage](https://azure.microsoft.com/en-us/documentation/articles/storage-introduction/).
-> **Note:** Passing credentials directly via config options will
make them included in cleartext inside the persisted state.
Access key should, ideally, be passed using the environment variable
`ARM_ACCESS_KEY` to follow this convention.
## Example Usage
## Example Configuration
```hcl
terraform {
backend "azure" {
storage_account_name = "abcd1234"
container_name = "tfstate"
key = "prod.terraform.tfstate"
}
}
```
terraform remote config \
-backend=azure \
-backend-config="storage_account_name=terraform123abc" \
-backend-config="container_name=terraform-state" \
-backend-config="key=prod.terraform.tfstate"
```
Note that for the access credentials we recommend using a
[partial configuration](/docs/backends/config.html).
## Example Referencing

View File

@ -1,27 +1,33 @@
---
layout: "remotestate"
page_title: "Remote State Backend: consul"
sidebar_current: "docs-state-remote-consul"
layout: "backend-types"
page_title: "Backend Type: consul"
sidebar_current: "docs-backends-types-standard-consul"
description: |-
Terraform can store the state remotely, making it easier to version and work with in a team.
Terraform can store state in Consul.
---
# consul
**Kind: Standard (with locking)**
Stores the state in the [Consul](https://www.consul.io/) KV store at a given path.
-> **Note:** Specifying `access_token` directly makes it included in
cleartext inside the persisted, shard state.
Use of the environment variable `CONSUL_HTTP_TOKEN` is recommended.
This backend supports [state locking](/docs/state/locking.html).
## Example Usage
## Example Configuration
```
terraform remote config \
-backend=consul \
-backend-config="path=full/path"
terraform {
backend "consul" {
address = "demo.consul.io"
path = "full/path"
}
}
```
Note that for the access credentials we recommend using a
[partial configuration](/docs/backends/config.html).
## Example Referencing
```

View File

@ -1,22 +1,26 @@
---
layout: "remotestate"
page_title: "Remote State Backend: etcd"
sidebar_current: "docs-state-remote-etcd"
layout: "backend-types"
page_title: "Backend Type: etcd"
sidebar_current: "docs-backends-types-standard-etcd"
description: |-
Terraform can store the state remotely, making it easier to version and work with in a team.
Terraform can store state remotely in etcd.
---
# etcd
**Kind: Standard (with no locking)**
Stores the state in [etcd](https://coreos.com/etcd/) at a given path.
## Example Usage
## Example Configuration
```
terraform remote config \
-backend=etcd \
-backend-config="path=path/to/terraform.tfstate" \
-backend-config="endpoints=http://one:4001 http://two:4001"
terraform {
backend "etcd" {
path = "path/to/terraform.tfstate"
endpoints = "http://one:4001 http://two:4001"
}
}
```
## Example Referencing

View File

@ -1,27 +1,27 @@
---
layout: "remotestate"
page_title: "Remote State Backend: gcs"
sidebar_current: "docs-state-remote-gcs"
layout: "backend-types"
page_title: "Backend Type: gcs"
sidebar_current: "docs-backends-types-standard-gcs"
description: |-
Terraform can store the state remotely, making it easier to version and work with in a team.
---
# gcs
**Kind: Standard (with no locking)**
Stores the state as a given key in a given bucket on [Google Cloud Storage](https://cloud.google.com/storage/).
-> **Note:** Passing credentials directly via config options will
make them included in cleartext inside the persisted state.
Use of environment variables or config file is recommended.
## Example Usage
## Example Configuration
```
terraform remote config \
-backend=gcs \
-backend-config="bucket=terraform-state-prod" \
-backend-config="path=network/terraform.tfstate" \
-backend-config="project=goopro"
terraform {
backend "gcs" {
bucket = "tf-state-prod"
path = "path/terraform.tfstate"
project = "myproject"
}
}
```
## Example Referencing

View File

@ -1,13 +1,15 @@
---
layout: "remotestate"
page_title: "Remote State Backend: http"
sidebar_current: "docs-state-remote-http"
layout: "backend-types"
page_title: "Backend Type: http"
sidebar_current: "docs-backends-types-standard-http"
description: |-
Terraform can store the state remotely, making it easier to version and work with in a team.
Terraform can store state remotely at any valid HTTP endpoint.
---
# http
**Kind: Standard (with no locking)**
Stores the state using a simple [REST](https://en.wikipedia.org/wiki/Representational_state_transfer) client.
State will be fetched via GET, updated via POST, and purged with DELETE.
@ -15,9 +17,11 @@ State will be fetched via GET, updated via POST, and purged with DELETE.
## Example Usage
```
terraform remote config \
-backend=http \
-backend-config="address=http://my.rest.api.com"
terraform {
backend "http" {
address = "http://myrest.api.com"
}
}
```
## Example Referencing

View File

@ -0,0 +1,25 @@
---
layout: "backend-types"
page_title: "Backend: Supported Backend Types"
sidebar_current: "docs-backends-types-index"
description: |-
Terraform can store the state remotely, making it easier to version and work with in a team.
---
# Backend Types
This section documents the various backend types supported by Terraform.
If you're not familiar with backends, please
[read the sections about backends](/docs/backends/index.html) first.
Backends may support differing levels of features in Terraform. We differentiate
these by calling a backend either **standard** or **enhanced**. All backends
must implement **standard** functionality. These are defined below:
* **Standard**: State management, functionality covered in
[State Storage & Locking](/docs/backends/state.html)
* **Enhanced**: Everything in standard plus
[remote operations](/docs/backends/operations.html).
The backends are separated in the left by standard and enhanced.

View File

@ -0,0 +1,43 @@
---
layout: "backend-types"
page_title: "Backend Type: local"
sidebar_current: "docs-backends-types-enhanced-local"
description: |-
Terraform can store the state remotely, making it easier to version and work with in a team.
---
# local
**Kind: Enhanced**
The local backend stores state on the local filesystem, locks that
state using system APIs, and performs operations locally.
## Example Configuration
```
terraform {
backend "local" {
path = "relative/path/to/terraform.tfstate"
}
}
```
## Example Reference
```
data "terraform_remote_state" "foo" {
backend = "local"
config {
path = "${path.module}/../../terraform.tfstate"
}
}
```
## Configuration variables
The following configuration options are supported:
* `path` - (Optional) The path to the `tfstate` file. This defaults to
"terraform.tfstate" relative to the root module by default.

View File

@ -1,24 +1,31 @@
---
layout: "remotestate"
page_title: "Remote State Backend: manta"
sidebar_current: "docs-state-remote-manta"
layout: "backend-types"
page_title: "Backend Type: manta"
sidebar_current: "docs-backends-types-standard-manta"
description: |-
Terraform can store the state remotely, making it easier to version and work with in a team.
Terraform can store state in manta.
---
# manta
**Kind: Standard (with no locking)**
Stores the state as an artifact in [Manta](https://www.joyent.com/manta).
## Example Usage
## Example Configuration
```
terraform remote config \
-backend=manta \
-backend-config="path=random/path" \
-backend-config="objecName=terraform.tfstate"
terraform {
backend "manta" {
path = "random/path"
objectName = "terraform.tfstate"
}
}
```
Note that for the access credentials we recommend using a
[partial configuration](/docs/backends/config.html).
## Example Referencing
```

View File

@ -1,40 +1,41 @@
---
layout: "remotestate"
page_title: "Remote State Backend: s3"
sidebar_current: "docs-state-remote-s3"
layout: "backend-types"
page_title: "Backend Type: s3"
sidebar_current: "docs-backends-types-standard-s3"
description: |-
Terraform can store the state remotely, making it easier to version and work with in a team.
Terraform can store state remotely in S3 and lock that state with DynamoDB.
---
# S3
Stores the state as a given key in a given bucket on [Amazon
S3](https://aws.amazon.com/s3/).
**Kind: Standard (with locking via DynamoDB)**
Stores the state as a given key in a given bucket on
[Amazon S3](https://aws.amazon.com/s3/).
This backend also supports state locking via
[Dynamo DB](https://aws.amazon.com/dynamodb/).
~> **Warning!** It is highly recommended that you enable
[Bucket Versioning](http://docs.aws.amazon.com/AmazonS3/latest/UG/enable-bucket-versioning.html)
on the S3 bucket to allow for state recovery in the case of accidental deletions and human error.
## Using S3 for Remote State
To enable remote state on S3 we run the `terraform remote config`
command like so:
## Example Configuration
```
terraform remote config \
-backend=s3 \
-backend-config="bucket=terraform-state-prod" \
-backend-config="key=network/terraform.tfstate" \
-backend-config="region=us-east-1"
terraform {
backend "s3" {
bucket = "mybucket"
key = "path/to/my/key"
region = "us-east-1"
}
}
```
This assumes we have a bucket created called `terraform-state-prod`. The
Terraform state is written to the file `terraform.tfstate` in a folder
called `network`.
This assumes we have a bucket created called `mybucket`. The
Terraform state is written to the key `path/to/my/key`.
-> **Note:** Passing credentials directly via configuration options will
make them included in cleartext inside the persisted state. Use of
environment variables or a configuration file is recommended.
Note that for the access credentials we recommend using a
[partial configuration](/docs/backends/config.html).
## Using the S3 remote state

View File

@ -1,27 +1,30 @@
---
layout: "remotestate"
page_title: "Remote State Backend: swift"
sidebar_current: "docs-state-remote-swift"
layout: "backend-types"
page_title: "Backend Type: swift"
sidebar_current: "docs-backends-types-standard-swift"
description: |-
Terraform can store the state remotely, making it easier to version and work with in a team.
Terraform can store state remotely in Swift.
---
# swift
**Kind: Standard (with no locking)**
Stores the state as an artifact in [Swift](http://docs.openstack.org/developer/swift/).
-> **Note:** Passing credentials directly via configuration options will
make them included in cleartext inside the persisted state. Use of
environment variables is recommended.
## Example Usage
## Example Configuration
```
terraform remote config \
-backend=swift \
-backend-config="path=terraform_state"
terraform {
backend "swift" {
path = "terraform-state"
}
}
```
Note that for the access credentials we recommend using a
[partial configuration](/docs/backends/config.html).
## Example Referencing
```

View File

@ -3,62 +3,71 @@ layout: "docs"
page_title: "Command: init"
sidebar_current: "docs-commands-init"
description: |-
The `terraform init` command is used to initialize a Terraform configuration using another module as a skeleton.
The `terraform init` command is used to initialize a Terraform configuration. This is the first command that should be run for any new or existing Terraform configuration. It is safe to run this command multiple times.
---
# Command: init
The `terraform init` command is used to initialize a Terraform configuration
using another
[module](/docs/modules/index.html)
as a skeleton.
The `terraform init` command is used to initialize a Terraform configuration.
This is the first command that should be run for any new or existing
Terraform configuration. It is safe to run this command multiple times.
## Usage
Usage: `terraform init [options] SOURCE [DIR]`
Usage: `terraform init [options] [SOURCE] [PATH]`
Init will download the module from SOURCE and copy it into the DIR
(which defaults to the current working directory). Version control
information from the module (such as Git history) will not be copied.
Initialize a new or existing Terraform environment by creating
initial files, loading any remote state, downloading modules, etc.
The directory being initialized must be empty of all Terraform configurations.
If the module has other files which conflict with what is already in the
directory, they _will be overwritten_.
This is the first command that should be run for any new or existing
Terraform configuration per machine. This sets up all the local data
necessary to run Terraform that is typically not comitted to version
control.
The command-line options available are a subset of the ones for the
[remote command](/docs/commands/remote.html), and are used to initialize
a remote state configuration if provided.
This command is always safe to run multiple times. Though subsequent runs
may give errors, this command will never blow away your environment or state.
Even so, if you have important information, please back it up prior to
running this command just in case.
If no arguments are given, the configuration in this working directory
is initialized.
If one or two arguments are given, the first is a SOURCE of a module to
download to the second argument PATH. After downloading the module to PATH,
the configuration will be initialized as if this command were called pointing
only to that PATH. PATH must be empty of any Terraform files. Any
conflicting non-Terraform files will be overwritten. The module download
is a copy. If you're downloading a module from Git, it will not preserve
Git history.
The command-line flags are all optional. The list of available flags are:
* `-backend=atlas` - Specifies the type of remote backend. Must be one
of Atlas, Consul, S3, or HTTP. Defaults to Atlas.
* `-backend=true` - Initialize the [backend](/docs/backends) for this environment.
* `-backend-config="k=v"` - Specify a configuration variable for a backend. This is how you set the required variables for the selected backend (as detailed in the [remote command documentation](/docs/commands/remote.html).
* `-backend-config=path` - Path to an HCL file with additional configuration
for the backend. This is merged with the backend in the Terraform configuration.
* `-get=true` - Download any modules for this configuration.
## Example: Consul
* `-input=true` - Ask for input interactively if necessary. If this is false
and input is required, `init` will error.
This example will initialize the current directory and configure Consul remote storage:
## Backend Config File
```
$ terraform init \
-backend=consul \
-backend-config="address=your.consul.endpoint:443" \
-backend-config="scheme=https" \
-backend-config="path=tf/path/for/project" \
/path/to/source/module
```
## Example: S3
This example will initialize the current directory and configure S3 remote storage:
```
$ terraform init \
-backend=s3 \
-backend-config="bucket=your-s3-bucket" \
-backend-config="key=tf/path/for/project.json" \
-backend-config="acl=bucket-owner-full-control" \
/path/to/source/module
The `-backend-config` path can be used to specify additional
backend configuration when [initialize a backend](/docs/backends/init.html).
This is particularly useful for
[partial configuration of backends](/docs/backends/config.html). Partial
configuration lets you keep sensitive information out of your Terraform
configuration.
The backend configuration file is a basic HCL file with key/value pairs.
The keys are configuration keys for your backend. You do not need to wrap it
in a `terraform` block. For example, the following file is a valid backend
configuration file for the Consul backend type:
```hcl
address = "demo.consul.io"
path = "newpath"
```

View File

@ -1,60 +0,0 @@
---
layout: "docs"
page_title: "Command: remote config"
sidebar_current: "docs-commands-remote-config"
description: |-
The `terraform remote config` command is used to configure Terraform to make
use of remote state storage, change remote storage configuration, or
to disable it.
---
# Command: remote config
The `terraform remote config` command is used to configure the use of remote state storage. By default, Terraform persists its state to a local disk. When remote state storage is enabled, Terraform will automatically fetch the latest state from the remote server when required. If updates are made, the newest state is persisted back to the remote server. In this mode, users do not need to store the state using version control or shared storage.
## Usage
Usage: `terraform remote config [options]`
The `remote config` command can be used to enable remote storage, change configuration or disable the use of remote storage. Terraform supports multiple types of storage backends, specified by using the `-backend` flag. By default, Atlas is assumed to be the storage backend. Each backend expects different configuration arguments documented below.
When remote storage is enabled, the existing local state file will be migrated. By default, `remote config` will look for the `terraform.tfstate` file, but that can be specified by the `-state` flag. If no state file exists, a blank state will be configured.
When remote storage is disabled, the existing remote state is migrated back to a local file. The location of the new local state file defaults to the path specified in the `-state` flag.
When enabling remote storage, we use the `-backend-config` flag to set any required configuration variables.
Supported storage backends and supported features of each backend are documented in the [Remote State](/docs/state/remote/index.html) section.
The command-line flags are all optional. The list of available flags are:
* `-backend=Atlas` - The remote backend to use. Must be one of the
supported backends.
* `-backend-config="k=v"` - Specify a configuration variable for a backend.
This is how you set any required variables for the backend.
* `-backup=path` - Path to backup the existing state file before
modifying. Defaults to the "-state" path with ".backup" extension.
Set to "-" to disable backup.
* `-disable` - Disables remote state management and migrates the state
to the `-state` path.
* `-pull=true` - Controls if the remote state is pulled before disabling
or after enabling. This defaults to true to ensure the latest state
is available under both conditions.
* `-state=path` - Path to read state. Defaults to `terraform.tfstate`
unless remote state is enabled.
## Example: Consul
This example below will push your remote state to a Consul server.
```
$ terraform remote config \
-backend=consul \
-backend-config="address=consul.example.com:80" \
-backend-config="path=tf"
```

View File

@ -1,23 +0,0 @@
---
layout: "docs"
page_title: "Command: remote pull"
sidebar_current: "docs-commands-remote-pull"
description: |-
The `terraform remote pull` refreshes the cached state file from the
remote server when remote state storage is enabled.
---
# Command: remote pull
The `terraform remote pull` refreshes the cached state file from the
remote server when remote state storage is enabled. The [`remote config`
command](/docs/commands/remote-config.html) should be used to enable
remote state storage.
## Usage
Usage: `terraform remote pull`
The `remote pull` command is invoked without options to refresh the
cache copy of the state.

View File

@ -1,27 +0,0 @@
---
layout: "docs"
page_title: "Command: remote push"
sidebar_current: "docs-commands-remote-push"
description: |-
The `terraform remote push` command is used to push a cached local copy
of the state to a remote storage server.
---
# Command: remote push
The `terraform remote push` uploads the cached state file to the
remote server when remote state storage is enabled. The [`remote config`
command](/docs/commands/remote-config.html) should be used to enable
remote state storage.
Uploading is typically done automatically when running a Terraform
command that modifies state, but this can be used to retry uploads
if a transient failure occurs.
## Usage
Usage: `terraform remote push`
The `remote push` command is invoked without options to upload the
local cached state to the remote storage server.

View File

@ -1,33 +0,0 @@
---
layout: "docs"
page_title: "Command: remote"
sidebar_current: "docs-commands-remote"
description: |-
The `terraform remote` command is used to configure Terraform to make
use of remote state storage, change remote storage configuration, or
to disable it.
---
# Command: remote
The `terraform remote` command is used to configure all aspects of
remote state storage. When remote state storage is enabled,
Terraform will automatically fetch the latest state from the remote
server when necessary and if any updates are made, the newest state
is persisted back to the remote server.
In this mode, users do not need to durably store the state using version
control or shared storage.
## Usage
Usage: `terraform remote SUBCOMMAND [options]`
The `remote` command behaves as another command that further has more
subcommands. The subcommands available are:
* [config](/docs/commands/remote-config.html) - Configure the remote storage,
including enabling/disabling it.
* [pull](/docs/commands/remote-pull.html) - Sync the remote storage to
the local storage (download).
* [push](/docs/commands/remote-push.html) - Sync the local storage to
remote storage (upload).

View File

@ -0,0 +1,24 @@
---
layout: "commands-state"
page_title: "Command: state pull"
sidebar_current: "docs-state-sub-pull"
description: |-
The `terraform state pull` command is used to manually download and output the state from remote state.
---
# Command: state pull
The `terraform state pull` command is used to manually download and output
the state from [remote state](/docs/state/remote.html). This command also
works with local state.
## Usage
Usage: `terraform state pull`
This command will download the state from its current location and
output the raw format to stdout.
This is useful for reading values out of state (potentially pairing this
command with something like [jq](https://stedolan.github.io/jq/)). It is
also useful if you need to make manual modifications to state.

View File

@ -0,0 +1,40 @@
---
layout: "commands-state"
page_title: "Command: state push"
sidebar_current: "docs-state-sub-push"
description: |-
The `terraform state rm` command removes items from the Terraform state.
---
# Command: state push
The `terraform state push` command is used to manually upload a local
state file to [remote state](/docs/state/remote.html). This command also
works with local state.
This command should rarely be used. It is meant only as a utility in case
manual intervention is necessary with the remote state.
## Usage
Usage: `terraform state push [options] PATH`
This command will push the state specified by PATH to the currently
configured [backend](/docs/backends).
Terraform will perform a number of safety checks to prevent you from
making changes that appear to be unsafe:
* **Differing lineage**: If the "lineage" value in the state differs,
Terraform will not allow you to push the state. A differing lineage
suggests that the states are completely different and you may lose
data.
* **Higher remote serial**: If the "serial" value in the destination state
is higher than the state being pushed, Terraform will prevent the push.
A higher serial suggests that data is in the destination state that isn't
accounted for in the local state being pushed.
Both of these safety checks can be disabled with the `-force` flag.
**This is not recommended.** If you disable the safety checks and are
pushing state, the destination state will be overwritten.

View File

@ -0,0 +1,41 @@
---
layout: "docs"
page_title: "State: Locking"
sidebar_current: "docs-state-locking"
description: |-
Terraform stores state which caches the known state of the world the last time Terraform ran.
---
# State Locking
If supported by your [backend](/docs/backends), Terraform will lock your
state for all operations that could write state. This prevents
others from acquiring the lock and potentially corrupting your state.
State locking happens automatically on all operations that could write
state. You won't see any message that it is happening. If state locking fails,
Terraform will not continue. You can disable state locking for most commands
with the `-lock` flag but it is not recommended.
If acquiring the lock is taking longer than expected, Terraform will output
a status message. If Terraform doesn't output a message, state locking is
still occuring if your backend supports it.
Not all [backends](/docs/backends) support locking. Please view the list
of [backend types](/docs/backends/types) for details on whether a backend
supports locking or not.
## Force Unlock
Terraform has a [force-unlock command](/docs/commands/force-unlock.html)
to manually unlock the state if unlocking failed.
**Be very careful with this command.** If you unlock the state when someone
else is holding the lock it could cause multiple writers. Force unlock should
only be used to unlock your own lock in the situation where automatic
unlocking failed.
To protect you, the `force-unlock` command requires a unique lock ID. Terraform
will output this lock ID if unlocking fails. This lock ID acts as a
[nonce](https://en.wikipedia.org/wiki/Cryptographic_nonce), ensuring
that locks and unlocks target the correct lock.

View File

@ -1,7 +1,7 @@
---
layout: "remotestate"
page_title: "Remote State"
sidebar_current: "docs-state-remote_index"
layout: "docs"
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.
---
@ -17,18 +17,10 @@ With remote state, Terraform stores the state in a remote store. Terraform
supports storing state in [Atlas](https://atlas.hashicorp.com),
[Consul](https://www.consul.io), S3, and more.
You can begin using remote state from the beginning with flags to the
[init](/docs/commands/init.html) command, or you can migrate an existing
local state to remote state using the
[remote config](/docs/commands/remote-config.html) command. You can also
use the remote config to disable remote state and move back to local
state.
### Example Usage
```
$ terraform remote config -disable
```
Remote state is a feature of [backends](/docs/backends). Configuring and
using backends is easy and you can get started with remote state quickly.
If you want to migrate back to using local state, backends make that
easy as well.
## Delegation and Teamwork
@ -47,18 +39,16 @@ 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](/docs/providers/terraform/d/remote_state.html) data source.
For example usage see the
[terraform_remote_state](/docs/providers/terraform/d/remote_state.html) data source.
## Locking and Teamwork
Remote state currently **does not** lock regions of your infrastructure
to allow parallel modification using Terraform. Therefore, you must still
collaborate with teammates to safely run Terraform.
Terraform will automatic lock state depending on the
[backend](/docs/backends) used. Please see the full page dedicated
to [state locking](/docs/state/locking.html).
[Atlas by HashiCorp](https://atlas.hashicorp.com) is a commercial offering
that does safely allow parallel Terraform runs and handles infrastructure
locking for you.
In the future, we'd like to extend the remote state system to allow some
minimal locking functionality, but it is a difficult problem without a
central system that we currently aren't focused on solving.
that in addition to locking supports remote operations that allow you to
safely queue Terraform operations in a central location. This enables
teams to safely modify infrastructure concurrently.

View File

@ -1,43 +0,0 @@
---
layout: "remotestate"
page_title: "Remote State Backend: atlas"
sidebar_current: "docs-state-remote-atlas"
description: |-
Terraform can store the state remotely, making it easier to version and work with in a team.
---
# atlas
Stores the state in [Atlas](https://atlas.hashicorp.com/).
You can create a new environment in the [Environments section](https://atlas.hashicorp.com/environments)
and generate new token in the [Tokens page](https://atlas.hashicorp.com/settings/tokens) under Settings.
## Example Usage
```
terraform remote config \
-backend=atlas \
-backend-config="name=bigbang/example" \
-backend-config="access_token=X2iTFefU5aWOjg.atlasv1.YaDa" \
```
## Example Referencing
```
data "terraform_remote_state" "foo" {
backend = "atlas"
config {
name = "bigbang/example"
access_token = "X2iTFefU5aWOjg.atlasv1.YaDa"
}
}
```
## Configuration variables
The following configuration options / environment variables are supported:
* `name` - (Required) Full name of the environment (`<username>/<name>`)
* `access_token` / `ATLAS_TOKEN` - (Required) Atlas API token
* `address` - (Optional) Address to alternative Atlas location (Atlas Enterprise endpoint)

View File

@ -1,36 +0,0 @@
---
layout: "remotestate"
page_title: "Remote State Backend: local"
sidebar_current: "docs-state-remote-local"
description: |-
Remote state stored using the local file system.
---
# local
Remote state backend that uses the local file system.
## Example Usage
```
terraform remote config \
-backend=local \
-backend-config="path=/path/to/terraform.tfstate"
```
## Example Reference
```
data "terraform_remote_state" "foo" {
backend = "local"
config {
path = "${path.module}/../../terraform.tfstate"
}
}
```
## Configuration variables
The following configuration options are supported:
* `path` - (Required) The path to the `tfstate` file.

View File

@ -0,0 +1,62 @@
<% wrap_layout :inner do %>
<% content_for :sidebar do %>
<div class="docs-sidebar hidden-print affix-top" role="complementary">
<ul class="nav docs-sidenav">
<li>
<a href="/docs/backends/index.html">&laquo; Backends</a>
</li>
<li<%= sidebar_current(/^docs-backends-types-index/) %>>
<a href="/docs/backends/types/index.html">Backend Types</a>
</li>
<li<%= sidebar_current(/^docs-backends-types-enhanced-/) %>>
<a href="#">Enhanced Backends</a>
<ul class="nav nav-visible">
<li<%= sidebar_current("docs-backends-types-enhanced-local") %>>
<a href="/docs/backends/types/local.html">local</a>
</li>
</ul>
</li>
<li<%= sidebar_current(/^docs-backends-types-standard-/) %>>
<a href="#">Standard Backends</a>
<ul class="nav nav-visible">
<li<%= sidebar_current("docs-backends-types-standard-artifactory") %>>
<a href="/docs/backends/types/artifactory.html">artifactory</a>
</li>
<li<%= sidebar_current("docs-backends-types-standard-atlas") %>>
<a href="/docs/backends/types/atlas.html">atlas</a>
</li>
<li<%= sidebar_current("docs-backends-types-standard-azure") %>>
<a href="/docs/backends/types/azure.html">azure</a>
</li>
<li<%= sidebar_current("docs-backends-types-standard-consul") %>>
<a href="/docs/backends/types/consul.html">consul</a>
</li>
<li<%= sidebar_current("docs-backends-types-standard-etcd") %>>
<a href="/docs/backends/types/etcd.html">etcd</a>
</li>
<li<%= sidebar_current("docs-backends-types-standard-gcs") %>>
<a href="/docs/backends/types/gcs.html">gcs</a>
</li>
<li<%= sidebar_current("docs-backends-types-standard-http") %>>
<a href="/docs/backends/types/http.html">http</a>
</li>
<li<%= sidebar_current("docs-backends-types-standard-manta") %>>
<a href="/docs/backends/types/manta.html">manta</a>
</li>
<li<%= sidebar_current("docs-backends-types-standard-s3") %>>
<a href="/docs/backends/types/s3.html">s3</a>
</li>
<li<%= sidebar_current("docs-backends-types-standard-swift") %>>
<a href="/docs/backends/types/swift.html">swift</a>
</li>
</ul>
</li>
</ul>
</div>
<% end %>
<%= yield %>
<% end %>

View File

@ -25,6 +25,14 @@
<a href="/docs/commands/state/mv.html">mv</a>
</li>
<li<%= sidebar_current("docs-state-sub-pull") %>>
<a href="/docs/commands/state/pull.html">pull</a>
</li>
<li<%= sidebar_current("docs-state-sub-push") %>>
<a href="/docs/commands/state/push.html">push</a>
</li>
<li<%= sidebar_current("docs-state-sub-rm") %>>
<a href="/docs/commands/state/rm.html">rm</a>
</li>

View File

@ -3,146 +3,142 @@
<div class="docs-sidebar hidden-print affix-top" role="complementary">
<ul class="nav docs-sidenav">
<li<%= sidebar_current("docs-home") %>>
<a href="/docs/index.html">Documentation Home</a>
<a href="/docs/index.html">Documentation Home</a>
</li>
<li<%= sidebar_current(/^docs-config/) %>>
<a href="/docs/configuration/index.html">Configuration</a>
<ul class="nav">
<li<%= sidebar_current("docs-config-load") %>>
<a href="/docs/configuration/load.html">Load Order and Semantics</a>
</li>
<a href="/docs/configuration/index.html">Configuration</a>
<ul class="nav">
<li<%= sidebar_current("docs-config-load") %>>
<a href="/docs/configuration/load.html">Load Order and Semantics</a>
</li>
<li<%= sidebar_current("docs-config-syntax") %>>
<a href="/docs/configuration/syntax.html">Configuration Syntax</a>
</li>
<li<%= sidebar_current("docs-config-syntax") %>>
<a href="/docs/configuration/syntax.html">Configuration Syntax</a>
</li>
<li<%= sidebar_current("docs-config-interpolation") %>>
<a href="/docs/configuration/interpolation.html">Interpolation Syntax</a>
</li>
<li<%= sidebar_current("docs-config-interpolation") %>>
<a href="/docs/configuration/interpolation.html">Interpolation Syntax</a>
</li>
<li<%= sidebar_current("docs-config-override") %>>
<a href="/docs/configuration/override.html">Overrides</a>
</li>
<li<%= sidebar_current("docs-config-override") %>>
<a href="/docs/configuration/override.html">Overrides</a>
</li>
<li<%= sidebar_current("docs-config-resources") %>>
<a href="/docs/configuration/resources.html">Resources</a>
</li>
<li<%= sidebar_current("docs-config-resources") %>>
<a href="/docs/configuration/resources.html">Resources</a>
</li>
<li<%= sidebar_current("docs-config-data-sources") %>>
<a href="/docs/configuration/data-sources.html">Data Sources</a>
</li>
<li<%= sidebar_current("docs-config-data-sources") %>>
<a href="/docs/configuration/data-sources.html">Data Sources</a>
</li>
<li<%= sidebar_current("docs-config-providers") %>>
<a href="/docs/configuration/providers.html">Providers</a>
</li>
<li<%= sidebar_current("docs-config-providers") %>>
<a href="/docs/configuration/providers.html">Providers</a>
</li>
<li<%= sidebar_current("docs-config-variables") %>>
<a href="/docs/configuration/variables.html">Variables</a>
</li>
<li<%= sidebar_current("docs-config-variables") %>>
<a href="/docs/configuration/variables.html">Variables</a>
</li>
<li<%= sidebar_current("docs-config-outputs") %>>
<a href="/docs/configuration/outputs.html">Outputs</a>
</li>
<li<%= sidebar_current("docs-config-outputs") %>>
<a href="/docs/configuration/outputs.html">Outputs</a>
</li>
<li<%= sidebar_current("docs-config-modules") %>>
<a href="/docs/configuration/modules.html">Modules</a>
</li>
<li<%= sidebar_current("docs-config-modules") %>>
<a href="/docs/configuration/modules.html">Modules</a>
</li>
<li<%= sidebar_current("docs-config-terraform") %>>
<a href="/docs/configuration/terraform.html">Terraform</a>
</li>
<li<%= sidebar_current("docs-config-terraform") %>>
<a href="/docs/configuration/terraform.html">Terraform</a>
</li>
<li<%= sidebar_current("docs-config-atlas") %>>
<a href="/docs/configuration/atlas.html">Atlas</a>
</li>
<li<%= sidebar_current("docs-config-atlas") %>>
<a href="/docs/configuration/atlas.html">Atlas</a>
</li>
<li<%= sidebar_current("docs-config-environment-variables") %>>
<a href="/docs/configuration/environment-variables.html">Environment Variables</a>
</li>
<li<%= sidebar_current("docs-config-environment-variables") %>>
<a href="/docs/configuration/environment-variables.html">Environment Variables</a>
</li>
</ul>
</ul>
</li>
<li<%= sidebar_current(/^docs-commands/) %>>
<a href="/docs/commands/index.html">Commands (CLI)</a>
<ul class="nav">
<li<%= sidebar_current("docs-commands-apply") %>>
<a href="/docs/commands/apply.html">apply</a>
</li>
<a href="/docs/commands/index.html">Commands (CLI)</a>
<ul class="nav">
<li<%= sidebar_current("docs-commands-apply") %>>
<a href="/docs/commands/apply.html">apply</a>
</li>
<li<%= sidebar_current("docs-commands-console") %>>
<a href="/docs/commands/console.html">console</a>
</li>
<li<%= sidebar_current("docs-commands-console") %>>
<a href="/docs/commands/console.html">console</a>
</li>
<li<%= sidebar_current("docs-commands-destroy") %>>
<a href="/docs/commands/destroy.html">destroy</a>
</li>
<li<%= sidebar_current("docs-commands-destroy") %>>
<a href="/docs/commands/destroy.html">destroy</a>
</li>
<li<%= sidebar_current("docs-commands-fmt") %>>
<a href="/docs/commands/fmt.html">fmt</a>
</li>
<li<%= sidebar_current("docs-commands-fmt") %>>
<a href="/docs/commands/fmt.html">fmt</a>
</li>
<li<%= sidebar_current("docs-commands-force-unlock") %>>
<a href="/docs/commands/force-unlock.html">force-unlock</a>
</li>
<li<%= sidebar_current("docs-commands-force-unlock") %>>
<a href="/docs/commands/force-unlock.html">force-unlock</a>
</li>
<li<%= sidebar_current("docs-commands-get") %>>
<a href="/docs/commands/get.html">get</a>
</li>
<li<%= sidebar_current("docs-commands-get") %>>
<a href="/docs/commands/get.html">get</a>
</li>
<li<%= sidebar_current("docs-commands-graph") %>>
<a href="/docs/commands/graph.html">graph</a>
</li>
<li<%= sidebar_current("docs-commands-graph") %>>
<a href="/docs/commands/graph.html">graph</a>
</li>
<li<%= sidebar_current("docs-commands-import") %>>
<a href="/docs/commands/import.html">import</a>
</li>
<li<%= sidebar_current("docs-commands-import") %>>
<a href="/docs/commands/import.html">import</a>
</li>
<li<%= sidebar_current("docs-commands-init") %>>
<a href="/docs/commands/init.html">init</a>
</li>
<li<%= sidebar_current("docs-commands-init") %>>
<a href="/docs/commands/init.html">init</a>
</li>
<li<%= sidebar_current("docs-commands-output") %>>
<a href="/docs/commands/output.html">output</a>
</li>
<li<%= sidebar_current("docs-commands-output") %>>
<a href="/docs/commands/output.html">output</a>
</li>
<li<%= sidebar_current("docs-commands-plan") %>>
<a href="/docs/commands/plan.html">plan</a>
</li>
<li<%= sidebar_current("docs-commands-plan") %>>
<a href="/docs/commands/plan.html">plan</a>
</li>
<li<%= sidebar_current("docs-commands-push") %>>
<a href="/docs/commands/push.html">push</a>
</li>
<li<%= sidebar_current("docs-commands-push") %>>
<a href="/docs/commands/push.html">push</a>
</li>
<li<%= sidebar_current("docs-commands-refresh") %>>
<a href="/docs/commands/refresh.html">refresh</a>
</li>
<li<%= sidebar_current("docs-commands-refresh") %>>
<a href="/docs/commands/refresh.html">refresh</a>
</li>
<li<%= sidebar_current("docs-commands-remote") %>>
<a href="/docs/commands/remote.html">remote</a>
</li>
<li<%= sidebar_current("docs-commands-show") %>>
<a href="/docs/commands/show.html">show</a>
</li>
<li<%= sidebar_current("docs-commands-show") %>>
<a href="/docs/commands/show.html">show</a>
</li>
<li<%= sidebar_current("docs-commands-state") %>>
<a href="/docs/commands/state/index.html">state</a>
</li>
<li<%= sidebar_current("docs-commands-state") %>>
<a href="/docs/commands/state/index.html">state</a>
</li>
<li<%= sidebar_current("docs-commands-taint") %>>
<a href="/docs/commands/taint.html">taint</a>
</li>
<li<%= sidebar_current("docs-commands-taint") %>>
<a href="/docs/commands/taint.html">taint</a>
</li>
<li<%= sidebar_current("docs-commands-validate") %>>
<a href="/docs/commands/validate.html">validate</a>
</li>
<li<%= sidebar_current("docs-commands-validate") %>>
<a href="/docs/commands/validate.html">validate</a>
</li>
<li<%= sidebar_current("docs-commands-untaint") %>>
<a href="/docs/commands/untaint.html">untaint</a>
</li>
</ul>
<li<%= sidebar_current("docs-commands-untaint") %>>
<a href="/docs/commands/untaint.html">untaint</a>
</li>
</ul>
</li>
<li<%= sidebar_current(/^docs-import/) %>>
@ -169,339 +165,370 @@
<a href="/docs/state/import.html">Import Existing Resources</a>
</li>
<li<%= sidebar_current("docs-state-locking") %>>
<a href="/docs/state/locking.html">Locking</a>
</li>
<li<%= sidebar_current("docs-state-remote") %>>
<a href="/docs/state/remote/index.html">Remote State</a>
<a href="/docs/state/remote.html">Remote State</a>
</li>
</ul>
</li>
<li<%= sidebar_current(/^docs-providers/) %>>
<a href="/docs/providers/index.html">Providers</a>
<ul class="nav">
<li<%= sidebar_current("docs-providers-alicloud") %>>
<a href="/docs/providers/alicloud/index.html">Alicloud</a>
</li>
<a href="/docs/providers/index.html">Providers</a>
<ul class="nav">
<li<%= sidebar_current("docs-providers-alicloud") %>>
<a href="/docs/providers/alicloud/index.html">Alicloud</a>
</li>
<li<%= sidebar_current("docs-providers-archive") %>>
<a href="/docs/providers/archive/index.html">Archive</a>
</li>
<li<%= sidebar_current("docs-providers-archive") %>>
<a href="/docs/providers/archive/index.html">Archive</a>
</li>
<li<%= sidebar_current("docs-providers-arukas") %>>
<a href="/docs/providers/arukas/index.html">Arukas</a>
</li>
<li<%= sidebar_current("docs-providers-arukas") %>>
<a href="/docs/providers/arukas/index.html">Arukas</a>
</li>
<li<%= sidebar_current("docs-providers-atlas") %>>
<a href="/docs/providers/atlas/index.html">Atlas</a>
</li>
<li<%= sidebar_current("docs-providers-atlas") %>>
<a href="/docs/providers/atlas/index.html">Atlas</a>
</li>
<li<%= sidebar_current("docs-providers-aws") %>>
<a href="/docs/providers/aws/index.html">AWS</a>
</li>
<li<%= sidebar_current("docs-providers-aws") %>>
<a href="/docs/providers/aws/index.html">AWS</a>
</li>
<li<%= sidebar_current("docs-providers-bitbucket") %>>
<a href="/docs/providers/bitbucket/index.html">Bitbucket</a>
</li>
<li<%= sidebar_current("docs-providers-bitbucket") %>>
<a href="/docs/providers/bitbucket/index.html">Bitbucket</a>
</li>
<li<%= sidebar_current("docs-providers-clc") %>>
<a href="/docs/providers/clc/index.html">CenturyLinkCloud</a>
</li>
<li<%= sidebar_current("docs-providers-clc") %>>
<a href="/docs/providers/clc/index.html">CenturyLinkCloud</a>
</li>
<li<%= sidebar_current("docs-providers-chef") %>>
<a href="/docs/providers/chef/index.html">Chef</a>
</li>
<li<%= sidebar_current("docs-providers-chef") %>>
<a href="/docs/providers/chef/index.html">Chef</a>
</li>
<li<%= sidebar_current("docs-providers-cloudflare") %>>
<a href="/docs/providers/cloudflare/index.html">CloudFlare</a>
</li>
<li<%= sidebar_current("docs-providers-cloudflare") %>>
<a href="/docs/providers/cloudflare/index.html">CloudFlare</a>
</li>
<li<%= sidebar_current("docs-providers-cloudstack") %>>
<a href="/docs/providers/cloudstack/index.html">CloudStack</a>
</li>
<li<%= sidebar_current("docs-providers-cloudstack") %>>
<a href="/docs/providers/cloudstack/index.html">CloudStack</a>
</li>
<li<%= sidebar_current("docs-providers-cobbler") %>>
<a href="/docs/providers/cobbler/index.html">Cobbler</a>
</li>
<li<%= sidebar_current("docs-providers-cobbler") %>>
<a href="/docs/providers/cobbler/index.html">Cobbler</a>
</li>
<li<%= sidebar_current("docs-providers-consul") %>>
<a href="/docs/providers/consul/index.html">Consul</a>
</li>
<li<%= sidebar_current("docs-providers-consul") %>>
<a href="/docs/providers/consul/index.html">Consul</a>
</li>
<li<%= sidebar_current("docs-providers-datadog") %>>
<a href="/docs/providers/datadog/index.html">Datadog</a>
</li>
<li<%= sidebar_current("docs-providers-datadog") %>>
<a href="/docs/providers/datadog/index.html">Datadog</a>
</li>
<li<%= sidebar_current("docs-providers-do") %>>
<a href="/docs/providers/do/index.html">DigitalOcean</a>
</li>
<li<%= sidebar_current("docs-providers-do") %>>
<a href="/docs/providers/do/index.html">DigitalOcean</a>
</li>
<li<%= sidebar_current("docs-providers-dme") %>>
<a href="/docs/providers/dme/index.html">DNSMadeEasy</a>
</li>
<li<%= sidebar_current("docs-providers-dme") %>>
<a href="/docs/providers/dme/index.html">DNSMadeEasy</a>
</li>
<li<%= sidebar_current("docs-providers-dnsimple") %>>
<a href="/docs/providers/dnsimple/index.html">DNSimple</a>
</li>
<li<%= sidebar_current("docs-providers-dnsimple") %>>
<a href="/docs/providers/dnsimple/index.html">DNSimple</a>
</li>
<li<%= sidebar_current("docs-providers-docker") %>>
<a href="/docs/providers/docker/index.html">Docker</a>
</li>
<li<%= sidebar_current("docs-providers-docker") %>>
<a href="/docs/providers/docker/index.html">Docker</a>
</li>
<li<%= sidebar_current("docs-providers-dyn") %>>
<a href="/docs/providers/dyn/index.html">Dyn</a>
</li>
<li<%= sidebar_current("docs-providers-dyn") %>>
<a href="/docs/providers/dyn/index.html">Dyn</a>
</li>
<li<%= sidebar_current("docs-providers-external") %>>
<a href="/docs/providers/external/index.html">External</a>
</li>
<li<%= sidebar_current("docs-providers-external") %>>
<a href="/docs/providers/external/index.html">External</a>
</li>
<li<%= sidebar_current("docs-providers-fastly") %>>
<a href="/docs/providers/fastly/index.html">Fastly</a>
</li>
<li<%= sidebar_current("docs-providers-fastly") %>>
<a href="/docs/providers/fastly/index.html">Fastly</a>
</li>
<li<%= sidebar_current("docs-providers-github") %>>
<a href="/docs/providers/github/index.html">GitHub</a>
</li>
<li<%= sidebar_current("docs-providers-github") %>>
<a href="/docs/providers/github/index.html">GitHub</a>
</li>
<li<%= sidebar_current("docs-providers-google") %>>
<a href="/docs/providers/google/index.html">Google Cloud</a>
</li>
<li<%= sidebar_current("docs-providers-google") %>>
<a href="/docs/providers/google/index.html">Google Cloud</a>
</li>
<li<%= sidebar_current("docs-providers-grafana") %>>
<a href="/docs/providers/grafana/index.html">Grafana</a>
</li>
<li<%= sidebar_current("docs-providers-grafana") %>>
<a href="/docs/providers/grafana/index.html">Grafana</a>
</li>
<li<%= sidebar_current("docs-providers-heroku") %>>
<a href="/docs/providers/heroku/index.html">Heroku</a>
</li>
<li<%= sidebar_current("docs-providers-heroku") %>>
<a href="/docs/providers/heroku/index.html">Heroku</a>
</li>
<li<%= sidebar_current("docs-providers-icinga2") %>>
<a href="/docs/providers/icinga2/index.html">Icinga2</a>
</li>
<li<%= sidebar_current("docs-providers-icinga2") %>>
<a href="/docs/providers/icinga2/index.html">Icinga2</a>
</li>
<li<%= sidebar_current("docs-providers-ignition") %>>
<a href="/docs/providers/ignition/index.html">Ignition</a>
</li>
<li<%= sidebar_current("docs-providers-ignition") %>>
<a href="/docs/providers/ignition/index.html">Ignition</a>
</li>
<li<%= sidebar_current("docs-providers-influxdb") %>>
<a href="/docs/providers/influxdb/index.html">InfluxDB</a>
</li>
<li<%= sidebar_current("docs-providers-influxdb") %>>
<a href="/docs/providers/influxdb/index.html">InfluxDB</a>
</li>
<li<%= sidebar_current("docs-providers-librato") %>>
<a href="/docs/providers/librato/index.html">Librato</a>
</li>
<li<%= sidebar_current("docs-providers-librato") %>>
<a href="/docs/providers/librato/index.html">Librato</a>
</li>
<li<%= sidebar_current("docs-providers-logentries") %>>
<a href="/docs/providers/logentries/index.html">Logentries</a>
</li>
<li<%= sidebar_current("docs-providers-logentries") %>>
<a href="/docs/providers/logentries/index.html">Logentries</a>
</li>
<li<%= sidebar_current("docs-providers-mailgun") %>>
<a href="/docs/providers/mailgun/index.html">Mailgun</a>
</li>
<li<%= sidebar_current("docs-providers-mailgun") %>>
<a href="/docs/providers/mailgun/index.html">Mailgun</a>
</li>
<li<%= sidebar_current("docs-providers-newrelic") %>>
<a href="/docs/providers/newrelic/index.html">New Relic</a>
</li>
<li<%= sidebar_current("docs-providers-newrelic") %>>
<a href="/docs/providers/newrelic/index.html">New Relic</a>
</li>
<li<%= sidebar_current("docs-providers-nomad") %>>
<a href="/docs/providers/nomad/index.html">Nomad</a>
</li>
<li<%= sidebar_current("docs-providers-nomad") %>>
<a href="/docs/providers/nomad/index.html">Nomad</a>
</li>
<li<%= sidebar_current("docs-providers-ns1") %>>
<a href="/docs/providers/ns1/index.html">NS1</a>
</li>
<li<%= sidebar_current("docs-providers-ns1") %>>
<a href="/docs/providers/ns1/index.html">NS1</a>
</li>
<li<%= sidebar_current("docs-providers-azurerm") %>>
<a href="/docs/providers/azurerm/index.html">Microsoft Azure</a>
</li>
<li<%= sidebar_current("docs-providers-azurerm") %>>
<a href="/docs/providers/azurerm/index.html">Microsoft Azure</a>
</li>
<li<%= sidebar_current("docs-providers-azurerm") %>>
<a href="/docs/providers/azure/index.html">Microsoft Azure (Legacy ASM)</a>
</li>
<li<%= sidebar_current("docs-providers-azurerm") %>>
<a href="/docs/providers/azure/index.html">Microsoft Azure (Legacy ASM)</a>
</li>
<li<%= sidebar_current("docs-providers-mysql") %>>
<a href="/docs/providers/mysql/index.html">MySQL</a>
</li>
<li<%= sidebar_current("docs-providers-mysql") %>>
<a href="/docs/providers/mysql/index.html">MySQL</a>
</li>
<li<%= sidebar_current("docs-providers-openstack") %>>
<a href="/docs/providers/openstack/index.html">OpenStack</a>
</li>
<li<%= sidebar_current("docs-providers-openstack") %>>
<a href="/docs/providers/openstack/index.html">OpenStack</a>
</li>
<li<%= sidebar_current("docs-providers-opsgenie") %>>
<a href="/docs/providers/opsgenie/index.html">OpsGenie</a>
</li>
<li<%= sidebar_current("docs-providers-opsgenie") %>>
<a href="/docs/providers/opsgenie/index.html">OpsGenie</a>
</li>
<li<%= sidebar_current("docs-providers-packet") %>>
<a href="/docs/providers/packet/index.html">Packet</a>
</li>
<li<%= sidebar_current("docs-providers-packet") %>>
<a href="/docs/providers/packet/index.html">Packet</a>
</li>
<li<%= sidebar_current("docs-providers-pagerduty") %>>
<a href="/docs/providers/pagerduty/index.html">PagerDuty</a>
</li>
<li<%= sidebar_current("docs-providers-pagerduty") %>>
<a href="/docs/providers/pagerduty/index.html">PagerDuty</a>
</li>
<li<%= sidebar_current("docs-providers-postgresql") %>>
<a href="/docs/providers/postgresql/index.html">PostgreSQL</a>
</li>
<li<%= sidebar_current("docs-providers-postgresql") %>>
<a href="/docs/providers/postgresql/index.html">PostgreSQL</a>
</li>
<li<%= sidebar_current("docs-providers-powerdns") %>>
<a href="/docs/providers/powerdns/index.html">PowerDNS</a>
</li>
<li<%= sidebar_current("docs-providers-powerdns") %>>
<a href="/docs/providers/powerdns/index.html">PowerDNS</a>
</li>
<li<%= sidebar_current("docs-providers-profitbricks") %>>
<a href="/docs/providers/profitbricks/index.html">ProfitBricks</a>
</li>
<li<%= sidebar_current("docs-providers-profitbricks") %>>
<a href="/docs/providers/profitbricks/index.html">ProfitBricks</a>
</li>
<li<%= sidebar_current("docs-providers-rabbitmq") %>>
<a href="/docs/providers/rabbitmq/index.html">RabbitMQ</a>
</li>
<li<%= sidebar_current("docs-providers-rabbitmq") %>>
<a href="/docs/providers/rabbitmq/index.html">RabbitMQ</a>
</li>
<li<%= sidebar_current("docs-providers-rancher") %>>
<a href="/docs/providers/rancher/index.html">Rancher</a>
</li>
<li<%= sidebar_current("docs-providers-rancher") %>>
<a href="/docs/providers/rancher/index.html">Rancher</a>
</li>
<li<%= sidebar_current("docs-providers-random") %>>
<a href="/docs/providers/random/index.html">Random</a>
</li>
<li<%= sidebar_current("docs-providers-random") %>>
<a href="/docs/providers/random/index.html">Random</a>
</li>
<li<%= sidebar_current("docs-providers-rundeck") %>>
<a href="/docs/providers/rundeck/index.html">Rundeck</a>
</li>
<li<%= sidebar_current("docs-providers-rundeck") %>>
<a href="/docs/providers/rundeck/index.html">Rundeck</a>
</li>
<li<%= sidebar_current("docs-providers-scaleway") %>>
<a href="/docs/providers/scaleway/index.html">Scaleway</a>
</li>
<li<%= sidebar_current("docs-providers-scaleway") %>>
<a href="/docs/providers/scaleway/index.html">Scaleway</a>
</li>
<li<%= sidebar_current("docs-providers-softlayer") %>>
<a href="/docs/providers/softlayer/index.html">SoftLayer</a>
</li>
<li<%= sidebar_current("docs-providers-softlayer") %>>
<a href="/docs/providers/softlayer/index.html">SoftLayer</a>
</li>
<li<%= sidebar_current("docs-providers-statuscake") %>>
<a href="/docs/providers/statuscake/index.html">StatusCake</a>
</li>
<li<%= sidebar_current("docs-providers-statuscake") %>>
<a href="/docs/providers/statuscake/index.html">StatusCake</a>
</li>
<li<%= sidebar_current("docs-providers-template") %>>
<a href="/docs/providers/template/index.html">Template</a>
</li>
<li<%= sidebar_current("docs-providers-template") %>>
<a href="/docs/providers/template/index.html">Template</a>
</li>
<li<%= sidebar_current("docs-providers-terraform") %>>
<a href="/docs/providers/terraform/index.html">Terraform</a>
</li>
<li<%= sidebar_current("docs-providers-terraform") %>>
<a href="/docs/providers/terraform/index.html">Terraform</a>
</li>
<li<%= sidebar_current("docs-providers-tls") %>>
<a href="/docs/providers/tls/index.html">TLS</a>
</li>
<li<%= sidebar_current("docs-providers-tls") %>>
<a href="/docs/providers/tls/index.html">TLS</a>
</li>
<li<%= sidebar_current("docs-providers-triton") %>>
<a href="/docs/providers/triton/index.html">Triton</a>
</li>
<li<%= sidebar_current("docs-providers-triton") %>>
<a href="/docs/providers/triton/index.html">Triton</a>
</li>
<li<%= sidebar_current("docs-providers-ultradns") %>>
<a href="/docs/providers/ultradns/index.html">UltraDNS</a>
</li>
<li<%= sidebar_current("docs-providers-ultradns") %>>
<a href="/docs/providers/ultradns/index.html">UltraDNS</a>
</li>
<li<%= sidebar_current("docs-providers-vault") %>>
<a href="/docs/providers/vault/index.html">Vault</a>
</li>
<li<%= sidebar_current("docs-providers-vault") %>>
<a href="/docs/providers/vault/index.html">Vault</a>
</li>
<li<%= sidebar_current("docs-providers-vcd") %>>
<a href="/docs/providers/vcd/index.html">VMware vCloud Director</a>
</li>
<li<%= sidebar_current("docs-providers-vcd") %>>
<a href="/docs/providers/vcd/index.html">VMware vCloud Director</a>
</li>
<li<%= sidebar_current("docs-providers-vsphere") %>>
<a href="/docs/providers/vsphere/index.html">VMware vSphere</a>
</li>
</ul>
<li<%= sidebar_current("docs-providers-vsphere") %>>
<a href="/docs/providers/vsphere/index.html">VMware vSphere</a>
</li>
</ul>
</li>
<li<%= sidebar_current(/^docs-provisioners/) %>>
<a href="/docs/provisioners/index.html">Provisioners</a>
<ul class="nav">
<li<%= sidebar_current("docs-provisioners-chef") %>>
<a href="/docs/provisioners/chef.html">chef</a>
</li>
<a href="/docs/provisioners/index.html">Provisioners</a>
<ul class="nav">
<li<%= sidebar_current("docs-provisioners-chef") %>>
<a href="/docs/provisioners/chef.html">chef</a>
</li>
<li<%= sidebar_current("docs-provisioners-connection") %>>
<a href="/docs/provisioners/connection.html">connection</a>
</li>
<li<%= sidebar_current("docs-provisioners-connection") %>>
<a href="/docs/provisioners/connection.html">connection</a>
</li>
<li<%= sidebar_current("docs-provisioners-file") %>>
<a href="/docs/provisioners/file.html">file</a>
</li>
<li<%= sidebar_current("docs-provisioners-file") %>>
<a href="/docs/provisioners/file.html">file</a>
</li>
<li<%= sidebar_current("docs-provisioners-local") %>>
<a href="/docs/provisioners/local-exec.html">local-exec</a>
</li>
<li<%= sidebar_current("docs-provisioners-local") %>>
<a href="/docs/provisioners/local-exec.html">local-exec</a>
</li>
<li<%= sidebar_current("docs-provisioners-remote") %>>
<a href="/docs/provisioners/remote-exec.html">remote-exec</a>
</li>
<li<%= sidebar_current("docs-provisioners-remote") %>>
<a href="/docs/provisioners/remote-exec.html">remote-exec</a>
</li>
<li<%= sidebar_current("docs-provisioners-null-resource") %>>
<a href="/docs/provisioners/null_resource.html">null_resource</a>
</li>
</ul>
<li<%= sidebar_current("docs-provisioners-null-resource") %>>
<a href="/docs/provisioners/null_resource.html">null_resource</a>
</li>
</ul>
</li>
<li<%= sidebar_current(/^docs-modules/) %>>
<a href="/docs/modules/index.html">Modules</a>
<ul class="nav">
<li<%= sidebar_current("docs-modules-usage") %>>
<a href="/docs/modules/usage.html">Usage</a>
</li>
<a href="/docs/modules/index.html">Modules</a>
<ul class="nav">
<li<%= sidebar_current("docs-modules-usage") %>>
<a href="/docs/modules/usage.html">Usage</a>
</li>
<li<%= sidebar_current("docs-modules-sources") %>>
<a href="/docs/modules/sources.html">Sources</a>
</li>
<li<%= sidebar_current("docs-modules-sources") %>>
<a href="/docs/modules/sources.html">Sources</a>
</li>
<li<%= sidebar_current("docs-modules-create") %>>
<a href="/docs/modules/create.html">Creating Modules</a>
</li>
</ul>
<li<%= sidebar_current("docs-modules-create") %>>
<a href="/docs/modules/create.html">Creating Modules</a>
</li>
</ul>
</li>
<li<%= sidebar_current(/^docs-backends/) %>>
<a href="/docs/backends/index.html">Backends</a>
<ul class="nav">
<li<%= sidebar_current("docs-backends-init") %>>
<a href="/docs/backends/init.html">Init</a>
</li>
<li<%= sidebar_current("docs-backends-config") %>>
<a href="/docs/backends/config.html">Configuration</a>
</li>
<li<%= sidebar_current("docs-backends-state") %>>
<a href="/docs/backends/state.html">State Storage & Locking</a>
</li>
<li<%= sidebar_current("docs-backends-types") %>>
<a href="/docs/backends/types/index.html">Backend Types</a>
</li>
<!--
<li<%= sidebar_current("docs-backends-ops") %>>
<a href="/docs/backends/operations.html">Operations</a>
</li>
-->
</ul>
</li>
<li<%= sidebar_current(/^docs-plugins/) %>>
<a href="/docs/plugins/index.html">Plugins</a>
<ul class="nav">
<li<%= sidebar_current("docs-plugins-basics") %>>
<a href="/docs/plugins/basics.html">Basics</a>
</li>
<a href="/docs/plugins/index.html">Plugins</a>
<ul class="nav">
<li<%= sidebar_current("docs-plugins-basics") %>>
<a href="/docs/plugins/basics.html">Basics</a>
</li>
<li<%= sidebar_current("docs-plugins-provider") %>>
<a href="/docs/plugins/provider.html">Provider</a>
</li>
<li<%= sidebar_current("docs-plugins-provider") %>>
<a href="/docs/plugins/provider.html">Provider</a>
</li>
<li<%= sidebar_current("docs-internals-plugins") %>>
<a href="/docs/internals/internal-plugins.html">Internals</a>
</li>
</ul>
<li<%= sidebar_current("docs-internals-plugins") %>>
<a href="/docs/internals/internal-plugins.html">Internals</a>
</li>
</ul>
</li>
<li<%= sidebar_current(/^docs-internals/) %>>
<a href="/docs/internals/index.html">Internals</a>
<ul class="nav">
<li<%= sidebar_current("docs-internals-debug") %>>
<a href="/docs/internals/debugging.html">Debugging Terraform</a>
</li>
<a href="/docs/internals/index.html">Internals</a>
<ul class="nav">
<li<%= sidebar_current("docs-internals-debug") %>>
<a href="/docs/internals/debugging.html">Debugging Terraform</a>
</li>
<li<%= sidebar_current("docs-internals-graph") %>>
<a href="/docs/internals/graph.html">Resource Graph</a>
</li>
<li<%= sidebar_current("docs-internals-graph") %>>
<a href="/docs/internals/graph.html">Resource Graph</a>
</li>
<li<%= sidebar_current("docs-internals-lifecycle") %>>
<a href="/docs/internals/lifecycle.html">Resource Lifecycle</a>
</li>
<li<%= sidebar_current("docs-internals-lifecycle") %>>
<a href="/docs/internals/lifecycle.html">Resource Lifecycle</a>
</li>
<li<%= sidebar_current("docs-internals-resource-addressing") %>>
<a href="/docs/internals/resource-addressing.html">Resource Addressing</a>
</li>
<li<%= sidebar_current("docs-internals-resource-addressing") %>>
<a href="/docs/internals/resource-addressing.html">Resource Addressing</a>
</li>
<li<%= sidebar_current("docs-internals-plugins") %>>
<a href="/docs/internals/internal-plugins.html">Internal Plugins</a>
</li>
</ul>
<li<%= sidebar_current("docs-internals-plugins") %>>
<a href="/docs/internals/internal-plugins.html">Internal Plugins</a>
</li>
</ul>
</li>
</ul>
</div>
<% end %>
<%= yield %>
<% end %>
<%= yield %>
<% end %>

View File

@ -9,6 +9,9 @@
<li<%= sidebar_current(/^upgrade-guides/) %>>
<a href="/upgrade-guides/index.html">Upgrade Guides</a>
<ul class="nav">
<li<%= sidebar_current("upgrade-guides-0-9") %>>
<a href="/upgrade-guides/0-9.html">Upgrading to v0.9</a>
</li>
<li<%= sidebar_current("upgrade-guides-0-8") %>>
<a href="/upgrade-guides/0-8.html">Upgrading to v0.8</a>
</li>

View File

@ -0,0 +1,74 @@
---
layout: "downloads"
page_title: "Upgrading to Terraform 0.9"
sidebar_current: "upgrade-guides-0-9"
description: |-
Upgrading to Terraform v0.9
---
# Upgrading to Terraform v0.9
Terraform v0.9 is a major release and thus includes some changes that
you'll need to consider when upgrading. This guide is meant to help with
that process.
The goal of this guide is to cover the most common upgrade concerns and
issues that would benefit from more explanation and background. The exhaustive
list of changes will always be the
[Terraform Changelog](https://github.com/hashicorp/terraform/blob/master/CHANGELOG.md).
After reviewing this guide, we recommend reviewing the Changelog to check on
specific notes about the resources and providers you use.
## Remote State
Remote state has been overhauled to be easier and safer to configure and use.
**The new changes are backwards compatible** with existing remote state and
you'll be prompted to migrate to the new remote backend system.
For extra safety when upgrading, you may backup your existing remote state
by running `terraform remote pull` with 0.8.x and saving your
`.terraform/terraform.tfstate` file somewhere safe. You must do this prior
to upgrading to Terraform 0.9.
The only non-backwards compatible change is in the CLI: the existing
`terraform remote config` command is now gone. Remote state is now configured
via the "backend" section within the Terraform configuration itself.
**Example configuring a Consul remote backend:**
```
terraform {
backend "consul" {
address = "demo.consul.io"
datacenter = "nyc3"
path = "tfdemo"
}
}
```
**Action:** Run `terraform init` to migrate your existing remote state.
Update any scripts or guides that may have used `terraform remote config`
to use the new file-based configuration.
## State Locking
Terraform 0.9 now will acquire a lock for your state if your backend
supports it. **This change is backwards compatible**, but may require
enhanced permissions for the authentication used with your backend.
Backends that support locking as of the 0.9.0 release are: local files,
Amazon S3, HashiCorp Consul, and Terraform Enterprise (atlas). If you don't
use these backends, you can ignore this section.
Specific notes for each affected backend:
* **Amazon S3**: DynamoDB is used for locking. The AWS access keys
must have access to Dynamo. You may disable locking by specifying
`lock = false` in your backend configuration.
* **HashiCorp Consul**: Sessions are used for locking. If an auth token
is used it must have permissions to create and destroy sessions. You
may disable locking by specifying `lock = false` in your backend
configuration.
**Action:** Update your credentials or configuration if necessary.