website: Update all links to {expressions,modules,resources}.html
...as well as to the standard module structure section in module development.
This commit is contained in:
parent
209541aaf0
commit
2bfec75bbf
|
@ -15,7 +15,7 @@ potentially save you time and effort.
|
|||
|
||||
- [The `terraform console` command](/docs/commands/console.html) starts an
|
||||
interactive shell for evaluating Terraform
|
||||
[expressions](/docs/configuration/expressions.html), which can be a faster way
|
||||
[expressions](/docs/configuration/expressions/index.html), which can be a faster way
|
||||
to verify that a particular resource argument results in the value you expect.
|
||||
|
||||
|
||||
|
|
|
@ -71,7 +71,7 @@ the change.
|
|||
Once upgraded the configuration will no longer be compatible with Terraform
|
||||
v0.11 and earlier. When upgrading a shared module that is called from multiple
|
||||
configurations, you may need to
|
||||
[fix existing configurations to a previous version](/docs/configuration/modules.html#module-versions)
|
||||
[fix existing configurations to a previous version](/docs/configuration/blocks/modules/syntax.html#version)
|
||||
to allow for a gradual upgrade. If the module is published via
|
||||
[a Terraform registry](/docs/registry/), assign a new _major_ version number
|
||||
to the upgraded module source to represent the fact that this is a breaking
|
||||
|
|
|
@ -10,14 +10,14 @@ description: |-
|
|||
# Command: console
|
||||
|
||||
The `terraform console` command provides an interactive console for
|
||||
evaluating [expressions](/docs/configuration/expressions.html).
|
||||
evaluating [expressions](/docs/configuration/expressions/index.html).
|
||||
|
||||
## Usage
|
||||
|
||||
Usage: `terraform console [options]`
|
||||
|
||||
This command provides an interactive command-line console for evaluating and
|
||||
experimenting with [expressions](/docs/configuration/expressions.html).
|
||||
experimenting with [expressions](/docs/configuration/expressions/index.html).
|
||||
This is useful for testing interpolations before using them in configurations,
|
||||
and for interacting with any values currently saved in
|
||||
[state](/docs/state/index.html).
|
||||
|
|
|
@ -133,7 +133,7 @@ $ terraform import module.foo.aws_instance.bar i-abcd1234
|
|||
## Example: Import into Resource configured with count
|
||||
|
||||
The example below will import an AWS instance into the first instance of the `aws_instance` resource named `baz` configured with
|
||||
[`count`](/docs/configuration/resources.html#count-multiple-resource-instances-by-count):
|
||||
[`count`](/docs/configuration/meta-arguments/count.html):
|
||||
|
||||
```shell
|
||||
$ terraform import 'aws_instance.baz[0]' i-abcd1234
|
||||
|
@ -142,7 +142,7 @@ $ terraform import 'aws_instance.baz[0]' i-abcd1234
|
|||
## Example: Import into Resource configured with for_each
|
||||
|
||||
The example below will import an AWS instance into the `"example"` instance of the `aws_instance` resource named `baz` configured with
|
||||
[`for_each`](/docs/configuration/resources.html#for_each-multiple-resource-instances-defined-by-a-map-or-set-of-strings):
|
||||
[`for_each`](/docs/configuration/meta-arguments/for_each.html):
|
||||
|
||||
Linux, Mac OS, and UNIX:
|
||||
|
||||
|
|
|
@ -95,7 +95,7 @@ $ terraform state mv -state-out=other.tfstate 'module.app' 'module.app'
|
|||
## Example: Move a Resource configured with count
|
||||
|
||||
The example below moves the first instance of a `packet_device` resource named `worker` configured with
|
||||
[`count`](/docs/configuration/resources.html#count-multiple-resource-instances-by-count) to
|
||||
[`count`](/docs/configuration/meta-arguments/count.html) to
|
||||
the first instance of a resource named `helper` also configured with `count`:
|
||||
|
||||
```shell
|
||||
|
@ -105,7 +105,7 @@ $ terraform state mv 'packet_device.worker[0]' 'packet_device.helper[0]'
|
|||
## Example: Move a Resource configured with for_each
|
||||
|
||||
The example below moves the `"example123"` instance of a `packet_device` resource named `worker` configured with
|
||||
[`for_each`](/docs/configuration/resources.html#for_each-multiple-resource-instances-defined-by-a-map-or-set-of-strings)
|
||||
[`for_each`](/docs/configuration/meta-arguments/for_each.html)
|
||||
to the `"example456"` instance of a resource named `helper` also configuring `for_each`:
|
||||
|
||||
Linux, Mac OS, and UNIX:
|
||||
|
|
|
@ -78,7 +78,7 @@ $ terraform state rm 'module.foo.packet_device.worker'
|
|||
## Example: Remove a Resource configured with count
|
||||
|
||||
The example below removes the first instance of a `packet_device` resource named `worker` configured with
|
||||
[`count`](/docs/configuration/resources.html#count-multiple-resource-instances-by-count):
|
||||
[`count`](/docs/configuration/meta-arguments/count.html):
|
||||
|
||||
```shell
|
||||
$ terraform state rm 'packet_device.worker[0]'
|
||||
|
@ -87,7 +87,7 @@ $ terraform state rm 'packet_device.worker[0]'
|
|||
## Example: Remove a Resource configured with for_each
|
||||
|
||||
The example below removes the `"example"` instance of a `packet_device` resource named `worker` configured with
|
||||
[`for_each`](/docs/configuration/resources.html#for_each-multiple-resource-instances-defined-by-a-map-or-set-of-strings):
|
||||
[`for_each`](/docs/configuration/meta-arguments/for_each.html):
|
||||
|
||||
Linux, Mac OS, and UNIX:
|
||||
|
||||
|
|
|
@ -61,7 +61,7 @@ $ terraform state show 'module.foo.packet_device.worker'
|
|||
## Example: Show a Resource configured with count
|
||||
|
||||
The example below shows the first instance of a `packet_device` resource named `worker` configured with
|
||||
[`count`](/docs/configuration/resources.html#count-multiple-resource-instances-by-count):
|
||||
[`count`](/docs/configuration/meta-arguments/count.html):
|
||||
|
||||
```shell
|
||||
$ terraform state show 'packet_device.worker[0]'
|
||||
|
@ -70,7 +70,7 @@ $ terraform state show 'packet_device.worker[0]'
|
|||
## Example: Show a Resource configured with for_each
|
||||
|
||||
The example below shows the `"example"` instance of a `packet_device` resource named `worker` configured with
|
||||
[`for_each`](/docs/configuration/resources.html#for_each-multiple-resource-instances-defined-by-a-map-or-set-of-strings):
|
||||
[`for_each`](/docs/configuration/meta-arguments/for_each.html):
|
||||
|
||||
Linux, Mac OS, and UNIX:
|
||||
|
||||
|
|
|
@ -10,7 +10,7 @@ description: |-
|
|||
|
||||
-> **Note:** This page is about Terraform 0.11 and earlier. For Terraform 0.12
|
||||
and later, see
|
||||
[Configuration Language: Expressions](../configuration/expressions.html) and
|
||||
[Configuration Language: Expressions](/docs/configuration/expressions/index.html) and
|
||||
[Configuration Language: Functions](../configuration/functions.html).
|
||||
|
||||
Embedded within strings in Terraform, whether you're using the
|
||||
|
|
|
@ -153,7 +153,7 @@ example = [
|
|||
|
||||
For the arguments that use the attributes-as-blocks usage mode, the above is
|
||||
a better pattern than using
|
||||
[`dynamic` blocks](/docs/configuration/expressions.html#dynamic-blocks)
|
||||
[`dynamic` blocks](/docs/configuration/expressions/dynamic-blocks.html)
|
||||
because the case where the
|
||||
caller provides an empty list will result in explicitly assigning an empty
|
||||
list value, rather than assigning no value at all and thus retaining and
|
||||
|
|
|
@ -13,7 +13,7 @@ configuration (like endpoint URLs or cloud regions) before they can be used.
|
|||
|
||||
## What Providers Do
|
||||
|
||||
Each provider adds a set of [resource types](/docs/configuration/resources.html)
|
||||
Each provider adds a set of [resource types](/docs/configuration/blocks/resources/index.html)
|
||||
and/or [data sources](/docs/configuration/data-sources.html) that Terraform can
|
||||
manage.
|
||||
|
||||
|
|
|
@ -18,7 +18,8 @@ configuration to make use of information defined outside of Terraform,
|
|||
or defined by another separate Terraform configuration.
|
||||
|
||||
Each [provider](./providers.html) may offer data sources
|
||||
alongside its set of [resource types](./resources.html#resource-types-and-arguments).
|
||||
alongside its set of [resource](/docs/configuration/blocks/resources/index.html)
|
||||
types.
|
||||
|
||||
## Using Data Sources
|
||||
|
||||
|
@ -71,7 +72,7 @@ infrastructure platform.
|
|||
|
||||
Most of the items within the body of a `data` block are defined by and
|
||||
specific to the selected data source, and these arguments can make full
|
||||
use of [expressions](./expressions.html) and other dynamic
|
||||
use of [expressions](/docs/configuration/expressions/index.html) and other dynamic
|
||||
Terraform language features.
|
||||
|
||||
However, there are some "meta-arguments" that are defined by Terraform itself
|
||||
|
@ -113,7 +114,7 @@ operation, and is re-calculated each time a new plan is created.
|
|||
## Data Resource Dependencies
|
||||
|
||||
Data resources have the same dependency resolution behavior
|
||||
[as defined for managed resources](./resources.html#resource-dependencies).
|
||||
[as defined for managed resources](/docs/configuration/blocks/resources/behavior.html#resource-dependencies).
|
||||
Setting the `depends_on` meta-argument within `data` blocks defers reading of
|
||||
the data source until after all changes to the dependencies have been applied.
|
||||
|
||||
|
@ -122,8 +123,8 @@ the data source until after all changes to the dependencies have been applied.
|
|||
|
||||
## Multiple Resource Instances
|
||||
|
||||
Data resources support [`count`](./resources.html#count-multiple-resource-instances-by-count)
|
||||
and [`for_each`](./resources.html#for_each-multiple-resource-instances-defined-by-a-map-or-set-of-strings)
|
||||
Data resources support [`count`](/docs/configuration/meta-arguments/count.html)
|
||||
and [`for_each`](/docs/configuration/meta-arguments/for_each.html)
|
||||
meta-arguments as defined for managed resources, with the same syntax and behavior.
|
||||
|
||||
As with managed resources, when `count` or `for_each` is present it is important to
|
||||
|
@ -133,7 +134,7 @@ own variant of the constraint arguments, producing an indexed result.
|
|||
|
||||
## Selecting a Non-default Provider Configuration
|
||||
|
||||
Data resources support [the `provider` meta-argument](./resources.html#provider-selecting-a-non-default-provider-configuration)
|
||||
Data resources support [the `provider` meta-argument](/docs/configuration/meta-arguments/resource-provider.html)
|
||||
as defined for managed resources, with the same syntax and behavior.
|
||||
|
||||
## Lifecycle Customizations
|
||||
|
@ -187,13 +188,15 @@ resource "aws_instance" "web" {
|
|||
## Meta-Arguments
|
||||
|
||||
As data sources are essentially a read only subset of resources, they also
|
||||
support the same [meta-arguments](./resources.html#meta-arguments) of resources
|
||||
support the same [meta-arguments](/docs/configuration/blocks/resources/syntax.html#meta-arguments) of resources
|
||||
with the exception of the
|
||||
[`lifecycle` configuration block](./resources.html#lifecycle-lifecycle-customizations).
|
||||
[`lifecycle` configuration block](/docs/configuration/meta-arguments/lifecycle.html).
|
||||
|
||||
### Non-Default Provider Configurations
|
||||
|
||||
Similarly to [resources](./resources.html), when a module has multiple configurations for the same provider you can specify which configuration to use with the `provider` meta-argument:
|
||||
Similarly to [resources](/docs/configuration/blocks/resources/index.html), when
|
||||
a module has multiple configurations for the same provider you can specify which
|
||||
configuration to use with the `provider` meta-argument:
|
||||
|
||||
```hcl
|
||||
data "aws_ami" "web" {
|
||||
|
@ -204,7 +207,7 @@ data "aws_ami" "web" {
|
|||
```
|
||||
|
||||
See
|
||||
[Resources: Selecting a Non-Default Provider Configuration](./resources.html#provider-selecting-a-non-default-provider-configuration)
|
||||
[The Resource `provider` Meta-Argument](/docs/configuration/meta-arguments/resource-provider.html)
|
||||
for more information.
|
||||
|
||||
## Data Source Lifecycle
|
||||
|
|
|
@ -14,9 +14,9 @@ dependency that come from outside of its own codebase:
|
|||
|
||||
* [Providers](./provider-requirements.html), which are plugins for Terraform
|
||||
that extend it with support for interacting with various external systems.
|
||||
* [Modules](./modules.html), which allow splitting out groups of Terraform
|
||||
configuration constructs (written in the Terraform language) into reusable
|
||||
abstractions.
|
||||
* [Modules](/docs/configuration/blocks/modules/index.html), which allow
|
||||
splitting out groups of Terraform configuration constructs (written in the
|
||||
Terraform language) into reusable abstractions.
|
||||
|
||||
Both of these dependency types can be published and updated independently from
|
||||
Terraform itself and from the configurations that depend on them. For that
|
||||
|
|
|
@ -34,7 +34,7 @@ treating the entire module as a single document. Separating various blocks into
|
|||
different files is purely for the convenience of readers and maintainers, and
|
||||
has no effect on the module's behavior.
|
||||
|
||||
A Terraform module can use [module calls](/docs/configuration/modules.html) to
|
||||
A Terraform module can use [module calls](/docs/configuration/blocks/modules/index.html) to
|
||||
explicitly include other modules into the configuration. These child modules can
|
||||
come from local directories (nested in the parent module's directory, or
|
||||
anywhere else on disk), or from external sources like the
|
||||
|
|
|
@ -23,8 +23,8 @@ max(5, 12, 9)
|
|||
```
|
||||
|
||||
For more details on syntax, see
|
||||
[_Function Calls_](./expressions.html#function-calls)
|
||||
on the Expressions page.
|
||||
[_Function Calls_](/docs/configuration/expressions/function-calls.html)
|
||||
in the Expressions section.
|
||||
|
||||
The Terraform language does not support user-defined functions, and so only
|
||||
the functions built in to the language are available for use. The navigation
|
||||
|
|
|
@ -70,7 +70,7 @@ platforms.
|
|||
```
|
||||
|
||||
You can use nested `cidrsubnets` calls with
|
||||
[`for` expressions](/docs/configuration/expressions.html#for-expressions)
|
||||
[`for` expressions](/docs/configuration/expressions/for.html)
|
||||
to concisely allocate groups of network address blocks:
|
||||
|
||||
```
|
||||
|
|
|
@ -46,7 +46,7 @@ number of fields, or this function will produce an error.
|
|||
## Use with the `for_each` meta-argument
|
||||
|
||||
You can use the result of `csvdecode` with
|
||||
[the `for_each` meta-argument](/docs/configuration/resources.html#for_each-multiple-resource-instances-defined-by-a-map-or-set-of-strings)
|
||||
[the `for_each` meta-argument](/docs/configuration/meta-arguments/for_each.html)
|
||||
to describe a collection of similar objects whose differences are
|
||||
described by the rows in the given CSV file.
|
||||
|
||||
|
@ -94,7 +94,7 @@ create or destroy associated instances as appropriate.
|
|||
|
||||
If there is no reasonable value you can use as a unique identifier in your CSV
|
||||
then you could instead use
|
||||
[the `count` meta-argument](/docs/configuration/resources.html#count-multiple-resource-instances-by-count)
|
||||
[the `count` meta-argument](/docs/configuration/meta-arguments/count.html)
|
||||
to define an object for each CSV row, with each one identified by its index into
|
||||
the list returned by `csvdecode`. However, in that case any future updates to
|
||||
the CSV may be disruptive if they change the positions of particular objects in
|
||||
|
|
|
@ -69,7 +69,7 @@ before Terraform takes any actions.
|
|||
```
|
||||
|
||||
A common use of `fileset` is to create one resource instance per matched file, using
|
||||
[the `for_each` meta-argument](/docs/configuration/resources.html#for_each-multiple-resource-instances-defined-by-a-map-or-set-of-strings):
|
||||
[the `for_each` meta-argument](/docs/configuration/meta-arguments/for_each.html):
|
||||
|
||||
```hcl
|
||||
resource "example_thing" "example" {
|
||||
|
|
|
@ -35,9 +35,9 @@ Indirectly-nested lists, such as those in maps, are _not_ flattened.
|
|||
## Flattening nested structures for `for_each`
|
||||
|
||||
The
|
||||
[resource `for_each`](/docs/configuration/resources.html#for_each-multiple-resource-instances-defined-by-a-map-or-set-of-strings)
|
||||
[resource `for_each`](/docs/configuration/meta-arguments/for_each.html)
|
||||
and
|
||||
[`dynamic` block](/docs/configuration/expressions.html#dynamic-blocks)
|
||||
[`dynamic` block](/docs/configuration/expressions/dynamic-blocks.html)
|
||||
language features both require a collection value that has one element for
|
||||
each repetition.
|
||||
|
||||
|
|
|
@ -19,7 +19,7 @@ of the result of decoding that string.
|
|||
The JSON encoding is defined in [RFC 7159](https://tools.ietf.org/html/rfc7159).
|
||||
|
||||
This function maps JSON values to
|
||||
[Terraform language values](../expressions.html#types-and-values)
|
||||
[Terraform language values](/docs/configuration/expressions/types.html)
|
||||
in the following way:
|
||||
|
||||
| JSON type | Terraform type |
|
||||
|
|
|
@ -17,7 +17,7 @@ earlier, see
|
|||
The JSON encoding is defined in [RFC 7159](https://tools.ietf.org/html/rfc7159).
|
||||
|
||||
This function maps
|
||||
[Terraform language values](../expressions.html#types-and-values)
|
||||
[Terraform language values](/docs/configuration/expressions/types.html)
|
||||
to JSON values in the following way:
|
||||
|
||||
| Terraform type | JSON type |
|
||||
|
|
|
@ -121,9 +121,9 @@ elements all have a consistent type:
|
|||
## Finding combinations for `for_each`
|
||||
|
||||
The
|
||||
[resource `for_each`](/docs/configuration/resources.html#for_each-multiple-resource-instances-defined-by-a-map-or-set-of-strings)
|
||||
[resource `for_each`](/docs/configuration/meta-arguments/for_each.html)
|
||||
and
|
||||
[`dynamic` block](/docs/configuration/expressions.html#dynamic-blocks)
|
||||
[`dynamic` block](/docs/configuration/expressions/dynamic-blocks.html)
|
||||
language features both require a collection value that has one element for
|
||||
each repetition.
|
||||
|
||||
|
|
|
@ -21,10 +21,10 @@ templatefile(path, vars)
|
|||
```
|
||||
|
||||
The template syntax is the same as for
|
||||
[string templates](../expressions.html#string-templates) in the main Terraform
|
||||
language, including interpolation sequences delimited with `${` ... `}`.
|
||||
This function just allows longer template sequences to be factored out
|
||||
into a separate file for readability.
|
||||
[string templates](/docs/configuration/expressions/strings.html#string-templates)
|
||||
in the main Terraform language, including interpolation sequences delimited with
|
||||
`${` ... `}`. This function just allows longer template sequences to be factored
|
||||
out into a separate file for readability.
|
||||
|
||||
The "vars" argument must be a map. Within the template file, each of the keys
|
||||
in the map is available as a variable for interpolation. The template may
|
||||
|
@ -102,7 +102,7 @@ interpolation sequences and directives.
|
|||
Instead, you can write a template that consists only of a single interpolated
|
||||
call to either [`jsonencode`](./jsonencode.html) or
|
||||
[`yamlencode`](./yamlencode.html), specifying the value to encode using
|
||||
[normal Terraform expression syntax](/docs/configuration/expressions.html)
|
||||
[normal Terraform expression syntax](/docs/configuration/expressions/index.html)
|
||||
as in the following examples:
|
||||
|
||||
```
|
||||
|
@ -122,9 +122,9 @@ this will produce a valid JSON or YAML representation of the given data
|
|||
structure, without the need to manually handle escaping or delimiters.
|
||||
In the latest examples above, the repetition based on elements of `ip_addrs` is
|
||||
achieved by using a
|
||||
[`for` expression](/docs/configuration/expressions.html#for-expressions)
|
||||
[`for` expression](/docs/configuration/expressions/for.html)
|
||||
rather than by using
|
||||
[template directives](/docs/configuration/expressions.html#directives).
|
||||
[template directives](/docs/configuration/expressions/strings.html#directives).
|
||||
|
||||
```json
|
||||
{"backends":["10.0.0.1:8080","10.0.0.2:8080"]}
|
||||
|
|
|
@ -24,7 +24,7 @@ The result of this function will change every second, so using this function
|
|||
directly with resource attributes will cause a diff to be detected on every
|
||||
Terraform run. We do not recommend using this function in resource attributes,
|
||||
but in rare cases it can be used in conjunction with
|
||||
[the `ignore_changes` lifecycle meta-argument](../resources.html#ignore_changes)
|
||||
[the `ignore_changes` lifecycle meta-argument](/docs/configuration/meta-arguments/lifecycle.html#ignore_changes)
|
||||
to take the timestamp only on initial creation of the resource. For more stable
|
||||
time handling, see the [Time Provider](https://registry.terraform.io/providers/hashicorp/time/).
|
||||
|
||||
|
|
|
@ -23,7 +23,7 @@ This function produces a new value each time it is called, and so using it
|
|||
directly in resource arguments will result in spurious diffs. We do not
|
||||
recommend using the `uuid` function in resource configurations, but it can
|
||||
be used with care in conjunction with
|
||||
[the `ignore_changes` lifecycle meta-argument](../resources.html#ignore_changes).
|
||||
[the `ignore_changes` lifecycle meta-argument](/docs/configuration/meta-arguments/lifecycle.html#ignore_changes).
|
||||
|
||||
In most cases we recommend using [the `random` provider](/docs/providers/random/index.html)
|
||||
instead, since it allows the one-time generation of random values that are
|
||||
|
|
|
@ -20,7 +20,7 @@ This function supports a subset of [YAML 1.2](https://yaml.org/spec/1.2/spec.htm
|
|||
as described below.
|
||||
|
||||
This function maps YAML values to
|
||||
[Terraform language values](../expressions.html#types-and-values)
|
||||
[Terraform language values](/docs/configuration/expressions/types.html)
|
||||
in the following way:
|
||||
|
||||
| YAML type | Terraform type |
|
||||
|
|
|
@ -33,7 +33,7 @@ results are also valid YAML because YAML is a JSON superset.
|
|||
-->
|
||||
|
||||
This function maps
|
||||
[Terraform language values](../expressions.html#types-and-values)
|
||||
[Terraform language values](/docs/configuration/expressions/types.html)
|
||||
to YAML tags in the following way:
|
||||
|
||||
| Terraform type | YAML type |
|
||||
|
|
|
@ -19,7 +19,7 @@ heart of the workflow.
|
|||
## About the Terraform Language
|
||||
|
||||
The main purpose of the Terraform language is declaring
|
||||
[resources](./resources.html), which represent infrastructure objects. All other
|
||||
[resources](/docs/configuration/blocks/resources/index.html), which represent infrastructure objects. All other
|
||||
language features exist only to make the definition of resources more flexible
|
||||
and convenient.
|
||||
|
||||
|
|
|
@ -13,7 +13,7 @@ description: |-
|
|||
earlier, see
|
||||
[0.11 Configuration Language: Local Values](../configuration-0-11/locals.html).
|
||||
|
||||
A local value assigns a name to an [expression](./expressions.html),
|
||||
A local value assigns a name to an [expression](/docs/configuration/expressions/index.html),
|
||||
so you can use it multiple times within a module without repeating
|
||||
it.
|
||||
|
||||
|
@ -61,7 +61,7 @@ locals {
|
|||
## Using Local Values
|
||||
|
||||
Once a local value is declared, you can reference it in
|
||||
[expressions](./expressions.html) as `local.<NAME>`.
|
||||
[expressions](/docs/configuration/expressions/index.html) as `local.<NAME>`.
|
||||
|
||||
-> **Note:** Local values are _created_ by a `locals` block (plural), but you
|
||||
_reference_ them as attributes on an object named `local` (singular). Make sure
|
||||
|
|
|
@ -46,7 +46,7 @@ valid [identifier](./syntax.html#identifiers). In a root module, this name is
|
|||
displayed to the user; in a child module, it can be used to access the output's
|
||||
value.
|
||||
|
||||
The `value` argument takes an [expression](./expressions.html)
|
||||
The `value` argument takes an [expression](/docs/configuration/expressions/index.html)
|
||||
whose result is to be returned to the user. In this example, the expression
|
||||
refers to the `private_ip` attribute exposed by an `aws_instance` resource
|
||||
defined elsewhere in this module (not shown). Any valid expression is allowed
|
||||
|
@ -163,7 +163,7 @@ correctly determine the dependencies between resources defined in different
|
|||
modules.
|
||||
|
||||
Just as with
|
||||
[resource dependencies](./resources.html#resource-dependencies),
|
||||
[resource dependencies](/docs/configuration/blocks/resources/behavior.html#resource-dependencies),
|
||||
Terraform analyzes the `value` expression for an output value and automatically
|
||||
determines a set of dependencies, but in less-common cases there are
|
||||
dependencies that cannot be recognized implicitly. In these rare cases, the
|
||||
|
|
|
@ -28,7 +28,8 @@ configuration (like endpoint URLs or cloud regions) before they can be used.
|
|||
Provider configurations belong in the root module of a Terraform configuration.
|
||||
(Child modules receive their provider configurations from the root module; for
|
||||
more information, see
|
||||
[Providers Within Modules](./modules.html#providers-within-modules).)
|
||||
[The Module `providers` Meta-Argument](/docs/configuration/meta-arguments/module-providers.html)
|
||||
and [Module Development: Providers Within Modules](/docs/modules/providers.html).)
|
||||
|
||||
A provider configuration is created using a `provider` block:
|
||||
|
||||
|
@ -49,7 +50,7 @@ the provider. Most arguments in this section are defined by the provider itself;
|
|||
in this example both `project` and `region` are specific to the `google`
|
||||
provider.
|
||||
|
||||
You can use [expressions](./expressions.html) in the values of these
|
||||
You can use [expressions](/docs/configuration/expressions/index.html) in the values of these
|
||||
configuration arguments, but can only reference values that are known before the
|
||||
configuration is applied. This means you can safely reference input variables,
|
||||
but not attributes exported by resources (with an exception for resource
|
||||
|
@ -160,7 +161,7 @@ module "aws_vpc" {
|
|||
```
|
||||
|
||||
Modules have some special requirements when passing in providers; see
|
||||
[Providers Within Modules](./modules.html#providers-within-modules)
|
||||
[The Module `providers` Meta-Argument](/docs/configuration/meta-arguments/module-providers.html)
|
||||
for more details. In most cases, only _root modules_ should define provider
|
||||
configurations, with all child modules obtaining their provider configurations
|
||||
from their parents.
|
||||
|
|
|
@ -99,7 +99,7 @@ different (see the [block-type-specific exceptions](#block-type-specific-excepti
|
|||
correspond either to argument names or to nested block type names.
|
||||
|
||||
* Where a property corresponds to an argument that accepts
|
||||
[arbitrary expressions](./expressions.html) in the native syntax, the
|
||||
[arbitrary expressions](/docs/configuration/expressions/index.html) in the native syntax, the
|
||||
property value is mapped to an expression as described under
|
||||
[_Expression Mapping_](#expression-mapping) below. For arguments that
|
||||
do _not_ accept arbitrary expressions, the interpretation of the property
|
||||
|
@ -116,20 +116,22 @@ different (see the [block-type-specific exceptions](#block-type-specific-excepti
|
|||
## Expression Mapping
|
||||
|
||||
Since JSON grammar is not able to represent all of the Terraform language
|
||||
[expression syntax](./expressions.html), JSON values interpreted as expressions
|
||||
[expression syntax](/docs/configuration/expressions/index.html), JSON values interpreted as expressions
|
||||
are mapped as follows:
|
||||
|
||||
| JSON | Terraform Language Interpretation |
|
||||
| ------- | ------------------------------------------------------------------------------------------------------------- |
|
||||
| Boolean | A literal `bool` value. |
|
||||
| Number | A literal `number` value. |
|
||||
| String | Parsed as a [string template](./expressions.html#string-templates) and then evaluated as described below. |
|
||||
| String | Parsed as a [string template][] and then evaluated as described below. |
|
||||
| Object | Each property value is mapped per this table, producing an `object(...)` value with suitable attribute types. |
|
||||
| Array | Each element is mapped per this table, producing a `tuple(...)` value with suitable element types. |
|
||||
| Null | A literal `null`. |
|
||||
|
||||
[string template]: /docs/configuration/expressions/strings.html#string-templates
|
||||
|
||||
When a JSON string is encountered in a location where arbitrary expressions are
|
||||
expected, its value is first parsed as a [string template](./expressions.html#string-templates)
|
||||
expected, its value is first parsed as a [string template][]
|
||||
and then it is evaluated to produce the final result.
|
||||
|
||||
If the given template consists _only_ of a single interpolation sequence,
|
||||
|
|
|
@ -53,7 +53,7 @@ after the equals sign is the argument's value.
|
|||
The context where the argument appears determines what value types are valid
|
||||
(for example, each resource type has a schema that defines the types of its
|
||||
arguments), but many arguments accept arbitrary
|
||||
[expressions](./expressions.html), which allow the value to
|
||||
[expressions](/docs/configuration/expressions/index.html), which allow the value to
|
||||
either be specified literally or generated from other values programmatically.
|
||||
|
||||
-> **Note:** Terraform's configuration language is based on a more general
|
||||
|
|
|
@ -51,7 +51,7 @@ can be used with your configuration.
|
|||
If the running version of Terraform doesn't match the constraints specified,
|
||||
Terraform will produce an error and exit without taking any further actions.
|
||||
|
||||
When you use [child modules](./modules.html), each module can specify its own
|
||||
When you use [child modules](/docs/configuration/blocks/modules/index.html), each module can specify its own
|
||||
version requirements. The requirements of all modules in the tree must be
|
||||
satisfied.
|
||||
|
||||
|
|
|
@ -32,7 +32,7 @@ function-like constructs called _type constructors._
|
|||
represent a type; instead, it represents a _kind_ of similar types.
|
||||
|
||||
Type constraints look like other kinds of Terraform
|
||||
[expressions](./expressions.html), but are a special syntax. Within the
|
||||
[expressions](/docs/configuration/expressions/index.html), but are a special syntax. Within the
|
||||
Terraform language, they are only valid in the `type` argument of an
|
||||
[input variable](./variables.html).
|
||||
|
||||
|
@ -160,7 +160,7 @@ like the following:
|
|||
|
||||
The Terraform language has literal expressions for creating tuple and object
|
||||
values, which are described in
|
||||
[Expressions: Literal Expressions](./expressions.html#literal-expressions) as
|
||||
[Expressions: Literal Expressions](/docs/configuration/expressions/types.html#literal-expressions) as
|
||||
"list/tuple" literals and "map/object" literals, respectively.
|
||||
|
||||
Terraform does _not_ provide any way to directly represent lists, maps, or sets.
|
||||
|
|
|
@ -21,7 +21,7 @@ and allowing modules to be shared between different configurations.
|
|||
|
||||
When you declare variables in the root module of your configuration, you can
|
||||
set their values using CLI options and environment variables.
|
||||
When you declare them in [child modules](./modules.html),
|
||||
When you declare them in [child modules](/docs/configuration/blocks/modules/index.html),
|
||||
the calling module should pass values in the `module` block.
|
||||
|
||||
If you're familiar with traditional programming languages, it can be useful to
|
||||
|
@ -36,7 +36,7 @@ compare Terraform modules to function definitions:
|
|||
variable is being discussed. Other kinds of variables in Terraform include
|
||||
_environment variables_ (set by the shell where Terraform runs) and _expression
|
||||
variables_ (used to indirectly represent a value in an
|
||||
[expression](./expressions.html)).
|
||||
[expression](/docs/configuration/expressions/index.html)).
|
||||
|
||||
## Declaring an Input Variable
|
||||
|
||||
|
@ -78,7 +78,7 @@ The name of a variable can be any valid [identifier](./syntax.html#identifiers)
|
|||
_except_ the following: `source`, `version`, `providers`, `count`, `for_each`, `lifecycle`, `depends_on`, `locals`.
|
||||
|
||||
These names are reserved for meta-arguments in
|
||||
[module configuration blocks](./modules.html), and cannot be
|
||||
[module configuration blocks](/docs/configuration/blocks/modules/syntax.html), and cannot be
|
||||
declared as variable names.
|
||||
|
||||
## Arguments
|
||||
|
@ -106,7 +106,7 @@ configuration.
|
|||
[inpage-type]: #type-constraints
|
||||
|
||||
The `type` argument in a `variable` block allows you to restrict the
|
||||
[type of value](./expressions.html#types-and-values) that will be accepted as
|
||||
[type of value](/docs/configuration/expressions/types.html) that will be accepted as
|
||||
the value for a variable. If no type constraint is set then a value of any type
|
||||
is accepted.
|
||||
|
||||
|
@ -302,7 +302,7 @@ random_pet.animal: Creation complete after 0s [id=jae-known-mongoose]
|
|||
## Using Input Variable Values
|
||||
|
||||
Within the module that declared a variable, its value can be accessed from
|
||||
within [expressions](./expressions.html) as `var.<NAME>`,
|
||||
within [expressions](/docs/configuration/expressions/index.html) as `var.<NAME>`,
|
||||
where `<NAME>` matches the label given in the declaration block:
|
||||
|
||||
-> **Note:** Input variables are _created_ by a `variable` block, but you
|
||||
|
@ -332,7 +332,7 @@ can be set in a number of ways:
|
|||
The following sections describe these options in more detail. This section does
|
||||
not apply to _child_ modules, where values for input variables are instead
|
||||
assigned in the configuration of their parent module, as described in
|
||||
[_Modules_](./modules.html).
|
||||
[_Modules_](/docs/configuration/blocks/modules/index.html).
|
||||
|
||||
### Variables on the Command Line
|
||||
|
||||
|
@ -411,9 +411,10 @@ and lower case letters as in the above example.
|
|||
|
||||
### Complex-typed Values
|
||||
|
||||
When variable values are provided in a variable definitions file, Terraform's
|
||||
[usual syntax](./expressions.html#structural-types) can be used to assign
|
||||
complex-typed values, like lists and maps.
|
||||
When variable values are provided in a variable definitions file, you can use
|
||||
Terraform's usual syntax for
|
||||
[literal expressions](/docs/configuration/expressions/types.html#literal-expressions)
|
||||
to assign complex-typed values, like lists and maps.
|
||||
|
||||
Some special rules apply to the `-var` command line option and to environment
|
||||
variables. For convenience, Terraform defaults to interpreting `-var` and
|
||||
|
|
|
@ -9,7 +9,7 @@ Anywhere that Terraform lets you specify a range of acceptable versions for
|
|||
something, it expects a specially formatted string known as a version
|
||||
constraint. Version constraints are used when configuring:
|
||||
|
||||
- [Modules](./modules.html)
|
||||
- [Modules](/docs/configuration/blocks/modules/index.html)
|
||||
- [Provider requirements](./provider-requirements.html)
|
||||
- [The `required_version` setting](./terraform.html#specifying-a-required-terraform-version) in the `terraform` block.
|
||||
|
||||
|
@ -22,7 +22,7 @@ other dependency management systems like Bundler and NPM.
|
|||
version = ">= 1.2.0, < 2.0.0"
|
||||
```
|
||||
|
||||
A version constraint is a [string literal](./expressions.html#string-literals)
|
||||
A version constraint is a [string literal](/docs/configuration/expressions/strings.html)
|
||||
containing one or more conditions, which are separated by commas.
|
||||
|
||||
Each condition consists of an operator and a version number.
|
||||
|
|
|
@ -35,7 +35,7 @@ Most commonly, modules use:
|
|||
the calling module.
|
||||
* [Output values](/docs/configuration/outputs.html) to return results to the
|
||||
calling module, which it can then use to populate arguments elsewhere.
|
||||
* [Resources](/docs/configuration/resources.html) to define one or more
|
||||
* [Resources](/docs/configuration/blocks/resources/index.html) to define one or more
|
||||
infrastructure objects that the module will manage.
|
||||
|
||||
To define a module, create a new directory for it and place one or more `.tf`
|
||||
|
|
|
@ -14,7 +14,7 @@ If you've built a module that you intend to be reused, we recommend
|
|||
your module, generate documentation, and more.
|
||||
|
||||
Published modules can be easily consumed by Terraform, and users can
|
||||
[constrain module versions](/docs/configuration/modules.html#module-versions)
|
||||
[constrain module versions](/docs/configuration/blocks/modules/syntax.html#version)
|
||||
for safe and predictable updates. The following example shows how a caller
|
||||
might use a module from the Terraform Registry:
|
||||
|
||||
|
@ -37,6 +37,6 @@ do not support the first-class versioning mechanism, but some sources have
|
|||
their own mechanisms for selecting particular VCS commits, etc.
|
||||
|
||||
We recommend that modules distributed via other protocols still use the
|
||||
[standard module structure](./#standard-module-structure) so that it can
|
||||
be used in a similar way to a registry module, or even _become_ a registry
|
||||
module at a later time.
|
||||
[standard module structure](/docs/modules/structure.html) so that they can
|
||||
be used in a similar way as a registry module or be published on the registry
|
||||
at a later time.
|
||||
|
|
|
@ -7,7 +7,7 @@ description: The source argument within a module block specifies the location of
|
|||
|
||||
# Module Sources
|
||||
|
||||
The `source` argument in [a `module` block](/docs/configuration/modules.html)
|
||||
The `source` argument in [a `module` block](/docs/configuration/blocks/modules/syntax.html)
|
||||
tells Terraform where to find the source code for the desired child module.
|
||||
|
||||
Terraform uses this during the module installation step of `terraform init`
|
||||
|
@ -122,7 +122,7 @@ access the Terraform Cloud application.
|
|||
|
||||
Registry modules support versioning. You can provide a specific version as shown
|
||||
in the above examples, or use flexible
|
||||
[version constraints](/docs/configuration/modules.html#module-versions).
|
||||
[version constraints](/docs/configuration/blocks/modules/syntax.html#version).
|
||||
|
||||
You can learn more about the registry at the
|
||||
[Terraform Registry documentation](/docs/registry/modules/use.html#using-modules).
|
||||
|
|
|
@ -42,7 +42,7 @@ to populate the short description of the module. This should be a simple
|
|||
one sentence description of the module.
|
||||
|
||||
- **Standard module structure.** The module must adhere to the
|
||||
[standard module structure](/docs/modules/index.html#standard-module-structure).
|
||||
[standard module structure](/docs/modules/structure.html).
|
||||
This allows the registry to inspect your module and generate documentation,
|
||||
track resource usage, parse submodules and examples, and more.
|
||||
|
||||
|
|
|
@ -76,7 +76,7 @@ follow [semantic versioning](http://semver.org/). In addition to pure syntax,
|
|||
we encourage all modules to follow the full guidelines of semantic versioning.
|
||||
|
||||
Terraform since version 0.11 will resolve any provided
|
||||
[module version constraints](/docs/configuration/modules.html#module-versions) and
|
||||
[module version constraints](/docs/configuration/blocks/modules/syntax.html#version) and
|
||||
using them is highly recommended to avoid pulling in breaking changes.
|
||||
|
||||
Terraform versions after 0.10.6 but before 0.11 have partial support for the registry
|
||||
|
|
|
@ -14,7 +14,7 @@ can't, shouldn't, or don't need to be public.
|
|||
|
||||
You can load private modules [directly from version control and other
|
||||
sources](/docs/modules/sources.html), but those sources don't support [version
|
||||
constraints](/docs/configuration/modules.html#module-versions) or a browsable
|
||||
constraints](/docs/configuration/blocks/modules/syntax.html#version) or a browsable
|
||||
marketplace of modules, both of which are important for enabling a
|
||||
producers-and-consumers content model in a large organization.
|
||||
|
||||
|
|
Loading…
Reference in New Issue