website: CLI: Update links to moved docs pages
This commit is contained in:
parent
a8332703c9
commit
d1e8537b33
|
@ -25,5 +25,5 @@ Terraform Cloud user account.
|
|||
|
||||
For details, see:
|
||||
|
||||
- [The `terraform login` command](/docs/commands/login.html)
|
||||
- [The `terraform logout` command](/docs/commands/logout.html)
|
||||
- [The `terraform login` command](/docs/cli/commands/login.html)
|
||||
- [The `terraform logout` command](/docs/cli/commands/logout.html)
|
||||
|
|
|
@ -13,18 +13,18 @@ Terraform CLI includes several commands to make Terraform code more convenient
|
|||
to work with. Integrating these commands into your editing workflow can
|
||||
potentially save you time and effort.
|
||||
|
||||
- [The `terraform console` command](/docs/commands/console.html) starts an
|
||||
- [The `terraform console` command](/docs/cli/commands/console.html) starts an
|
||||
interactive shell for evaluating Terraform
|
||||
[expressions](/docs/language/expressions/index.html), which can be a faster way
|
||||
to verify that a particular resource argument results in the value you expect.
|
||||
|
||||
|
||||
- [The `terraform fmt` command](/docs/commands/fmt.html) rewrites Terraform
|
||||
- [The `terraform fmt` command](/docs/cli/commands/fmt.html) rewrites Terraform
|
||||
configuration files to a canonical format and style, so you don't have to
|
||||
waste time making minor adjustments for readability and consistency. It works
|
||||
well as a pre-commit hook in your version control system.
|
||||
|
||||
- [The `terraform validate` command](/docs/commands/validate.html) validates the
|
||||
- [The `terraform validate` command](/docs/cli/commands/validate.html) validates the
|
||||
syntax and arguments of the Terraform configuration files in a directory,
|
||||
including argument and attribute names and types for resources and modules.
|
||||
The `plan` and `apply` commands automatically validate a configuration before
|
||||
|
@ -32,8 +32,8 @@ potentially save you time and effort.
|
|||
workflow, but it can be very useful as a pre-commit hook or as part of a
|
||||
continuous integration pipeline.
|
||||
|
||||
- [The `0.13upgrade` command](/docs/commands/0.13upgrade.html) and
|
||||
[the `0.12upgrade` command](/docs/commands/0.12upgrade.html) can automatically
|
||||
- [The `0.13upgrade` command](/docs/cli/commands/0.13upgrade.html) and
|
||||
[the `0.12upgrade` command](/docs/cli/commands/0.12upgrade.html) can automatically
|
||||
modify the configuration files in a Terraform module to help deal with major
|
||||
syntax changes that occurred in the 0.13 and 0.12 releases of Terraform. Both
|
||||
of these commands are only available in the Terraform version they are
|
||||
|
|
|
@ -66,9 +66,9 @@ The command-line flags are all optional. The list of available flags are:
|
|||
[remote state](/docs/language/state/remote.html) is used.
|
||||
|
||||
* `-target=resource` - A [Resource
|
||||
Address](/docs/internals/resource-addressing.html) to target. For more
|
||||
Address](/docs/cli/state/resource-addressing.html) to target. For more
|
||||
information, see
|
||||
[the targeting docs from `terraform plan`](/docs/commands/plan.html#resource-targeting).
|
||||
[the targeting docs from `terraform plan`](/docs/cli/commands/plan.html#resource-targeting).
|
||||
|
||||
* `-var 'foo=bar'` - Set a variable in the Terraform configuration. This flag
|
||||
can be set multiple times. Variable values are interpreted as
|
||||
|
@ -100,6 +100,6 @@ current working directory.
|
|||
If your previous use of this legacy pattern was also relying on Terraform
|
||||
writing the `.terraform` subdirectory into the current working directory even
|
||||
though the root module directory was overridden, use
|
||||
[the `TF_DATA_DIR` environment variable](environment-variables.html#tf_data_dir)
|
||||
[the `TF_DATA_DIR` environment variable](/docs/cli/config/environment-variables.html#tf_data_dir)
|
||||
to direct Terraform to write the `.terraform` directory to a location other
|
||||
than the current working directory.
|
||||
|
|
|
@ -19,13 +19,13 @@ Infrastructure managed by Terraform will be destroyed. This will ask for
|
|||
confirmation before destroying.
|
||||
|
||||
This command accepts all the arguments and options that the [apply
|
||||
command](/docs/commands/apply.html) accepts, with the exception of a plan file
|
||||
command](/docs/cli/commands/apply.html) accepts, with the exception of a plan file
|
||||
argument.
|
||||
|
||||
If `-auto-approve` is set, then the destroy confirmation will not be shown.
|
||||
|
||||
The `-target` flag, instead of affecting "dependencies" will instead also
|
||||
destroy any resources that _depend on_ the target(s) specified. For more information, see [the targeting docs from `terraform plan`](/docs/commands/plan.html#resource-targeting).
|
||||
destroy any resources that _depend on_ the target(s) specified. For more information, see [the targeting docs from `terraform plan`](/docs/cli/commands/plan.html#resource-targeting).
|
||||
|
||||
The behavior of any `terraform destroy` command can be previewed at any time
|
||||
with an equivalent `terraform plan -destroy` command.
|
||||
|
|
|
@ -9,5 +9,5 @@ description: |-
|
|||
# Command: env
|
||||
|
||||
The `terraform env` command is deprecated.
|
||||
[The `terraform workspace` command](/docs/commands/workspace/)
|
||||
[The `terraform workspace` command](/docs/cli/commands/workspace/index.html)
|
||||
should be used instead.
|
||||
|
|
|
@ -11,7 +11,7 @@ description: |-
|
|||
> **Hands-on:** Try the [Import Terraform Configuration](https://learn.hashicorp.com/tutorials/terraform/state-import?in=terraform/state&utm_source=WEBSITE&utm_medium=WEB_IO&utm_offer=ARTICLE_PAGE&utm_content=DOCS) tutorial on HashiCorp Learn.
|
||||
|
||||
The `terraform import` command is used to
|
||||
[import existing resources](/docs/import/index.html)
|
||||
[import existing resources](/docs/cli/import/index.html)
|
||||
into Terraform.
|
||||
|
||||
## Usage
|
||||
|
@ -21,7 +21,7 @@ Usage: `terraform import [options] ADDRESS ID`
|
|||
Import will find the existing resource from ID and import it into your Terraform
|
||||
state at the given ADDRESS.
|
||||
|
||||
ADDRESS must be a valid [resource address](/docs/internals/resource-addressing.html).
|
||||
ADDRESS must be a valid [resource address](/docs/cli/state/resource-addressing.html).
|
||||
Because any resource address is valid, the import command can import resources
|
||||
into modules as well as directly into the root of your state.
|
||||
|
||||
|
|
|
@ -101,7 +101,7 @@ will be read or written in the given directory instead.
|
|||
There are two exceptions where Terraform will use the original working directory
|
||||
even when you specify `-chdir=...`:
|
||||
|
||||
* Settings in the [CLI Configuration](cli-config.html) are not for a specific
|
||||
* Settings in the [CLI Configuration](/docs/cli/config/config-file.html) are not for a specific
|
||||
subcommand and Terraform processes them before acting on the `-chdir`
|
||||
option.
|
||||
|
||||
|
@ -154,7 +154,7 @@ Checkpoint itself can be entirely disabled for all HashiCorp products by
|
|||
setting the environment variable `CHECKPOINT_DISABLE` to any non-empty value.
|
||||
|
||||
Alternatively, settings in
|
||||
[the CLI configuration file](/docs/commands/cli-config.html) can be used to
|
||||
[the CLI configuration file](/docs/cli/config/config-file.html) can be used to
|
||||
disable checkpoint features. The following checkpoint-related settings are
|
||||
supported in this file:
|
||||
|
||||
|
|
|
@ -123,7 +123,7 @@ third-party provider registry, `terraform init` will automatically find,
|
|||
download, and install the necessary provider plugins. If you cannot or do not
|
||||
wish to install providers from their origin registries, you can customize how
|
||||
Terraform installs providers using
|
||||
[the provider installation settings in the CLI configuration](./cli-config.html#provider-installation).
|
||||
[the provider installation settings in the CLI configuration](/docs/cli/config/config-file.html#provider-installation).
|
||||
|
||||
For more information about specifying which providers are required for each
|
||||
of your modules, see [Provider Requirements](/docs/language/providers/requirements.html).
|
||||
|
@ -145,15 +145,15 @@ You can modify `terraform init`'s plugin behavior with the following options:
|
|||
- `-get-plugins=false` — Skip plugin installation.
|
||||
|
||||
-> Note: Since Terraform 0.13, this option has been superseded by the
|
||||
[`provider_installation`](./cli-config.html#provider-installation) and
|
||||
[`plugin_cache_dir`](./cli-config.html#plugin_cache_dir) settings.
|
||||
[`provider_installation`](/docs/cli/config/config-file.html#provider-installation) and
|
||||
[`plugin_cache_dir`](/docs/cli/config/config-file.html#plugin_cache_dir) settings.
|
||||
It should not be used in Terraform versions 0.13+, and this option
|
||||
was removed in Terraform 0.15.
|
||||
- `-plugin-dir=PATH` — Force plugin installation to read plugins _only_ from
|
||||
the specified directory, as if it had been configured as a `filesystem_mirror`
|
||||
in the CLI configuration. If you intend to routinely use a particular
|
||||
filesystem mirror then we recommend
|
||||
[configuring Terraform's installation methods globally](./cli-config.html#provider-installation).
|
||||
[configuring Terraform's installation methods globally](/docs/cli/config/config-file.html#provider-installation).
|
||||
You can use `-plugin-dir` as a one-time override for exceptional situations,
|
||||
such as if you are testing a local build of a provider plugin you are
|
||||
currently developing.
|
||||
|
@ -187,6 +187,6 @@ current working directory.
|
|||
If your previous use of this legacy pattern was also relying on Terraform
|
||||
writing the `.terraform` subdirectory into the current working directory even
|
||||
though the root module directory was overridden, use
|
||||
[the `TF_DATA_DIR` environment variable](environment-variables.html#tf_data_dir)
|
||||
[the `TF_DATA_DIR` environment variable](/docs/cli/config/environment-variables.html#tf_data_dir)
|
||||
to direct Terraform to write the `.terraform` directory to a location other
|
||||
than the current working directory.
|
||||
|
|
|
@ -15,7 +15,7 @@ API token for Terraform Cloud, Terraform Enterprise, or any other host that offe
|
|||
where it is possible to launch a web browser on the same host where Terraform
|
||||
is running. If you are running Terraform in an unattended automation scenario,
|
||||
you can
|
||||
[configure credentials manually in the CLI configuration](https://www.terraform.io/docs/commands/cli-config.html#credentials).
|
||||
[configure credentials manually in the CLI configuration](https://www.terraform.io/docs/cli/config/config-file.html#credentials).
|
||||
|
||||
## Usage
|
||||
|
||||
|
@ -34,7 +34,7 @@ not as desired.
|
|||
|
||||
If you don't wish to store your API token in the default location, you can
|
||||
optionally configure a
|
||||
[credentials helper program](cli-config.html#credentials-helpers) which knows
|
||||
[credentials helper program](/docs/cli/config/config-file.html#credentials-helpers) which knows
|
||||
how to store and later retrieve credentials in some other system, such as
|
||||
your organization's existing secrets management system.
|
||||
|
||||
|
|
|
@ -26,5 +26,5 @@ the remote server, so it will remain valid until manually revoked.
|
|||
|
||||
By default, Terraform will remove the token stored in plain text in a local CLI
|
||||
configuration file called `credentials.tfrc.json`. If you have configured a
|
||||
[credentials helper program](cli-config.html#credentials-helpers), Terraform
|
||||
[credentials helper program](/docs/cli/config/config-file.html#credentials-helpers), Terraform
|
||||
will use the helper's `forget` command to remove it.
|
||||
|
|
|
@ -73,7 +73,7 @@ The available options are:
|
|||
Ignored when [remote state](/docs/language/state/remote.html) is used.
|
||||
|
||||
* `-target=resource` - A [Resource
|
||||
Address](/docs/internals/resource-addressing.html) to target. This flag can
|
||||
Address](/docs/cli/state/resource-addressing.html) to target. This flag can
|
||||
be used multiple times. See below for more information.
|
||||
|
||||
* `-var 'foo=bar'` - Set a variable in the Terraform configuration. This flag
|
||||
|
@ -93,7 +93,7 @@ The available options are:
|
|||
|
||||
The `-target` option can be used to focus Terraform's attention on only a
|
||||
subset of resources.
|
||||
[Resource Address](/docs/internals/resource-addressing.html) syntax is used
|
||||
[Resource Address](/docs/cli/state/resource-addressing.html) syntax is used
|
||||
to specify the constraint. The resource address is interpreted as follows:
|
||||
|
||||
* If the given address has a _resource spec_, only the specified resource
|
||||
|
@ -150,6 +150,6 @@ current working directory.
|
|||
If your previous use of this legacy pattern was also relying on Terraform
|
||||
writing the `.terraform` subdirectory into the current working directory even
|
||||
though the root module directory was overridden, use
|
||||
[the `TF_DATA_DIR` environment variable](environment-variables.html#tf_data_dir)
|
||||
[the `TF_DATA_DIR` environment variable](/docs/cli/config/environment-variables.html#tf_data_dir)
|
||||
to direct Terraform to write the `.terraform` directory to a location other
|
||||
than the current working directory.
|
||||
|
|
|
@ -15,11 +15,11 @@ order to write provider dependency information into
|
|||
|
||||
The common way to update the dependency lock file is as a side-effect of normal
|
||||
provider installation during
|
||||
[`terraform init`](../init.html), but there are several situations where that
|
||||
[`terraform init`](/docs/cli/commands/init.html), but there are several situations where that
|
||||
automatic approach may not be sufficient:
|
||||
|
||||
* If you are running Terraform in an environment that uses
|
||||
[alternative provider installation methods](../cli-config.html#provider-installation),
|
||||
[alternative provider installation methods](/docs/cli/config/config-file.html#provider-installation),
|
||||
such as filesystem or network mirrors, normal provider installation will not
|
||||
access the origin registry for a provider and therefore Terraform will not
|
||||
be able to populate all of the possible package checksums for the selected
|
||||
|
@ -150,7 +150,7 @@ multiple times and specify a different subset of your providers each time.
|
|||
|
||||
The `-fs-mirror` and `-net-mirror` options have the same meaning as
|
||||
`filesystem_mirror` and `network_mirror` blocks in
|
||||
[the provider installation methods configuration](../cli-config.html#provider-installation),
|
||||
[the provider installation methods configuration](/docs/cli/config/config-file.html#provider-installation),
|
||||
but specify only a single method in order to be explicit about where you
|
||||
intend to derive the package checksum information from.
|
||||
|
||||
|
|
|
@ -19,7 +19,7 @@ from provider registries as part of initializing the current working directory.
|
|||
Sometimes Terraform is running in an environment where that isn't possible,
|
||||
such as on an isolated network without access to the Terraform Registry. In
|
||||
that case,
|
||||
[explicit installation method configuration](../cli-config.html#explicit-installation-method-configuration)
|
||||
[explicit installation method configuration](/docs/cli/config/config-file.html#explicit-installation-method-configuration)
|
||||
allows you to configure Terraform, when running on a particular system, to
|
||||
consult only a local filesystem directory where you've created a local mirror
|
||||
of the necessary plugins, and to skip accessing the upstream registry at all.
|
||||
|
|
|
@ -50,7 +50,7 @@ The `terraform refresh` command accepts the following options:
|
|||
[remote state](/docs/language/state/remote.html) is used.
|
||||
|
||||
* `-target=resource` - A [Resource
|
||||
Address](/docs/internals/resource-addressing.html) to target. Operation will
|
||||
Address](/docs/cli/state/resource-addressing.html) to target. Operation will
|
||||
be limited to this resource and its dependencies. This flag can be used
|
||||
multiple times.
|
||||
|
||||
|
|
|
@ -35,7 +35,7 @@ written to disk and the CLI usage is the same as if it were local state.
|
|||
All `terraform state` subcommands that modify the state write backup
|
||||
files. The path of these backup file can be controlled with `-backup`.
|
||||
|
||||
Subcommands that are read-only (such as [list](/docs/commands/state/list.html))
|
||||
Subcommands that are read-only (such as [list](/docs/cli/commands/state/list.html))
|
||||
do not write any backup files since they aren't modifying the state.
|
||||
|
||||
Note that backups for state modification _can not be disabled_. Due to
|
||||
|
|
|
@ -30,7 +30,7 @@ The command-line flags are all optional. The list of available flags are:
|
|||
|
||||
The output of `terraform state show` is intended for human consumption, not
|
||||
programmatic consumption. To extract state data for use in other software, use
|
||||
[`terraform show -json`](../show.html#json-output) and decode the result
|
||||
[`terraform show -json`](/docs/cli/commands/show.html#json-output) and decode the result
|
||||
using the documented structure.
|
||||
|
||||
## Example: Show a Resource
|
||||
|
|
|
@ -14,9 +14,9 @@ as tainted, forcing it to be destroyed and recreated on the next apply.
|
|||
This command _will not_ modify infrastructure, but does modify the
|
||||
state file in order to mark a resource as tainted. Once a resource is
|
||||
marked as tainted, the next
|
||||
[plan](/docs/commands/plan.html) will show that the resource will
|
||||
[plan](/docs/cli/commands/plan.html) will show that the resource will
|
||||
be destroyed and recreated and the next
|
||||
[apply](/docs/commands/apply.html) will implement this change.
|
||||
[apply](/docs/cli/commands/apply.html) will implement this change.
|
||||
|
||||
Forcing the recreation of a resource is useful when you want a certain
|
||||
side effect of recreation that is not visible in the attributes of a resource.
|
||||
|
@ -28,7 +28,7 @@ Note that tainting a resource for recreation may affect resources that
|
|||
depend on the newly tainted resource. For example, a DNS resource that
|
||||
uses the IP address of a server may need to be modified to reflect
|
||||
the potentially new IP address of a tainted server. The
|
||||
[plan command](/docs/commands/plan.html) will show this if this is
|
||||
[plan command](/docs/cli/commands/plan.html) will show this if this is
|
||||
the case.
|
||||
|
||||
## Usage
|
||||
|
@ -37,7 +37,7 @@ Usage: `terraform taint [options] address`
|
|||
|
||||
The `address` argument is the address of the resource to mark as tainted.
|
||||
The address is in
|
||||
[the resource address syntax](/docs/internals/resource-addressing.html) syntax,
|
||||
[the resource address syntax](/docs/cli/state/resource-addressing.html) syntax,
|
||||
as shown in the output from other commands, such as:
|
||||
|
||||
* `aws_instance.foo`
|
||||
|
|
|
@ -17,7 +17,7 @@ Usage: `terraform version [options]`
|
|||
|
||||
With no additional arguments, `version` will display the version of Terraform,
|
||||
the platform it's installed on, installed providers, and the results of upgrade
|
||||
and security checks [unless disabled](/docs/commands/index.html#upgrade-and-security-bulletin-checks).
|
||||
and security checks [unless disabled](/docs/cli/commands/index.html#upgrade-and-security-bulletin-checks).
|
||||
|
||||
This command has one optional flag:
|
||||
|
||||
|
|
|
@ -33,7 +33,7 @@ as just `terraform.rc`. Use `dir` from PowerShell or Command Prompt to
|
|||
confirm the filename.
|
||||
|
||||
The location of the Terraform CLI configuration file can also be specified
|
||||
using the `TF_CLI_CONFIG_FILE` [environment variable](/docs/commands/environment-variables.html).
|
||||
using the `TF_CLI_CONFIG_FILE` [environment variable](/docs/cli/config/environment-variables.html).
|
||||
|
||||
## Configuration File Syntax
|
||||
|
||||
|
@ -60,7 +60,7 @@ The following settings can be set in the CLI configuration file:
|
|||
See [Credentials Helpers](#credentials-helpers) below for more information.
|
||||
|
||||
- `disable_checkpoint` — when set to `true`, disables
|
||||
[upgrade and security bulletin checks](/docs/commands/index.html#upgrade-and-security-bulletin-checks)
|
||||
[upgrade and security bulletin checks](/docs/cli/commands/index.html#upgrade-and-security-bulletin-checks)
|
||||
that require reaching out to HashiCorp-provided network services.
|
||||
|
||||
- `disable_checkpoint_signature` — when set to `true`, allows the upgrade and
|
||||
|
@ -93,7 +93,7 @@ credentials "app.terraform.io" {
|
|||
}
|
||||
```
|
||||
|
||||
If you are running the Terraform CLI interactively on a computer with a web browser, you can use [the `terraform login` command](./login.html)
|
||||
If you are running the Terraform CLI interactively on a computer with a web browser, you can use [the `terraform login` command](/docs/cli/commands/login.html)
|
||||
to get credentials and automatically save them in the CLI configuration. If
|
||||
not, you can manually write `credentials` blocks.
|
||||
|
||||
|
|
|
@ -145,7 +145,7 @@ export TF_REGISTRY_CLIENT_TIMEOUT=15
|
|||
|
||||
## TF_CLI_CONFIG_FILE
|
||||
|
||||
The location of the [Terraform CLI configuration file](/docs/commands/cli-config.html).
|
||||
The location of the [Terraform CLI configuration file](/docs/cli/config/config-file.html).
|
||||
|
||||
```shell
|
||||
export TF_CLI_CONFIG_FILE="$HOME/.terraformrc-custom"
|
||||
|
|
|
@ -14,9 +14,9 @@ most of the global settings relate to advanced or automated workflows, or
|
|||
unusual environmental conditions like running Terraform on an airgapped
|
||||
instance.
|
||||
|
||||
- The [CLI config file](/docs/commands/cli-config.html) configures provider
|
||||
- The [CLI config file](/docs/cli/config/config-file.html) configures provider
|
||||
installation and security features.
|
||||
- Several [environment variables](/docs/commands/environment-variables.html) can
|
||||
- Several [environment variables](/docs/cli/config/environment-variables.html) can
|
||||
configure Terraform's inputs and outputs; this includes some alternate ways to
|
||||
provide information that is usually passed on the command line or read from
|
||||
the state of the shell.
|
||||
|
|
|
@ -57,7 +57,7 @@ Terraform state.
|
|||
|
||||
It is also possible to import to resources in child modules, using their paths,
|
||||
and to single instances of a resource with `count` or `for_each` set. See
|
||||
[_Resource Addressing_](/docs/internals/resource-addressing.html) for more
|
||||
[_Resource Addressing_](/docs/cli/state/resource-addressing.html) for more
|
||||
details on how to specify a target resource.
|
||||
|
||||
The syntax of the given ID is dependent on the resource type being imported.
|
||||
|
@ -83,4 +83,4 @@ a `resource` block in configuration for each secondary resource. If this is
|
|||
not done, Terraform will plan to destroy the imported objects on the next run.
|
||||
|
||||
If you want to rename or otherwise move the imported resources, the
|
||||
[state management commands](/docs/commands/state/index.html) can be used.
|
||||
[state management commands](/docs/cli/commands/state/index.html) can be used.
|
||||
|
|
|
@ -47,7 +47,7 @@ plugins, and downloading modules. Under some conditions (usually when changing
|
|||
from one backend to another), it might ask the user for guidance or
|
||||
confirmation.
|
||||
|
||||
For details, see [the `terraform init` command](/docs/commands/init.html).
|
||||
For details, see [the `terraform init` command](/docs/cli/commands/init.html).
|
||||
|
||||
## Reinitialization
|
||||
|
||||
|
|
|
@ -15,19 +15,19 @@ Terraform CLI includes some commands for inspecting or transforming this data.
|
|||
You can use these to integrate other tools with Terraform's infrastructure data,
|
||||
or just to gain a deeper or more holistic understanding of your infrastructure.
|
||||
|
||||
- [The `terraform graph` command](/docs/commands/graph.html) creates a visual
|
||||
- [The `terraform graph` command](/docs/cli/commands/graph.html) creates a visual
|
||||
representation of a configuration or a set of planned changes.
|
||||
- [The `terraform output` command](/docs/commands/output.html) can get the
|
||||
- [The `terraform output` command](/docs/cli/commands/output.html) can get the
|
||||
values for the top-level [output values](/docs/language/values/outputs.html) of
|
||||
a configuration, which are often helpful when making use of the infrastructure
|
||||
Terraform has provisioned.
|
||||
- [The `terraform show` command](/docs/commands/show.html) can generate
|
||||
- [The `terraform show` command](/docs/cli/commands/show.html) can generate
|
||||
human-readable versions of a state file or plan file, or generate
|
||||
machine-readable versions that can be integrated with other tools.
|
||||
- [The `terraform state list` command](/docs/commands/state/list.html) can list
|
||||
- [The `terraform state list` command](/docs/cli/commands/state/list.html) can list
|
||||
the resources being managed by the current working directory and workspace,
|
||||
providing a complete or filtered list.
|
||||
- [The `terraform state show` command](/docs/commands/state/show.html) can print
|
||||
- [The `terraform state show` command](/docs/cli/commands/state/show.html) can print
|
||||
all of the attributes of a given resource being managed by the current working
|
||||
directory and workspace, including generated read-only attributes like the
|
||||
unique ID assigned by the cloud provider.
|
||||
|
|
|
@ -30,29 +30,29 @@ environments.
|
|||
|
||||
Terraform's configuration file includes options for caching downloaded plugins,
|
||||
or explicitly specifying a local or HTTPS mirror to install plugins from. For
|
||||
more information, see [CLI Config File](/docs/commands/cli-config.html).
|
||||
more information, see [CLI Config File](/docs/cli/config/config-file.html).
|
||||
|
||||
## Getting Plugin Information
|
||||
|
||||
Use the [`terraform providers`](/docs/commands/providers.html) command to get information
|
||||
Use the [`terraform providers`](/docs/cli/commands/providers.html) command to get information
|
||||
about the providers required by the current working directory's configuration.
|
||||
|
||||
Use the [`terraform version`](/docs/commands/version.html) command (or
|
||||
Use the [`terraform version`](/docs/cli/commands/version.html) command (or
|
||||
`terraform -version`) to show the specific provider versions installed for the
|
||||
current working directory.
|
||||
|
||||
Use the [`terraform providers schema`](/docs/commands/providers/schema.html) command to
|
||||
Use the [`terraform providers schema`](/docs/cli/commands/providers/schema.html) command to
|
||||
get machine-readable information about the resources and configuration options
|
||||
offered by each provider.
|
||||
|
||||
## Managing Plugin Installation
|
||||
|
||||
Use the [`terraform providers mirror`](/docs/commands/providers/mirror.html) command to
|
||||
Use the [`terraform providers mirror`](/docs/cli/commands/providers/mirror.html) command to
|
||||
download local copies of every provider required by the current working
|
||||
directory's configuration. This directory will use the nested directory layout
|
||||
that Terraform expects when installing plugins from a local source, so you can
|
||||
transfer it directly to an airgapped system that runs Terraform.
|
||||
|
||||
Use the [`terraform providers lock`](/docs/commands/providers/lock.html) command
|
||||
Use the [`terraform providers lock`](/docs/cli/commands/providers/lock.html) command
|
||||
to update the lock file that Terraform uses to ensure predictable runs when
|
||||
using ambiguous provider version constraints.
|
||||
|
|
|
@ -38,7 +38,7 @@ resulting actions are as expected. However, `terraform plan` can also save its
|
|||
plan as a runnable artifact, which `terraform apply` can use to carry out those
|
||||
exact changes.
|
||||
|
||||
For details, see [the `terraform plan` command](/docs/commands/plan.html).
|
||||
For details, see [the `terraform plan` command](/docs/cli/commands/plan.html).
|
||||
|
||||
## Applying
|
||||
|
||||
|
@ -54,7 +54,7 @@ running a new plan. You can use this to reliably perform an exact set of
|
|||
pre-approved changes, even if the configuration or the state of the real
|
||||
infrastructure has changed in the minutes since the original plan was created.
|
||||
|
||||
For details, see [the `terraform apply` command](/docs/commands/apply.html).
|
||||
For details, see [the `terraform apply` command](/docs/cli/commands/apply.html).
|
||||
|
||||
## Destroying
|
||||
|
||||
|
@ -68,4 +68,4 @@ and then running an apply, except that it doesn't require editing the
|
|||
configuration. This is more convenient if you intend to provision similar
|
||||
resources at a later date.
|
||||
|
||||
For details, see [the `terraform destroy` command](/docs/commands/destroy.html).
|
||||
For details, see [the `terraform destroy` command](/docs/cli/commands/destroy.html).
|
||||
|
|
|
@ -21,7 +21,7 @@ Terraform CLI supports several workflows for interacting with state:
|
|||
- [Forcing Re-creation (Tainting)](/docs/cli/state/taint.html)
|
||||
- [Moving Resources](/docs/cli/state/move.html)
|
||||
- Importing Pre-existing Resources (documented in the
|
||||
[Importing Infrastructure](/docs/import/index.html) section)
|
||||
[Importing Infrastructure](/docs/cli/import/index.html) section)
|
||||
- [Disaster Recovery](/docs/cli/state/recover.html)
|
||||
|
||||
~> **Important:** Modifying state data outside a normal plan or apply can cause
|
||||
|
|
|
@ -8,14 +8,14 @@ page_title: "Inspecting State - Terraform CLI"
|
|||
Terraform includes some commands for reading and updating state without taking
|
||||
any other actions.
|
||||
|
||||
- [The `terraform state list` command](/docs/commands/state/list.html)
|
||||
- [The `terraform state list` command](/docs/cli/commands/state/list.html)
|
||||
shows the resource addresses for every resource Terraform knows about in a
|
||||
configuration, optionally filtered by partial resource address.
|
||||
|
||||
- [The `terraform state show` command](/docs/commands/state/show.html)
|
||||
- [The `terraform state show` command](/docs/cli/commands/state/show.html)
|
||||
displays detailed state data about one resource.
|
||||
|
||||
- [The `terraform refresh` command](/docs/commands/refresh.html) updates
|
||||
- [The `terraform refresh` command](/docs/cli/commands/refresh.html) updates
|
||||
state data to match the real-world condition of the managed resources. This is
|
||||
done automatically during plans and applies, but not when interacting with
|
||||
state directly.
|
||||
|
|
|
@ -6,7 +6,7 @@ page_title: "Moving Resources - Terraform CLI"
|
|||
# Moving Resources
|
||||
|
||||
Terraform's state associates each real-world object with a configured resource
|
||||
at a specific [resource address](/docs/internals/resource-addressing.html). This
|
||||
at a specific [resource address](/docs/cli/state/resource-addressing.html). This
|
||||
is seamless when changing a resource's attributes, but Terraform will lose track
|
||||
of a resource if you change its name, move it to a different module, or change
|
||||
its provider.
|
||||
|
@ -19,17 +19,17 @@ In cases where it's important to preserve an existing infrastructure object, you
|
|||
can explicitly tell Terraform to associate it with a different configured
|
||||
resource.
|
||||
|
||||
- [The `terraform state mv` command](/docs/commands/state/mv.html) changes
|
||||
- [The `terraform state mv` command](/docs/cli/commands/state/mv.html) changes
|
||||
which resource address in your configuration is associated with a particular
|
||||
real-world object. Use this to preserve an object when renaming a resource, or
|
||||
when moving a resource into or out of a child module.
|
||||
|
||||
- [The `terraform state rm` command](/docs/commands/state/rm.html) tells
|
||||
- [The `terraform state rm` command](/docs/cli/commands/state/rm.html) tells
|
||||
Terraform to stop managing a resource as part of the current working directory
|
||||
and workspace, _without_ destroying the corresponding real-world object. (You
|
||||
can later use `terraform import` to start managing that resource in a
|
||||
different workspace or a different Terraform configuration.)
|
||||
|
||||
- [The `terraform state replace-provider` command](/docs/commands/state/replace-provider.html)
|
||||
- [The `terraform state replace-provider` command](/docs/cli/commands/state/replace-provider.html)
|
||||
transfers existing resources to a new provider without requiring them to be
|
||||
re-created.
|
||||
|
|
|
@ -9,7 +9,7 @@ If something has gone horribly wrong (possibly due to accidents when performing
|
|||
other state manipulation actions), you might need to take drastic actions with
|
||||
your state data.
|
||||
|
||||
- [The `terraform force-unlock` command](/docs/commands/force-unlock.html) can
|
||||
- [The `terraform force-unlock` command](/docs/cli/commands/force-unlock.html) can
|
||||
override the protections Terraform uses to prevent two processes from
|
||||
modifying state at the same time. You might need this if a Terraform process
|
||||
(like a normal apply) is unexpectedly terminated (like by the complete
|
||||
|
@ -17,8 +17,8 @@ your state data.
|
|||
state backend. Do not run this until you are completely certain what happened
|
||||
to the process that caused the lock to get stuck.
|
||||
|
||||
- [The `terraform state pull` command](/docs/commands/state/pull.html) and
|
||||
[the `terraform state push` command](/docs/commands/state/push.html) can
|
||||
- [The `terraform state pull` command](/docs/cli/commands/state/pull.html) and
|
||||
[the `terraform state push` command](/docs/cli/commands/state/push.html) can
|
||||
directly read and write entire state files from and to the configured backend.
|
||||
You might need this for obtaining or restoring a state backup.
|
||||
|
||||
|
|
|
@ -16,10 +16,10 @@ happen during creation; for example, a virtual machine that configures itself
|
|||
with `cloud-init` on startup might no longer meet your needs if the cloud-init
|
||||
configuration changes.
|
||||
|
||||
- [The `terraform taint` command](/docs/commands/taint.html) tells Terraform to
|
||||
- [The `terraform taint` command](/docs/cli/commands/taint.html) tells Terraform to
|
||||
destroy and re-create a particular resource during the next apply, regardless
|
||||
of whether its resource arguments would normally require that.
|
||||
|
||||
- [The `terraform untaint` command](/docs/commands/untaint.html) undoes a
|
||||
- [The `terraform untaint` command](/docs/cli/commands/untaint.html) undoes a
|
||||
previous taint, or can preserve a resource that was automatically tainted due
|
||||
to failed [provisioners](/docs/language/resources/provisioners/syntax.html).
|
||||
|
|
|
@ -17,11 +17,11 @@ resources with the same configuration.
|
|||
- Most Terraform commands (including [provisioning](/docs/cli/run/index.html)
|
||||
and [state manipulation](/docs/cli/state/index.html) commands) only interact
|
||||
with the currently selected workspace.
|
||||
- Use [the `terraform workspace select` command](/docs/commands/workspace/select.html)
|
||||
- Use [the `terraform workspace select` command](/docs/cli/commands/workspace/select.html)
|
||||
to change the currently selected workspace.
|
||||
- Use the [`terraform workspace list`](/docs/commands/workspace/list.html),
|
||||
[`terraform workspace new`](/docs/commands/workspace/new.html), and
|
||||
[`terraform workspace delete`](/docs/commands/workspace/delete.html) commands
|
||||
- Use the [`terraform workspace list`](/docs/cli/commands/workspace/list.html),
|
||||
[`terraform workspace new`](/docs/cli/commands/workspace/new.html), and
|
||||
[`terraform workspace delete`](/docs/cli/commands/workspace/delete.html) commands
|
||||
to manage the available workspaces in the current working directory.
|
||||
|
||||
-> **Note:** Terraform Cloud and Terraform CLI both have features called
|
||||
|
|
|
@ -9,7 +9,7 @@ description: |-
|
|||
# Resource Addressing
|
||||
|
||||
The `terraform state` subcommands use
|
||||
[standard address syntax](/docs/internals/resource-addressing.html) to refer
|
||||
[standard address syntax](/docs/cli/state/resource-addressing.html) to refer
|
||||
to individual resources, resource instances, and modules. This is the same
|
||||
syntax used for the `-target` option to the `apply` and `plan` commands.
|
||||
|
||||
|
@ -17,4 +17,4 @@ Most state commands allow referring to individual resource instances, whole
|
|||
resources (which may have multiple instances if `count` or `for_each` is used),
|
||||
or even whole modules.
|
||||
|
||||
For more information on the syntax, see [Resource Addressing](/docs/internals/resource-addressing.html).
|
||||
For more information on the syntax, see [Resource Addressing](/docs/cli/state/resource-addressing.html).
|
||||
|
|
|
@ -10,7 +10,7 @@ description: |-
|
|||
|
||||
-> **Note:** This page is about Terraform 0.11 and earlier. For Terraform 0.12
|
||||
and later, see
|
||||
[Commands: Environment Variables](../commands/environment-variables.html).
|
||||
[Commands: Environment Variables](/docs/cli/config/environment-variables.html).
|
||||
|
||||
## TF_LOG
|
||||
|
||||
|
@ -48,7 +48,7 @@ export TF_INPUT=0
|
|||
|
||||
## TF_MODULE_DEPTH
|
||||
|
||||
When given a value, causes terraform commands to behave as if the `-module-depth=VALUE` flag was specified. By setting this to 0, for example, you enable commands such as [plan](/docs/commands/plan.html) and [graph](/docs/commands/graph.html) to display more compressed information.
|
||||
When given a value, causes terraform commands to behave as if the `-module-depth=VALUE` flag was specified. By setting this to 0, for example, you enable commands such as [plan](/docs/cli/commands/plan.html) and [graph](/docs/cli/commands/graph.html) to display more compressed information.
|
||||
|
||||
```shell
|
||||
export TF_MODULE_DEPTH=0
|
||||
|
|
|
@ -560,7 +560,7 @@ Operator precedences is the standard mathematical order of operations:
|
|||
"${2 * (4 + 3) * 3}" # computes to 42
|
||||
```
|
||||
|
||||
You can use the [terraform console](/docs/commands/console.html) command to
|
||||
You can use the [terraform console](/docs/cli/commands/console.html) command to
|
||||
try the math operations.
|
||||
|
||||
-> **Note:** Since Terraform allows hyphens in resource and variable names,
|
||||
|
|
|
@ -386,7 +386,7 @@ giving each instance a unique name -- here `module "assets_bucket"` and
|
|||
Resources from child modules are prefixed with `module.<module-instance-name>`
|
||||
when displayed in plan output and elsewhere in the UI. For example, the
|
||||
`./publish_bucket` module contains `aws_s3_bucket.example`, and so the two
|
||||
instances of this module produce S3 bucket resources with [_resource addresses_](/docs/internals/resource-addressing.html)
|
||||
instances of this module produce S3 bucket resources with [_resource addresses_](/docs/cli/state/resource-addressing.html)
|
||||
`module.assets_bucket.aws_s3_bucket.example` and `module.media_bucket.aws_s3_bucket.example`
|
||||
respectively. These full addresses are used within the UI and on the command
|
||||
line, but are not valid within interpolation expressions due to the
|
||||
|
@ -405,7 +405,7 @@ several regions or datacenters.
|
|||
|
||||
## Tainting resources within a module
|
||||
|
||||
The [taint command](/docs/commands/taint.html) can be used to _taint_ specific
|
||||
The [taint command](/docs/cli/commands/taint.html) can be used to _taint_ specific
|
||||
resources within a module:
|
||||
|
||||
```shell
|
||||
|
|
|
@ -14,7 +14,7 @@ and later, see
|
|||
|
||||
Outputs define values that will be highlighted to the user
|
||||
when Terraform applies, and can be queried easily using the
|
||||
[output command](/docs/commands/output.html).
|
||||
[output command](/docs/cli/commands/output.html).
|
||||
|
||||
Terraform knows a lot about the infrastructure it manages.
|
||||
Most resources have attributes associated with them, and
|
||||
|
|
|
@ -79,7 +79,7 @@ distributed by HashiCorp. See [Third-party Plugins](#third-party-plugins) below
|
|||
for installation instructions.
|
||||
|
||||
For more information, see
|
||||
[the `terraform init` command](/docs/commands/init.html).
|
||||
[the `terraform init` command](/docs/cli/commands/init.html).
|
||||
|
||||
## Provider Versions
|
||||
|
||||
|
@ -118,7 +118,7 @@ provider "aws" {
|
|||
```
|
||||
|
||||
This special argument applies to _all_ providers.
|
||||
[`terraform providers`](/docs/commands/providers.html) can be used to
|
||||
[`terraform providers`](/docs/cli/commands/providers.html) can be used to
|
||||
view the specified version constraints for all providers used in the
|
||||
current configuration.
|
||||
|
||||
|
@ -295,7 +295,7 @@ use of a local directory as a shared plugin cache, which then allows each
|
|||
distinct plugin binary to be downloaded only once.
|
||||
|
||||
To enable the plugin cache, use the `plugin_cache_dir` setting in
|
||||
[the CLI configuration file](https://www.terraform.io/docs/commands/cli-config.html).
|
||||
[the CLI configuration file](https://www.terraform.io/docs/cli/config/config-file.html).
|
||||
For example:
|
||||
|
||||
```hcl
|
||||
|
|
|
@ -13,7 +13,7 @@ feature that was removed in Terraform 0.12.
|
|||
|
||||
~> **Important:** The `terraform push` command is deprecated, and only works with the legacy version of Terraform Enterprise. In the current version of Terraform Cloud, you can upload configurations using the API. See [the docs about API-driven runs](/docs/cloud/run/api.html) for more details.
|
||||
|
||||
The [`terraform push` command](/docs/commands/push.html) uploads a configuration to a Terraform Enterprise (legacy) environment. The name of the environment (and the organization it's in) can be specified on the command line, or as part of the Terraform configuration in an `atlas` block.
|
||||
The [`terraform push` command](/docs/cli/commands/push.html) uploads a configuration to a Terraform Enterprise (legacy) environment. The name of the environment (and the organization it's in) can be specified on the command line, or as part of the Terraform configuration in an `atlas` block.
|
||||
|
||||
The `atlas` block does not configure remote state; it only configures the push command. For remote state, use a `terraform { backend "<NAME>" {...} }` block.
|
||||
|
||||
|
@ -40,7 +40,7 @@ Enterprise**. While this transition is in progress, you may see references to
|
|||
## Description
|
||||
|
||||
The `atlas` block configures the settings when Terraform is
|
||||
[pushed](/docs/commands/push.html) to Terraform Enterprise. Only one `atlas` block
|
||||
[pushed](/docs/cli/commands/push.html) to Terraform Enterprise. Only one `atlas` block
|
||||
is allowed.
|
||||
|
||||
Within the block (the `{ }`) is configuration for Atlas uploading.
|
||||
|
@ -50,7 +50,7 @@ No keys are required, but the key typically set is `name`.
|
|||
to the nature of this configuration, interpolations are not possible.
|
||||
If you want to parameterize these settings, use the Atlas block to
|
||||
set defaults, then use the command-line flags of the
|
||||
[push command](/docs/commands/push.html) to override.
|
||||
[push command](/docs/cli/commands/push.html) to override.
|
||||
|
||||
## Syntax
|
||||
|
||||
|
|
|
@ -12,7 +12,7 @@ For Terraform-specific features that interact with remote network services,
|
|||
such as [module registries](/docs/registry/) and
|
||||
[remote operations](/docs/cloud/run/cli.html), Terraform by default looks for
|
||||
API credentials to use in these calls in
|
||||
[the CLI configuration](/docs/commands/cli-config.html).
|
||||
[the CLI configuration](/docs/cli/config/config-file.html).
|
||||
|
||||
Credentials helpers offer an alternative approach that allows you to customize
|
||||
how Terraform obtains credentials using an external program, which can then
|
||||
|
@ -20,7 +20,7 @@ directly access an existing secrets management system in your organization.
|
|||
|
||||
This page is about how to write and install a credentials helper. To learn
|
||||
how to configure a credentials helper that was already installed, see
|
||||
[the CLI config Credentials Helpers section](/docs/commands/cli-config.html#credentials-helpers).
|
||||
[the CLI config Credentials Helpers section](/docs/cli/config/config-file.html#credentials-helpers).
|
||||
|
||||
## How Terraform finds Credentials Helpers
|
||||
|
||||
|
@ -57,7 +57,7 @@ The current set of verbs are:
|
|||
|
||||
To represent credentials, the credentials helper protocol uses a JSON object
|
||||
whose contents correspond with the contents of
|
||||
[`credentials` blocks in the CLI configuration](/docs/commands/cli-config.html#credentials).
|
||||
[`credentials` blocks in the CLI configuration](/docs/cli/config/config-file.html#credentials).
|
||||
To represent an API token, the object contains a property called "token" whose
|
||||
value is the token string:
|
||||
|
||||
|
|
|
@ -108,8 +108,8 @@ The amount of parallelism is limited using a semaphore to prevent too many
|
|||
concurrent operations from overwhelming the resources of the machine running
|
||||
Terraform. By default, up to 10 nodes in the graph will be processed
|
||||
concurrently. This number can be set using the `-parallelism` flag on the
|
||||
[plan](/docs/commands/plan.html), [apply](/docs/commands/apply.html), and
|
||||
[destroy](/docs/commands/destroy.html) commands.
|
||||
[plan](/docs/cli/commands/plan.html), [apply](/docs/cli/commands/apply.html), and
|
||||
[destroy](/docs/cli/commands/destroy.html) commands.
|
||||
|
||||
Setting `-parallelism` is considered an advanced operation and should not be
|
||||
necessary for normal usage of Terraform. It may be helpful in certain special
|
||||
|
|
|
@ -14,7 +14,7 @@ When Terraform plans to make changes, it prints a human-readable summary to the
|
|||
|
||||
Since the format of plan files isn't suited for use with external tools (and likely never will be), Terraform can output a machine-readable JSON representation of a plan file's changes. It can also convert state files to the same format, to simplify data loading and provide better long-term compatibility.
|
||||
|
||||
Use `terraform show -json <FILE>` to generate a JSON representation of a plan or state file. See [the `terraform show` documentation](/docs/commands/show.html) for more details.
|
||||
Use `terraform show -json <FILE>` to generate a JSON representation of a plan or state file. See [the `terraform show` documentation](/docs/cli/commands/show.html) for more details.
|
||||
|
||||
-> **Note:** The output includes a `format_version` key, which currently has major version zero to indicate that the format is experimental and subject to change. A future version will assign a non-zero major version and make stronger promises about compatibility. We do not anticipate any significant breaking changes to the format before its first major version, however.
|
||||
|
||||
|
|
|
@ -9,7 +9,7 @@ description: |-
|
|||
# Server-side Login Protocol
|
||||
|
||||
~> **Note:** You don't need to read these docs to _use_
|
||||
[`terraform login`](/docs/commands/login.html). The information below is for
|
||||
[`terraform login`](/docs/cli/commands/login.html). The information below is for
|
||||
anyone intending to implement the server side of `terraform login` in order to
|
||||
offer Terraform-native services in a third-party system.
|
||||
|
||||
|
|
|
@ -18,7 +18,7 @@ implement to provide an alternative installation source for Terraform providers,
|
|||
regardless of their origin registries.
|
||||
|
||||
Terraform uses network mirrors only if you activate them explicitly in
|
||||
[the CLI configuration's `provider_installation` block](/docs/commands/cli-config.html#provider-installation).
|
||||
[the CLI configuration's `provider_installation` block](/docs/cli/config/config-file.html#provider-installation).
|
||||
When enabled, a network mirror can serve providers belonging to any registry
|
||||
hostname, which can allow an organization to serve all of the Terraform
|
||||
providers they intend to use from an internal server, rather than from each
|
||||
|
@ -96,7 +96,7 @@ base URL from the above CLI configuration example.
|
|||
### Authentication
|
||||
|
||||
If the CLI configuration includes
|
||||
[credentials](/docs/commands/cli-config.html#credentials) for the hostname
|
||||
[credentials](/docs/cli/config/config-file.html#credentials) for the hostname
|
||||
given in the network mirror base URL, Terraform will include those credentials
|
||||
in its requests for operations described below.
|
||||
|
||||
|
@ -264,7 +264,7 @@ in the appropriate nested subdirectories, and ensure that your system is
|
|||
configured to serve `.json` files with the `application/json` media type.
|
||||
|
||||
As a convenience, Terraform CLI includes
|
||||
[the `terraform providers mirror` subcommand](https://www.terraform.io/docs/commands/providers/mirror.html),
|
||||
[the `terraform providers mirror` subcommand](https://www.terraform.io/docs/cli/commands/providers/mirror.html),
|
||||
which will analyze the current configuration for the providers it requires,
|
||||
download the packages for those providers from their origin registries, and
|
||||
place them into a local directory suitable for use as a mirror.
|
||||
|
|
|
@ -42,7 +42,7 @@ where:
|
|||
* `hostname` is the registry host that the provider is considered to have
|
||||
originated from, and the default location Terraform will consult for
|
||||
information about the provider
|
||||
[unless overridden in the CLI configuration](/docs/commands/cli-config.html#provider-installation).
|
||||
[unless overridden in the CLI configuration](/docs/cli/config/config-file.html#provider-installation).
|
||||
* `namespace` is the name of a namespace, unique on a particular hostname, that
|
||||
can contain one or more providers that are somehow related. On the public
|
||||
Terraform Registry the "namespace" represents the organization that is
|
||||
|
@ -78,7 +78,7 @@ to see it as an entirely separate provider that will _not_ be usable by modules
|
|||
that declare a dependency on `hashicorp/azurerm`. If your goal is to create
|
||||
an alternative local distribution source for an existing provider -- that is,
|
||||
a _mirror_ of the provider -- refer to
|
||||
[the provider installation method configuration](/docs/commands/cli-config.html#provider-installation)
|
||||
[the provider installation method configuration](/docs/cli/config/config-file.html#provider-installation)
|
||||
instead.
|
||||
|
||||
## Provider Versions
|
||||
|
|
|
@ -85,14 +85,14 @@ version 1 of the module registry protocol:
|
|||
|
||||
At present, the following service identifiers are in use:
|
||||
|
||||
* `login.v1`: [login protocol version 1](/docs/commands/login.html)
|
||||
* `login.v1`: [login protocol version 1](/docs/cli/commands/login.html)
|
||||
* `modules.v1`: [module registry API version 1](module-registry-protocol.html)
|
||||
* `providers.v1`: [provider registry API version 1](provider-registry-protocol.html)
|
||||
|
||||
## Authentication
|
||||
|
||||
If credentials for the given hostname are available in
|
||||
[the CLI config](/docs/commands/cli-config.html) then they will be included
|
||||
[the CLI config](/docs/cli/config/config-file.html) then they will be included
|
||||
in the request for the discovery document.
|
||||
|
||||
The credentials may also be provided to endpoints declared in the discovery
|
||||
|
|
|
@ -51,7 +51,7 @@ to signify that it is a lock file for various items that Terraform caches in
|
|||
the `.terraform` subdirectory of your working directory.
|
||||
|
||||
Terraform automatically creates or updates the dependency lock file each time
|
||||
you run [the `terraform init` command](/docs/commands/init.html). You should
|
||||
you run [the `terraform init` command](/docs/cli/commands/init.html). You should
|
||||
include this file in your version control repository so that you can discuss
|
||||
potential changes to your external dependencies via code review, just as you
|
||||
would discuss potential changes to your configuration itself.
|
||||
|
@ -139,7 +139,7 @@ There are two special considerations with the "trust on first use" model:
|
|||
|
||||
To avoid this problem you can pre-populate checksums for a variety of
|
||||
different platforms in your lock file using
|
||||
[the `terraform providers lock` command](/docs/commands/providers/lock.html),
|
||||
[the `terraform providers lock` command](/docs/cli/commands/providers/lock.html),
|
||||
which will then allow future calls to `terraform init` to verify that the
|
||||
packages available in your chosen mirror match the official packages from
|
||||
the provider's origin registry.
|
||||
|
@ -304,7 +304,7 @@ The two hashing schemes currently supported are:
|
|||
packages indexed in the origin registry. This is an effective scheme for
|
||||
verifying the official release packages when installed from a registry, but
|
||||
it's not suitable for verifying packages that come from other
|
||||
[provider installation methods](/docs/commands/cli-config.html#provider-installation),
|
||||
[provider installation methods](/docs/cli/config/config-file.html#provider-installation),
|
||||
such as filesystem mirrors using the unpacked directory layout.
|
||||
|
||||
* `h1:`: a mnemonic for "hash scheme 1", which is the current preferred hashing
|
||||
|
@ -345,7 +345,7 @@ your configuration on new target platforms, or if you are installing providers
|
|||
from a mirror that therefore can't provide official signed checksums, you
|
||||
can ask Terraform to pre-populate hashes for a chosen set of platforms
|
||||
using
|
||||
[the `terraform providers lock` command](/docs/commands/providers/lock.html):
|
||||
[the `terraform providers lock` command](/docs/cli/commands/providers/lock.html):
|
||||
|
||||
```
|
||||
terraform providers lock \
|
||||
|
|
|
@ -22,7 +22,7 @@ expressions.
|
|||
|
||||
You can experiment with the behavior of Terraform's expressions from
|
||||
the Terraform expression console, by running
|
||||
[the `terraform console` command](/docs/commands/console.html).
|
||||
[the `terraform console` command](/docs/cli/commands/console.html).
|
||||
|
||||
The other pages in this section describe the features of Terraform's
|
||||
expression syntax.
|
||||
|
|
|
@ -30,7 +30,7 @@ for this section includes a list of all of the available built-in functions.
|
|||
|
||||
You can experiment with the behavior of Terraform's built-in functions from
|
||||
the Terraform expression console, by running
|
||||
[the `terraform console` command](/docs/commands/console.html):
|
||||
[the `terraform console` command](/docs/cli/commands/console.html):
|
||||
|
||||
```
|
||||
> max(5, 12, 9)
|
||||
|
|
|
@ -6,7 +6,7 @@ page_title: "Overview - Configuration Language"
|
|||
# Terraform Language Documentation
|
||||
|
||||
This is the documentation for Terraform's configuration language. It is relevant
|
||||
to users of [Terraform CLI](/docs/cli-index.html),
|
||||
to users of [Terraform CLI](/docs/cli/index.html),
|
||||
[Terraform Cloud](/docs/cloud/index.html), and
|
||||
[Terraform Enterprise](/docs/enterprise/index.html).
|
||||
|
||||
|
|
|
@ -15,8 +15,8 @@ Modules can be used to create lightweight abstractions, so that you can
|
|||
describe your infrastructure in terms of its architecture, rather than
|
||||
directly in terms of physical objects.
|
||||
|
||||
The `.tf` files in your working directory when you run [`terraform plan`](/docs/commands/plan.html)
|
||||
or [`terraform apply`](/docs/commands/apply.html) together form the _root_
|
||||
The `.tf` files in your working directory when you run [`terraform plan`](/docs/cli/commands/plan.html)
|
||||
or [`terraform apply`](/docs/cli/commands/apply.html) together form the _root_
|
||||
module. That module may [call other modules](/docs/language/modules/syntax.html#calling-a-child-module)
|
||||
and connect them together by passing output values from one to input values
|
||||
of another.
|
||||
|
|
|
@ -129,7 +129,7 @@ You can learn more about the registry at the
|
|||
[Terraform Registry documentation](/docs/registry/modules/use.html#using-modules).
|
||||
|
||||
To access modules from a private registry, you may need to configure an access
|
||||
token [in the CLI config](/docs/commands/cli-config.html#credentials). Use the
|
||||
token [in the CLI config](/docs/cli/config/config-file.html#credentials). Use the
|
||||
same hostname as used in the module source string. For a private registry
|
||||
within Terraform Cloud, use the same authentication token as you would
|
||||
use with the Enterprise API or command-line clients.
|
||||
|
|
|
@ -168,7 +168,7 @@ after moving code across modules to ensure that no resources are deleted by
|
|||
surprise.
|
||||
|
||||
If you want to make sure an existing resource is preserved, use
|
||||
[the `terraform state mv` command](/docs/commands/state/mv.html) to inform
|
||||
[the `terraform state mv` command](/docs/cli/commands/state/mv.html) to inform
|
||||
Terraform that it has moved to a different module.
|
||||
|
||||
When passing resource addresses to `terraform state mv`, resources within child
|
||||
|
@ -186,7 +186,7 @@ elsewhere in your configuration.
|
|||
|
||||
## Tainting resources within a module
|
||||
|
||||
The [taint command](/docs/commands/taint.html) can be used to _taint_ specific
|
||||
The [taint command](/docs/cli/commands/taint.html) can be used to _taint_ specific
|
||||
resources within a module:
|
||||
|
||||
```shell
|
||||
|
|
|
@ -60,7 +60,7 @@ about it in your configuration. See the following pages for details:
|
|||
|
||||
To save time and bandwidth, Terraform CLI supports an optional plugin
|
||||
cache. You can enable the cache using the `plugin_cache_dir` setting in
|
||||
[the CLI configuration file](/docs/commands/cli-config.html).
|
||||
[the CLI configuration file](/docs/cli/config/config-file.html).
|
||||
|
||||
To ensure Terraform always installs the same provider versions for a given
|
||||
configuration, you can use Terraform CLI to create a
|
||||
|
|
|
@ -303,7 +303,7 @@ registry, by implementing
|
|||
|
||||
Running an additional service just to distribute a single provider internally
|
||||
may be undesirable, so Terraform also supports
|
||||
[other provider installation methods](/docs/commands/cli-config.html#provider-installation),
|
||||
[other provider installation methods](/docs/cli/config/config-file.html#provider-installation),
|
||||
including placing provider plugins directly in specific directories in the
|
||||
local filesystem, via _filesystem mirrors_.
|
||||
|
||||
|
@ -332,7 +332,7 @@ terraform {
|
|||
|
||||
To make version 1.0.0 of this provider available for installation from the
|
||||
local filesystem, choose one of the
|
||||
[implied local mirror directories](/docs/commands/cli-config.html#implied-local-mirror-directories)
|
||||
[implied local mirror directories](/docs/cli/config/config-file.html#implied-local-mirror-directories)
|
||||
and create a directory structure under it like this:
|
||||
|
||||
```
|
||||
|
|
|
@ -29,14 +29,14 @@ this section document how to configure and use backends.
|
|||
|
||||
## Where Backends are Used
|
||||
|
||||
Backend configuration is only used by [Terraform CLI](/docs/cli-index.html).
|
||||
Backend configuration is only used by [Terraform CLI](/docs/cli/index.html).
|
||||
Terraform Cloud and Terraform Enterprise always use their own state storage when
|
||||
performing Terraform runs, so they ignore any backend block in the
|
||||
configuration.
|
||||
|
||||
But since it's common to
|
||||
[use Terraform CLI alongside Terraform Cloud](/docs/cloud/run/cli.html)
|
||||
(and since certain state operations, like [tainting](/docs/commands/taint.html),
|
||||
(and since certain state operations, like [tainting](/docs/cli/commands/taint.html),
|
||||
can only be performed on the CLI), we recommend that Terraform Cloud users
|
||||
include a backend block in their configurations and configure the `remote`
|
||||
backend to use the relevant Terraform Cloud workspace(s).
|
||||
|
|
|
@ -85,7 +85,7 @@ This backend creates one table **states** in the automatically-managed Postgres
|
|||
|
||||
The table is keyed by the [workspace](/docs/language/state/workspaces.html) name. If workspaces are not in use, the name `default` is used.
|
||||
|
||||
Locking is supported using [Postgres advisory locks](https://www.postgresql.org/docs/9.5/explicit-locking.html#ADVISORY-LOCKS). [`force-unlock`](https://www.terraform.io/docs/commands/force-unlock.html) is not supported, because these database-native locks will automatically unlock when the session is aborted or the connection fails. To see outstanding locks in a Postgres server, use the [`pg_locks` system view](https://www.postgresql.org/docs/9.5/view-pg-locks.html).
|
||||
Locking is supported using [Postgres advisory locks](https://www.postgresql.org/docs/9.5/explicit-locking.html#ADVISORY-LOCKS). [`force-unlock`](https://www.terraform.io/docs/cli/commands/force-unlock.html) is not supported, because these database-native locks will automatically unlock when the session is aborted or the connection fails. To see outstanding locks in a Postgres server, use the [`pg_locks` system view](https://www.postgresql.org/docs/9.5/view-pg-locks.html).
|
||||
|
||||
The **states** table contains:
|
||||
|
||||
|
|
|
@ -94,8 +94,8 @@ running any remote operations against them.
|
|||
## Example Configurations
|
||||
|
||||
-> **Note:** We recommend omitting the token from the configuration, and instead using
|
||||
[`terraform login`](/docs/commands/login.html) or manually configuring
|
||||
`credentials` in the [CLI config file](/docs/commands/cli-config.html#credentials).
|
||||
[`terraform login`](/docs/cli/commands/login.html) or manually configuring
|
||||
`credentials` in the [CLI config file](/docs/cli/config/config-file.html#credentials).
|
||||
|
||||
### Basic Configuration
|
||||
|
||||
|
@ -177,9 +177,9 @@ The following configuration options are supported:
|
|||
targeted workspace(s).
|
||||
* `token` - (Optional) The token used to authenticate with the remote backend.
|
||||
We recommend omitting the token from the configuration, and instead using
|
||||
[`terraform login`](/docs/commands/login.html) or manually configuring
|
||||
[`terraform login`](/docs/cli/commands/login.html) or manually configuring
|
||||
`credentials` in the
|
||||
[CLI config file](/docs/commands/cli-config.html#credentials).
|
||||
[CLI config file](/docs/cli/config/config-file.html#credentials).
|
||||
* `workspaces` - (Required) A block specifying which remote workspace(s) to use.
|
||||
The `workspaces` block supports the following keys:
|
||||
|
||||
|
|
|
@ -12,4 +12,4 @@ Terraform is able to import existing infrastructure. This allows you take
|
|||
resources you've created by some other means and bring it under Terraform management.
|
||||
|
||||
To learn more about this, please visit the
|
||||
[pages dedicated to import](/docs/import/index.html).
|
||||
[pages dedicated to import](/docs/cli/import/index.html).
|
||||
|
|
|
@ -18,7 +18,7 @@ but it can also be stored remotely, which works better in a team environment.
|
|||
|
||||
Terraform uses this local state to create plans and make changes to your
|
||||
infrastructure. Prior to any operation, Terraform does a
|
||||
[refresh](/docs/commands/refresh.html) to update the state with the
|
||||
[refresh](/docs/cli/commands/refresh.html) to update the state with the
|
||||
real infrastructure.
|
||||
|
||||
The primary purpose of Terraform state is to store bindings between objects in
|
||||
|
@ -35,7 +35,7 @@ function without state, please see the page [state purpose](/docs/language/state
|
|||
|
||||
While the format of the state files are just JSON, direct file editing
|
||||
of the state is discouraged. Terraform provides the
|
||||
[terraform state](/docs/commands/state/index.html) command to perform
|
||||
[terraform state](/docs/cli/commands/state/index.html) command to perform
|
||||
basic modifications of the state using the CLI.
|
||||
|
||||
The CLI usage and output of the state commands is structured to be
|
||||
|
@ -68,10 +68,10 @@ in new versions.
|
|||
Alternatively, there are several integration points which produce JSON output
|
||||
that is specifically intended for consumption by external software:
|
||||
|
||||
* [The `terraform output` command](/docs/commands/output.html)
|
||||
* [The `terraform output` command](/docs/cli/commands/output.html)
|
||||
has a `-json` option, for obtaining either the full set of root module output
|
||||
values or a specific named output value from the latest state snapshot.
|
||||
* [The `terraform show` command](/docs/commands/show.html) has a `-json`
|
||||
* [The `terraform show` command](/docs/cli/commands/show.html) has a `-json`
|
||||
option for inspecting the latest state snapshot in full, and also for
|
||||
inspecting saved plan files which include a copy of the prior state at the
|
||||
time the plan was made.
|
||||
|
|
|
@ -27,7 +27,7 @@ includes details on whether it supports locking or not.
|
|||
|
||||
## Force Unlock
|
||||
|
||||
Terraform has a [force-unlock command](/docs/commands/force-unlock.html)
|
||||
Terraform has a [force-unlock command](/docs/cli/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
|
||||
|
|
|
@ -18,4 +18,4 @@ section offer a more abstract view of the Terraform language.
|
|||
don't have a readily available HCL library.
|
||||
- [Style Conventions](/docs/language/syntax/style.html) documents some commonly
|
||||
accepted formatting guidelines for Terraform code. These conventions can be
|
||||
enforced automatically with [`terraform fmt`](/docs/commands/fmt.html).
|
||||
enforced automatically with [`terraform fmt`](/docs/cli/commands/fmt.html).
|
||||
|
|
|
@ -186,7 +186,7 @@ structure. This structure has the following fields:
|
|||
you may keep that field nil.
|
||||
|
||||
* `Importer` - If this is non-nil, then this resource is
|
||||
[importable](/docs/import/importability.html). It is recommended to
|
||||
[importable](/docs/cli/import/importability.html). It is recommended to
|
||||
implement this.
|
||||
|
||||
The CRUD operations in more detail, along with their contracts:
|
||||
|
|
|
@ -28,7 +28,7 @@ in the navigation) if you are upgrading directly from an earlier version.
|
|||
As of v0.10, provider plugins are no longer included in the main Terraform
|
||||
distribution. Instead, they are distributed separately and installed
|
||||
automatically by
|
||||
[the `terraform init` command](/docs/commands/init.html).
|
||||
[the `terraform init` command](/docs/cli/commands/init.html).
|
||||
|
||||
In the long run, this new approach should be beneficial to anyone who wishes
|
||||
to upgrade a specific provider to get new functionality without also
|
||||
|
@ -104,9 +104,9 @@ For example, if `module.example` contains a module itself, called
|
|||
`module.example` _and_ `module.example.module.examplechild`.
|
||||
|
||||
This also applies to other Terraform features that use
|
||||
[resource addressing](/docs/internals/resource-addressing.html) syntax.
|
||||
[resource addressing](/docs/cli/state/resource-addressing.html) syntax.
|
||||
This includes some of the subcommands of
|
||||
[`terraform state`](/docs/commands/state/index.html).
|
||||
[`terraform state`](/docs/cli/commands/state/index.html).
|
||||
|
||||
**Action:** If running Terraform with `-target` in automation, review usage
|
||||
to ensure that selecting additional resources in child modules will not have
|
||||
|
|
|
@ -16,7 +16,7 @@ to cover the most common upgrade concerns and issues.
|
|||
For most users, upgrading configuration should be completely automatic. Some
|
||||
simple configurations will require no changes at all, and most other
|
||||
configurations can be prepared by running
|
||||
[the automatic upgrade tool](/docs/commands/0.12upgrade.html). Please read on
|
||||
[the automatic upgrade tool](/docs/cli/commands/0.12upgrade.html). Please read on
|
||||
for more information and recommendations on the upgrade process.
|
||||
|
||||
-> If you are a developer maintaining a provider plugin, please see
|
||||
|
|
|
@ -117,7 +117,7 @@ following command:
|
|||
|
||||
As mentioned in the error message, Terraform v0.13 includes an automatic
|
||||
upgrade command
|
||||
[`terraform 0.13upgrade`](/docs/commands/0.13upgrade.html)
|
||||
[`terraform 0.13upgrade`](/docs/cli/commands/0.13upgrade.html)
|
||||
that is able to automatically generate source addresses for unlabelled
|
||||
providers by consulting the same lookup table that was previously used for
|
||||
Terraform v0.12 provider installation. This command will automatically modify
|
||||
|
@ -140,7 +140,7 @@ version constraint for Terraform v0.13 or later, which you can weaken to
|
|||
Each module must declare its own set of provider requirements, so if you have
|
||||
a configuration which calls other modules then you'll need to run this upgrade
|
||||
command for each module separately.
|
||||
[The `terraform 0.13upgrade documentation`](/docs/commands/0.13upgrade.html)
|
||||
[The `terraform 0.13upgrade documentation`](/docs/cli/commands/0.13upgrade.html)
|
||||
includes an example of running the upgrade process across all directories under
|
||||
a particular prefix that contain `.tf` files using some common Unix command line
|
||||
tools, which may be useful if you want to upgrade all modules in a single
|
||||
|
@ -149,7 +149,7 @@ repository at once.
|
|||
After you've added explicit provider source addresses to your configuration,
|
||||
run `terraform init` again to re-run the provider installer.
|
||||
|
||||
-> **Action:** Either run [`terraform 0.13upgrade`](/docs/commands/0.13upgrade.html) for each of your modules, or manually update the provider declarations to use explicit source addresses.
|
||||
-> **Action:** Either run [`terraform 0.13upgrade`](/docs/cli/commands/0.13upgrade.html) for each of your modules, or manually update the provider declarations to use explicit source addresses.
|
||||
|
||||
The upgrade tool described above only updates references in your configuration.
|
||||
The Terraform state also includes references to provider configurations which
|
||||
|
@ -232,12 +232,12 @@ Terraform under:
|
|||
|
||||
Terraform v0.13 introduces some additional options for customizing where
|
||||
Terraform looks for providers in the local filesystem. For more information on
|
||||
those new options, see [Provider Installation](/docs/commands/cli-config.html#provider-installation).
|
||||
those new options, see [Provider Installation](/docs/cli/config/config-file.html#provider-installation).
|
||||
|
||||
If you use only providers that are automatically installable from Terraform
|
||||
provider registries but still want to avoid Terraform re-downloading them from
|
||||
registries each time, Terraform v0.13 includes
|
||||
[the `terraform providers mirror` command](/docs/commands/providers/mirror.html)
|
||||
[the `terraform providers mirror` command](/docs/cli/commands/providers/mirror.html)
|
||||
which you can use to automatically populate a local directory based on the
|
||||
requirements of the current configuration file:
|
||||
|
||||
|
|
|
@ -159,7 +159,7 @@ network mirrors:
|
|||
across a mixture of platforms then, in addition to making sure that your
|
||||
mirrors include packages for all of the necessary platforms, you may choose
|
||||
to use
|
||||
[the new `terraform providers lock` command](/docs/commands/providers/lock.html)
|
||||
[the new `terraform providers lock` command](/docs/cli/commands/providers/lock.html)
|
||||
to pre-enter the required lock file entries for all of the platforms you
|
||||
intend to use.
|
||||
|
||||
|
@ -265,9 +265,9 @@ Cloud in particular that this approach was previously mis-documented.
|
|||
|
||||
If you aren't intending to upload the provider plugin to Terraform Cloud as
|
||||
part of your configuration, we recommend instead installing to one of
|
||||
[the other implied mirror directories](/docs/commands/cli-config.html#implied-local-mirror-directories),
|
||||
[the other implied mirror directories](/docs/cli/config/config-file.html#implied-local-mirror-directories),
|
||||
or you can explicitly configure some
|
||||
[custom provider installation methods](/docs/commands/cli-config.html#provider-installation)
|
||||
[custom provider installation methods](/docs/cli/config/config-file.html#provider-installation)
|
||||
if your needs are more complicated.
|
||||
|
||||
## Concise Terraform Plan Output
|
||||
|
|
Loading…
Reference in New Issue