mirror of https://github.com/hashicorp/terraform
trujillo-adam
2 years ago
parent
dc5939b3dc
commit
9edbd79465
@ -1,139 +0,0 @@
|
||||
---
|
||||
page_title: Terraform Settings - Configuration Language
|
||||
description: >-
|
||||
The terraform block allows you to configure Terraform behavior, including the
|
||||
Terraform version, backend, integration with HCP Terraform, and required
|
||||
providers.
|
||||
---
|
||||
|
||||
# Terraform Settings
|
||||
|
||||
The special `terraform` configuration block type is used to configure some
|
||||
behaviors of Terraform itself, such as requiring a minimum Terraform version to
|
||||
apply your configuration.
|
||||
|
||||
## Terraform Block Syntax
|
||||
|
||||
Terraform settings are gathered together into `terraform` blocks:
|
||||
|
||||
```hcl
|
||||
terraform {
|
||||
# ...
|
||||
}
|
||||
```
|
||||
|
||||
Each `terraform` block can contain a number of settings related to Terraform's
|
||||
behavior. Within a `terraform` block, only constant values can be used;
|
||||
arguments may not refer to named objects such as resources, input variables,
|
||||
etc, and may not use any of the Terraform language built-in functions.
|
||||
|
||||
The various options supported within a `terraform` block are described in the
|
||||
following sections.
|
||||
|
||||
## Configuring HCP Terraform
|
||||
|
||||
The nested `cloud` block configures HCP Terraform for enabling its
|
||||
[CLI-driven run workflow](/terraform/cloud-docs/run/cli).
|
||||
|
||||
- Refer to [HCP Terraform Configuration](/terraform/language/settings/cloud) for a summary of the `cloud` block's syntax.
|
||||
|
||||
- Refer to [Using HCP Terraform](/terraform/cli/cloud) in the
|
||||
Terraform CLI documentation for complete details about how to initialize and configure the HCP Terraform CLI integration.
|
||||
|
||||
## Configuring a Terraform Backend
|
||||
|
||||
The nested `backend` block configures which state backend Terraform should use.
|
||||
|
||||
The syntax and behavior of the `backend` block is described in [Backend
|
||||
Configuration](/terraform/language/settings/backends/configuration).
|
||||
|
||||
## Specifying a Required Terraform Version
|
||||
|
||||
> **Hands-on:** Try the [Manage Terraform Versions](/terraform/tutorials/configuration-language/versions) or [Manage Terraform Versions in HCP Terraform](/terraform/tutorials/cloud/cloud-versions) tutorials.
|
||||
|
||||
The `required_version` setting accepts a [version constraint
|
||||
string,](/terraform/language/expressions/version-constraints) which specifies which versions of Terraform
|
||||
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](/terraform/language/modules), each module can specify its own
|
||||
version requirements. The requirements of all modules in the tree must be
|
||||
satisfied.
|
||||
|
||||
Use Terraform version constraints in a collaborative environment to
|
||||
ensure that everyone is using a specific Terraform version, or using at least
|
||||
a minimum Terraform version that has behavior expected by the configuration.
|
||||
|
||||
The `required_version` setting applies only to the version of Terraform CLI.
|
||||
Terraform's resource types are implemented by provider plugins,
|
||||
whose release cycles are independent of Terraform CLI and of each other.
|
||||
Use [the `required_providers` block](/terraform/language/providers/requirements) to manage
|
||||
the expected versions for each provider you use.
|
||||
|
||||
## Specifying Provider Requirements
|
||||
|
||||
[inpage-source]: #specifying-provider-requirements
|
||||
|
||||
The `required_providers` block specifies all of the providers required by the
|
||||
current module, mapping each local provider name to a source address and a
|
||||
version constraint.
|
||||
|
||||
```hcl
|
||||
terraform {
|
||||
required_providers {
|
||||
aws = {
|
||||
version = ">= 2.7.0"
|
||||
source = "hashicorp/aws"
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
For more information, see [Provider Requirements](/terraform/language/providers/requirements).
|
||||
|
||||
## Experimental Language Features
|
||||
|
||||
The Terraform team will sometimes introduce new language features initially via
|
||||
an opt-in experiment, so that the community can try the new feature and give
|
||||
feedback on it prior to it becoming a backward-compatibility constraint.
|
||||
|
||||
In releases where experimental features are available, you can enable them on
|
||||
a per-module basis by setting the `experiments` argument inside a `terraform`
|
||||
block:
|
||||
|
||||
```hcl
|
||||
terraform {
|
||||
experiments = [example]
|
||||
}
|
||||
```
|
||||
|
||||
The above would opt in to an experiment named `example`, assuming such an
|
||||
experiment were available in the current Terraform version.
|
||||
|
||||
Experiments are subject to arbitrary changes in later releases and, depending on
|
||||
the outcome of the experiment, may change drastically before final release or
|
||||
may not be released in stable form at all. Such breaking changes may appear
|
||||
even in minor and patch releases. We do not recommend using experimental
|
||||
features in Terraform modules intended for production use.
|
||||
|
||||
In order to make that explicit and to avoid module callers inadvertently
|
||||
depending on an experimental feature, any module with experiments enabled will
|
||||
generate a warning on every `terraform plan` or `terraform apply`. If you
|
||||
want to try experimental features in a shared module, we recommend enabling the
|
||||
experiment only in alpha or beta releases of the module.
|
||||
|
||||
The introduction and completion of experiments is reported in
|
||||
[Terraform's changelog](https://github.com/hashicorp/terraform/blob/main/CHANGELOG.md),
|
||||
so you can watch the release notes there to discover which experiment keywords,
|
||||
if any, are available in a particular Terraform release.
|
||||
|
||||
## Passing Metadata to Providers
|
||||
|
||||
The `terraform` block can have a nested `provider_meta` block for each
|
||||
provider a module is using, if the provider defines a schema for it. This
|
||||
allows the provider to receive module-specific information, and is primarily
|
||||
intended for modules distributed by the same vendor as the associated provider.
|
||||
|
||||
For more information, see [Provider Metadata](/terraform/internals/provider-meta).
|
||||
Loading…
Reference in new issue