mirror of
https://github.com/hashicorp/terraform.git
synced 2026-04-22 06:40:42 -04:00
7055650270
Previously "terraform console" always evaluated in a kinda strange context where resource instance data comes from the prior state, but other derived of values end up being calculated dynamically based on the current configuration, which is okay for simple cases but can be confusing if the configuration has changed significantly since the most recent apply, or if there haven't yet been any applied changes. Now we'll allow an optional new mode where Terraform runs the normal plan phase (as if running "terraform plan") and then uses the resulting _planned state_ as the basis for evaluation, allowing evaluation against a partial approximation of what the world ought to look like if these changes were applied, without having to actually apply them first. As with the previous use of the eval walk, it's possible that an erroneous situation will still produce a partial evaluation scope, and so the console still allows evaluation against that scope but with a caveat that it might produce unexpected results. In practice this can be useful for debugging situations like when unknown values block planning of an object, to allow inspection of the values that are contributing to that blocked planning operation even though the plan is not yet complete.
145 lines
4.3 KiB
Text
145 lines
4.3 KiB
Text
---
|
|
page_title: 'Command: console'
|
|
description: >-
|
|
The terraform console command provides an interactive console for evaluating
|
|
expressions.
|
|
---
|
|
|
|
# Command: console
|
|
|
|
The `terraform console` command provides an interactive console for
|
|
evaluating [expressions](/terraform/language/expressions).
|
|
|
|
## Usage
|
|
|
|
Usage: `terraform console [options]`
|
|
|
|
This command provides an interactive command-line console for evaluating and
|
|
experimenting with [expressions](/terraform/language/expressions).
|
|
You can use it to test interpolations before using them in configurations
|
|
and to interact with any values currently saved in
|
|
[state](/terraform/language/state). If the current state is empty or has not yet been created, you can use the console to experiment with the expression syntax and
|
|
[built-in functions](/terraform/language/functions). The console holds a [lock on the state](/terraform/language/state/locking), and you will not be able to use the console while performing other actions that modify state.
|
|
|
|
To close the console, enter the `exit` command or press Control-C
|
|
or Control-D.
|
|
|
|
For configurations using
|
|
[the `local` backend](/terraform/language/settings/backends/local) only,
|
|
`terraform console` accepts the legacy command line option
|
|
[`-state`](/terraform/language/settings/backends/local#command-line-arguments).
|
|
|
|
## Scripting
|
|
|
|
The `terraform console` command can be used in non-interactive scripts
|
|
by piping newline-separated commands to it. Only the output from the
|
|
final command is printed unless an error occurs earlier.
|
|
|
|
For example:
|
|
|
|
```shell
|
|
$ echo 'split(",", "foo,bar,baz")' | terraform console
|
|
tolist([
|
|
"foo",
|
|
"bar",
|
|
"baz",
|
|
])
|
|
```
|
|
|
|
## Remote State
|
|
|
|
If [remote state](/terraform/language/state/remote) is used by the current backend,
|
|
Terraform will read the state for the current workspace from the backend
|
|
before evaluating any expressions.
|
|
|
|
## Evaluation against a Plan
|
|
|
|
By default, `terraform console` evaluates expressions against the current
|
|
Terraform state, and so the results are typically very limited for resource
|
|
instances that haven't yet been created by applying a plan.
|
|
|
|
You can use the `-plan` option to instead generate an execution plan first,
|
|
as if running `terraform plan`, and then evaluate against the _planned_ state
|
|
to describe the values Terraform expects will be correct after the plan is
|
|
applied. This typically causes a longer delay before the console prompt
|
|
appears, but in return there will be a more complete set of values available in
|
|
the expression scope.
|
|
|
|
For well-behaved configurations the planning phase should not make any
|
|
modifications to real remote objects, but it _is_ possible to write a
|
|
configuration that can take significant actions while planning. For example, a
|
|
configuration which uses the `hashicorp/external` provider's
|
|
[`external` data source](https://registry.terraform.io/providers/hashicorp/external/latest/docs/data-sources/external)
|
|
is likely to run the configured external command during the plan phase, which
|
|
means it would be run by `terraform console -plan` too.
|
|
|
|
We don't recommend that you write configurations that make changes during the
|
|
plan phase. If you do write such a configuration despite that recommendation,
|
|
take care when using the console in plan mode against that configuration.
|
|
|
|
## Examples
|
|
|
|
The `terraform console` command will read the Terraform configuration in the
|
|
current working directory and the Terraform state file from the configured
|
|
backend so that interpolations can be tested against both the values in the
|
|
configuration and the state file.
|
|
|
|
With the following `main.tf`:
|
|
|
|
```hcl
|
|
variable "apps" {
|
|
type = map(any)
|
|
default = {
|
|
"foo" = {
|
|
"region" = "us-east-1",
|
|
},
|
|
"bar" = {
|
|
"region" = "eu-west-1",
|
|
},
|
|
"baz" = {
|
|
"region" = "ap-south-1",
|
|
},
|
|
}
|
|
}
|
|
|
|
resource "random_pet" "example" {
|
|
for_each = var.apps
|
|
}
|
|
```
|
|
|
|
Executing `terraform console` will drop you into an interactive shell where you
|
|
can test interpolations to:
|
|
|
|
Print a value from a map:
|
|
|
|
```
|
|
> var.apps.foo
|
|
{
|
|
"region" = "us-east-1"
|
|
}
|
|
```
|
|
|
|
Filter a map based on a specific value:
|
|
|
|
```
|
|
> { for key, value in var.apps : key => value if value.region == "us-east-1" }
|
|
{
|
|
"foo" = {
|
|
"region" = "us-east-1"
|
|
}
|
|
}
|
|
```
|
|
|
|
Check if certain values may not be known until apply:
|
|
|
|
```
|
|
> random_pet.example
|
|
(known after apply)
|
|
```
|
|
|
|
Test various functions:
|
|
|
|
```
|
|
> cidrnetmask("172.16.0.0/12")
|
|
"255.240.0.0"
|
|
```
|