Apply suggestions from code review

Co-authored-by: Laura Pacilio <83350965+laurapacilio@users.noreply.github.com>
This commit is contained in:
Judith Malnick 2021-12-08 09:43:18 -08:00 committed by GitHub
parent 099c7269e4
commit f514f8eb30
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
9 changed files with 36 additions and 62 deletions

View File

@ -10,18 +10,17 @@ When your configuration includes a `cloud` block, commands that
make local modifications to Terraform state and then push them back up to the remote workspace
accept the following option to modify that behavior:
* `-ignore-remote-version` - Override checking that the local and remote
- `-ignore-remote-version` - Override checking that the local and remote
Terraform versions agree, making an operation proceed even when there is
a mismatch.
Normally state-modification operations require using a local version of
State-modification operations usually require using a local version of the
Terraform CLI that is compatible with the Terraform version selected
for the remote workspace as part of its settings. This is to avoid the
local operation creating a new state snapshot that the workspace's
remote execution environment would then be unable to decode.
in the remote workspace settings. This prevents the
local operation from creating a new state snapshot that the workspace's
remote execution environment cannot decode.
Overriding this check can result in a Terraform Cloud workspace that is no
longer able to complete remote operations with the currently selected
version of Terraform, so we recommend against using this option unless
absolutely necessary.
We recommend against using this option unless absolutely necessary. Overriding this check can result
in a Terraform Cloud workspace that is no longer able to complete remote operations with the currently
selected version of Terraform.

View File

