Merge pull request #11976 from hashicorp/b-0-9-website
0.9 Website Content (Backends, Locking, etc.)
This commit is contained in:
commit
7e14184393
|
@ -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,
|
||||
|
|
|
@ -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.
|
|
@ -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.
|
|
@ -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.
|
|
@ -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!
|
|
@ -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).
|
|
@ -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
|
|
@ -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)
|
|
@ -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
|
||||
|
|
@ -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
|
||||
|
||||
```
|
|
@ -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
|
|
@ -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
|
|
@ -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
|
|
@ -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.
|
|
@ -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.
|
|
@ -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
|
||||
|
||||
```
|
|
@ -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
|
||||
|
|
@ -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
|
||||
|
||||
```
|
|
@ -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"
|
||||
```
|
||||
|
|
|
@ -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"
|
||||
```
|
|
@ -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.
|
||||
|
|
@ -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.
|
||||
|
|
@ -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).
|
|
@ -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.
|
|
@ -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.
|
|
@ -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.
|
|
@ -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.
|
|
@ -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)
|
|
@ -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.
|
|
@ -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">« 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 %>
|
|
@ -24,7 +24,15 @@
|
|||
<li<%= sidebar_current("docs-state-sub-mv") %>>
|
||||
<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>
|
||||
|
|
|
@ -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-powerdns") %>>
|
||||
<a href="/docs/providers/powerdns/index.html">PowerDNS</a>
|
||||
</li>
|
||||
<li<%= sidebar_current("docs-providers-postgresql") %>>
|
||||
<a href="/docs/providers/postgresql/index.html">PostgreSQL</a>
|
||||
</li>
|
||||
|
||||
<li<%= sidebar_current("docs-providers-profitbricks") %>>
|
||||
<a href="/docs/providers/profitbricks/index.html">ProfitBricks</a>
|
||||
</li>
|
||||
<li<%= sidebar_current("docs-providers-powerdns") %>>
|
||||
<a href="/docs/providers/powerdns/index.html">PowerDNS</a>
|
||||
</li>
|
||||
|
||||
<li<%= sidebar_current("docs-providers-rabbitmq") %>>
|
||||
<a href="/docs/providers/rabbitmq/index.html">RabbitMQ</a>
|
||||
</li>
|
||||
<li<%= sidebar_current("docs-providers-profitbricks") %>>
|
||||
<a href="/docs/providers/profitbricks/index.html">ProfitBricks</a>
|
||||
</li>
|
||||
|
||||
<li<%= sidebar_current("docs-providers-rancher") %>>
|
||||
<a href="/docs/providers/rancher/index.html">Rancher</a>
|
||||
</li>
|
||||
<li<%= sidebar_current("docs-providers-rabbitmq") %>>
|
||||
<a href="/docs/providers/rabbitmq/index.html">RabbitMQ</a>
|
||||
</li>
|
||||
|
||||
<li<%= sidebar_current("docs-providers-random") %>>
|
||||
<a href="/docs/providers/random/index.html">Random</a>
|
||||
</li>
|
||||
<li<%= sidebar_current("docs-providers-rancher") %>>
|
||||
<a href="/docs/providers/rancher/index.html">Rancher</a>
|
||||
</li>
|
||||
|
||||
<li<%= sidebar_current("docs-providers-rundeck") %>>
|
||||
<a href="/docs/providers/rundeck/index.html">Rundeck</a>
|
||||
</li>
|
||||
<li<%= sidebar_current("docs-providers-random") %>>
|
||||
<a href="/docs/providers/random/index.html">Random</a>
|
||||
</li>
|
||||
|
||||
<li<%= sidebar_current("docs-providers-scaleway") %>>
|
||||
<a href="/docs/providers/scaleway/index.html">Scaleway</a>
|
||||
</li>
|
||||
<li<%= sidebar_current("docs-providers-rundeck") %>>
|
||||
<a href="/docs/providers/rundeck/index.html">Rundeck</a>
|
||||
</li>
|
||||
|
||||
<li<%= sidebar_current("docs-providers-softlayer") %>>
|
||||
<a href="/docs/providers/softlayer/index.html">SoftLayer</a>
|
||||
</li>
|
||||
<li<%= sidebar_current("docs-providers-scaleway") %>>
|
||||
<a href="/docs/providers/scaleway/index.html">Scaleway</a>
|
||||
</li>
|
||||
|
||||
<li<%= sidebar_current("docs-providers-statuscake") %>>
|
||||
<a href="/docs/providers/statuscake/index.html">StatusCake</a>
|
||||
</li>
|
||||
<li<%= sidebar_current("docs-providers-softlayer") %>>
|
||||
<a href="/docs/providers/softlayer/index.html">SoftLayer</a>
|
||||
</li>
|
||||
|
||||
<li<%= sidebar_current("docs-providers-template") %>>
|
||||
<a href="/docs/providers/template/index.html">Template</a>
|
||||
</li>
|
||||
<li<%= sidebar_current("docs-providers-statuscake") %>>
|
||||
<a href="/docs/providers/statuscake/index.html">StatusCake</a>
|
||||
</li>
|
||||
|
||||
<li<%= sidebar_current("docs-providers-terraform") %>>
|
||||
<a href="/docs/providers/terraform/index.html">Terraform</a>
|
||||
</li>
|
||||
<li<%= sidebar_current("docs-providers-template") %>>
|
||||
<a href="/docs/providers/template/index.html">Template</a>
|
||||
</li>
|
||||
|
||||
<li<%= sidebar_current("docs-providers-tls") %>>
|
||||
<a href="/docs/providers/tls/index.html">TLS</a>
|
||||
</li>
|
||||
<li<%= sidebar_current("docs-providers-terraform") %>>
|
||||
<a href="/docs/providers/terraform/index.html">Terraform</a>
|
||||
</li>
|
||||
|
||||
<li<%= sidebar_current("docs-providers-triton") %>>
|
||||
<a href="/docs/providers/triton/index.html">Triton</a>
|
||||
</li>
|
||||
<li<%= sidebar_current("docs-providers-tls") %>>
|
||||
<a href="/docs/providers/tls/index.html">TLS</a>
|
||||
</li>
|
||||
|
||||
<li<%= sidebar_current("docs-providers-ultradns") %>>
|
||||
<a href="/docs/providers/ultradns/index.html">UltraDNS</a>
|
||||
</li>
|
||||
<li<%= sidebar_current("docs-providers-triton") %>>
|
||||
<a href="/docs/providers/triton/index.html">Triton</a>
|
||||
</li>
|
||||
|
||||
<li<%= sidebar_current("docs-providers-vault") %>>
|
||||
<a href="/docs/providers/vault/index.html">Vault</a>
|
||||
</li>
|
||||
<li<%= sidebar_current("docs-providers-ultradns") %>>
|
||||
<a href="/docs/providers/ultradns/index.html">UltraDNS</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-vault") %>>
|
||||
<a href="/docs/providers/vault/index.html">Vault</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-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>
|
||||
|
||||
<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 %>
|
||||
|
|
|
@ -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>
|
||||
|
|
|
@ -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.
|
Loading…
Reference in New Issue