@ -12,15 +12,9 @@ Using Terraform Cloud through the command line is called the [CLI-driven run wor
Workspaces can also be configured for local execution, in which case only state is stored in
Terraform Cloud. In this mode, Terraform Cloud behaves just like a standard state backend.
-> **Note:** The Cloud integration for Terraform was added in Terraform 1.1.0; for previous
versions, see the [remote backend documentation](/docs/language/settings/backends/remote.html). See
also: [Migrating from the remote
backend](/docs/cli/cloud/migrating.html)
-> **Note:** The CLI integration is available in Terraform 1.1.0 and later, and Terraform Enterprise 202201-1 and later. Previous versions can use the [`remote` backend](/docs/language/settings/backends/remote.html). Refer to [Migrating from the remote
backend](/docs/cli/cloud/migrating.html) for details about switching to the CLI integration.
-> **Note:** This integration supports Terraform Enterprise as well. Throughout all the
documentation, the platform will be referred to as Terraform Cloud, with any Terraform
Enterprise-specific details explicitly stated. The minimum required version of Terraform Enterprise
is 202201-1.
## Documentation Summary

View File

@ -5,7 +5,7 @@ page_title: "Initializing and Migrating to Terraform Cloud - Terraform CLI"
# Initializing and Migrating
After [configuring Terraform Cloud settings](/docs/cli/cloud/settings.html) for a working directory, you must run `terraform init` to finish setting up. When running this command, Terraform may guide you through an interactive process where you may choose whether or not you'd like to migrate state from any existing workspaces.
After [configuring Terraform Cloud settings](/docs/cli/cloud/settings.html) for a working directory, you must run `terraform init` to finish setting up. When running this command, Terraform may guide you through an interactive process where you may choose whether or not to migrate state from any existing workspaces.
There are three potential scenarios:
@ -47,7 +47,7 @@ When switching from the `remote` backend to a `cloud` block, Terraform will cont
set of Terraform Cloud workspaces. Replace your `backend "remote"` block with an equivalent `cloud`
block:
- If you were using a single workspace via the `name` argument, change the block
- If you were using a single workspace with the `name` argument, change the block
label to `cloud`.
```diff
@ -68,8 +68,7 @@ block:
distinguish the workspaces for your working directory, but a good starting point may be to use
whatever the prefix was before.
The existing workspaces don't need to already have these tags — when you
initialize, Terraform will add the specified tags to them.
The tags you configure do not need to be present on the existing workspaces. When you initialize, Terraform will add the specified tags to the workspaces if necessary.
```diff
terraform {

View File

@ -43,7 +43,7 @@ The `cloud` block has some special restrictions:
- A configuration can only provide one `cloud` block.
- A `cloud` block cannot be used with [state backends](/docs/language/settings/backends/index.html).
A configuration can use one or the other, but not both.
- A cloud block cannot refer to named values (like input variables, locals, or
- A `cloud` block cannot refer to named values (like input variables, locals, or
data source attributes).
The `cloud` block only affects Terraform CLI's behavior. When Terraform Cloud uses a configuration
@ -54,10 +54,10 @@ directly - it ignores the block and behaves according to its own workspace setti
The `cloud` block supports the following configuration arguments:
* `organization` - (Required) The name of the organization containing the
- `organization` - (Required) The name of the organization containing the
workspace(s) the current configuration should use.
* `workspaces` - (Required) A nested block that specifies which remote Terraform Cloud workspaces to
- `workspaces` - (Required) A nested block that specifies which remote Terraform Cloud workspaces to
use for the current configuration. The `workspaces` block must contain **exactly one** of the
following arguments, each denoting a strategy for how workspaces should be mapped:
@ -67,7 +67,7 @@ following arguments, each denoting a strategy for how workspaces should be mappe
to switch between them or create new workspaces; new workspaces will automatically have
the specified tags. This option conflicts with `name`.
* `name` - (Optional) The name of a single Terraform Cloud workspace. You will
- `name` - (Optional) The name of a single Terraform Cloud workspace. You will
only be able to use the workspace specified in the configuration with this working
directory, and cannot manage workspaces from the CLI (e.g. `terraform workspace select` or
`terraform workspace new`). This option conflicts with `tags`.
@ -75,7 +75,7 @@ following arguments, each denoting a strategy for how workspaces should be mappe
* `hostname` - (Optional) The hostname of a Terraform Enterprise installation, if using Terraform
Enterprise. Defaults to Terraform Cloud (app.terraform.io).
* `token` - (Optional) The token used to authenticate with Terraform Cloud.
- `token` - (Optional) The token used to authenticate with Terraform Cloud.
We recommend omitting the token from the configuration, and instead using
[`terraform login`](/docs/cli/commands/login.html) or manually configuring
`credentials` in the
@ -89,15 +89,14 @@ paths to exclude from upload by adding a `.terraformignore` file at the root of
configuration directory. If this file is not present, the upload will exclude
the following by default:
* `.git/` directories
* `.terraform/` directories (exclusive of `.terraform/modules`)
- `.git/` directories
- `.terraform/` directories (exclusive of `.terraform/modules`)
The rules in `.terraformignore` file resemble the rules allowed in a
[.gitignore file](https://git-scm.com/book/en/v2/Git-Basics-Recording-Changes-to-the-Repository#_ignoring):
* Comments (starting with `#`) or blank lines are ignored.
* End a pattern with a forward slash `/` to specify a directory.
* Negate a pattern by starting it with an exclamation point `!`.
- Comments (starting with `#`) or blank lines are ignored.
- End a pattern with a forward slash `/` to specify a directory.
- Negate a pattern by starting it with an exclamation point `!`.
Note that unlike `.gitignore`, only the `.terraformignore` at the root of the configuration
directory is considered.
-> **Note:** Unlike `.gitignore`, only the `.terraformignore` at the root of the configuration directory is considered.

View File

@ -11,7 +11,7 @@ description: |-
Stores the state as a Blob with the given Key within the Blob Container within [the Blob Storage Account](https://docs.microsoft.com/en-us/azure/storage/common/storage-introduction).
This backend supports state locking and consistency checking via native capabilities of Azure Blob Storage.
This backend supports state locking and consistency checking with Azure Blob Storage native capabilities.
-> **Note:** By default the Azure Backend uses ADAL for authentication which is deprecated in favour of MSAL - MSAL can be used by setting `use_microsoft_graph` to `true`. **The default for this will change in Terraform 1.2**, so that MSAL authentication is used by default.

View File

@ -8,11 +8,8 @@ page_title: "Backend Configuration - Configuration Language"
Each Terraform configuration can specify a backend, which defines where
[state](/docs/language/state/index.html) snapshots are stored.
Backend configuration is not needed when using Terraform Cloud, because
Terraform Cloud automatically manages state in the workspaces your configuration
is associated with. If your configuration includes
[a `cloud` block](/docs/language/settings/terraform-cloud.html),
it cannot include a `backend` block.
You do not need to configure a backend when using Terraform Cloud because
Terraform Cloud automatically manages state in the workspaces associated with your configuration. If your configuration includes [a `cloud` block](/docs/language/settings/terraform-cloud.html), it cannot include a `backend` block.
Most non-trivial Terraform configurations store state remotely so that multiple
people can work with the same infrastructure.

View File

@ -12,14 +12,8 @@ description: |-
[`cloud` integration](/docs/language/settings/terraform-cloud.html) instead of this backend.
The `cloud` option includes an improved user experience and more features.
-> **Note:** This backend is unique among all other Terraform backends in that it has the ability to
execute operations for Terraform Cloud's [CLI-driven run workflow](/docs/cloud/run/cli.html), rather
than only store state snapshots. (The documentation used to refer to this as "enhanced" backend
behavior, but it's simpler to describe it as a quirk of the `remote` backend.)
The remote backend is unique among all other Terraform backends because it can both store state snapshots and execute operations for Terraform Cloud's [CLI-driven run workflow](/docs/cloud/run/cli.html). It used to be called an "enhanced" backend.
-> **Note:** The remote backend requires Terraform v0.11.13 or newer, and requires either a
Terraform Cloud account on [app.terraform.io](https://app.terraform.io) or a Terraform Enterprise
instance (version v201809-1 or newer).
When using full remote operations, operations like `terraform plan` or `terraform apply` can be executed in Terraform

View File

@ -34,12 +34,10 @@ following sections.
The nested `cloud` block configures Terraform Cloud for enabling its
[CLI-driven run workflow](/docs/cloud/run/cli.html).
- For a summary of the `cloud` block's syntax, see
[Terraform Cloud Configuration](/docs/language/settings/terraform-cloud.html).
- Refer to [Terraform Cloud Configuration](/docs/language/settings/terraform-cloud.html) for a summary of the `cloud` block's syntax.
- For more complete details about configuring and using Terraform Cloud with Terraform CLI,
see [Using Terraform Cloud](/docs/cli/cloud/index.html) in the
Terraform CLI documentation.
- Refer to [Using Terraform Cloud](/docs/cli/cloud/index.html) in the
Terraform CLI documentation for complete details about how to initialize and configure the Terraform Cloud CLI integration.
## Configuring a Terraform Backend

View File

@ -8,11 +8,10 @@ description: "The nested `cloud` block configures Terraform's integration with T
# Terraform Cloud Configuration
The main module of a Terraform configuration can integrate with Terraform Cloud to enable its
[CLI-driven run workflow](/docs/cloud/run/cli.html). These settings are only needed when
using Terraform CLI to interact with Terraform Cloud, and are ignored when interacting with
Terraform Cloud via version control or the API.
[CLI-driven run workflow](/docs/cloud/run/cli.html). You only need to configure these settings when you want to use Terraform CLI to interact with Terraform Cloud. Terraform Cloud ignores them when interacting with
Terraform through version control or the API.
Terraform Cloud is configured with a nested `cloud` block within the top-level
You can configure the Terraform Cloud CLI integration by adding a nested `cloud` block within the top-level
`terraform` block:
```hcl
@ -27,11 +26,6 @@ terraform {
}
```
Using the Cloud integration is mutually exclusive of declaring any [state backend](/docs/language/settings/backends/index.html); that is, a configuration
can only declare one or the other. Similar to backends...
You cannot use the CLI integration and a [state backend](/docs/language/settings/backends/index.html) in the same configuration; the are mutually exclusive. A configuration can only provide one `cloud` block and the `cloud` block cannot refer to named values like input variables, locals, or data source attributes.
- A configuration can only provide one cloud block.
- A cloud block cannot refer to named values (like input variables, locals, or data source attributes).
See [Using Terraform Cloud](/docs/cli/cloud/index.html)
in the Terraform CLI docs for more information.
Refer to [Using Terraform Cloud](/docs/cli/cloud/index.html) in the Terraform CLI docs for more information.