website: Fix references to the now-defunct "Interpolation" page
This has been replaced with an "Expressions" page. Also includes a number of changes to Markdown style to conform to our usual conventions, applied automatically by my editor while making these changes.
This commit is contained in:
Martin Atkins
parent
6549f24d88
commit
b2e8987f7e
|
|
@ -3,47 +3,48 @@ layout: "docs"
|
|||
page_title: "Command: console"
|
||||
sidebar_current: "docs-commands-console"
|
||||
description: |-
|
||||
The `terraform console` command creates an interactive console for using [interpolations](/docs/configuration/interpolation.html).
|
||||
The `terraform console` command provides an interactive console for
|
||||
evaluting expressions.
|
||||
---
|
||||
|
||||
# Command: console
|
||||
|
||||
The `terraform console` command creates an interactive console for
|
||||
using [interpolations](/docs/configuration/interpolation.html).
|
||||
The `terraform console` command provides an interactive console for
|
||||
evaluating [expressions](/docs/configuration/expressions.html).
|
||||
|
||||
## Usage
|
||||
|
||||
Usage: `terraform console [options] [dir]`
|
||||
|
||||
This opens an interactive console for experimenting with interpolations.
|
||||
This is useful for testing interpolations before using them in configurations
|
||||
as well as interacting with an existing [state](/docs/state/index.html).
|
||||
This command provides an interative command-line console for evaluating and
|
||||
experimenting with [expressions](/docs/configuration/expressions.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).
|
||||
|
||||
If a state file doesn't exist, the console still works and can be used
|
||||
to experiment with supported interpolation functions. Try entering some basic
|
||||
math such as `1 + 5` to see.
|
||||
If the current state is empty or has not yet been created, the console can be
|
||||
used to experiment with the expression syntax and
|
||||
[built-in functions](/docs/configuration/functions.html).
|
||||
|
||||
The `dir` argument can be used to open a console for a specific Terraform
|
||||
configuration directory. This will load any state from that directory as
|
||||
well as the configuration. This defaults to the current working directory.
|
||||
The `console` command does not require Terraform state or configuration
|
||||
to function.
|
||||
The `dir` argument specifies the directory of the root module to use.
|
||||
If a path is not specified, the current working directory is used.
|
||||
|
||||
The command-line flags are all optional. The list of available flags are:
|
||||
The supported options are:
|
||||
|
||||
* `-state=path` - Path to the state file. Defaults to `terraform.tfstate`.
|
||||
A state file doesn't need to exist.
|
||||
* `-state=path` - Path to a local state file. Expressions will be evaluated
|
||||
using values from this state file. If not specified, the state associated
|
||||
with the current [workspace](/docs/state/workspaces.html) is used.
|
||||
|
||||
You can close the console with the `exit` command or by using Control-C
|
||||
You can close the console with the `exit` command or by pressing Control-C
|
||||
or Control-D.
|
||||
|
||||
## 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 outputted unless an error occurs earlier.
|
||||
final command is printed unless an error occurs earlier.
|
||||
|
||||
An example is shown below:
|
||||
For example:
|
||||
|
||||
```shell
|
||||
$ echo "1 + 5" | terraform console
|
||||
|
|
@ -52,14 +53,6 @@ $ echo "1 + 5" | terraform console
|
|||
|
||||
## Remote State
|
||||
|
||||
The `terraform console` command will read configured state even if it
|
||||
is [remote](/docs/state/remote.html). This is great for scripting
|
||||
state reading in CI environments or other remote scenarios.
|
||||
|
||||
After configuring remote state, run a `terraform remote pull` command
|
||||
to sync state locally. The `terraform console` command will use this
|
||||
state for operations.
|
||||
|
||||
Because the console currently isn't able to modify state in any way,
|
||||
this is a one way operation and you don't need to worry about remote
|
||||
state conflicts in any way.
|
||||
If [remote state](/docs/state/remote.html) is used by the current backend,
|
||||
Terraform will read the state for the current workspace from the backend
|
||||
before evaluating any expressions.
|
||||
|
|
|
|||
|
|
@ -72,7 +72,7 @@ If you now run `terraform apply`, you see how this works.
|
|||
|
||||
It is sometimes useful to embed files within the module that aren't Terraform configuration files, such as a script to provision a resource or a file to upload.
|
||||
|
||||
In these cases, you can't use a relative path, since paths in Terraform are generally relative to the working directory from which Terraform was executed. Instead, you want to use a module-relative path. To do this, you should use the [path interpolated variables](/docs/configuration/interpolation.html).
|
||||
In these cases, you can't use a relative path, since paths in Terraform are generally relative to the working directory from which Terraform was executed. Instead, use a module-relative path, by interpolating `path.module`:
|
||||
|
||||
```hcl
|
||||
resource "aws_instance" "server" {
|
||||
|
|
@ -84,8 +84,6 @@ resource "aws_instance" "server" {
|
|||
}
|
||||
```
|
||||
|
||||
Here we use `${path.module}` to get a module-relative path.
|
||||
|
||||
## Nested Modules
|
||||
|
||||
You can nest a module within another module. This module will be hidden from your root configuration, so you'll have to re-expose any
|
||||
|
|
@ -118,13 +116,13 @@ standard structure.
|
|||
|
||||
* **README**. The root module and any nested modules should have README
|
||||
files. This file should be named `README` or `README.md`. The latter will
|
||||
be treated as markdown. There should be a description of the module and
|
||||
be treated as markdown. There should be a description of the module and
|
||||
what it should be used for. If you want to include an example for how this
|
||||
module can be used in combination with other resources, put it in an [examples
|
||||
directory like this](https://github.com/hashicorp/terraform-aws-consul/tree/master/examples).
|
||||
Consider including a visual diagram depicting the infrastructure resources
|
||||
the module may create and their relationship. The README doesn't need to
|
||||
document inputs or outputs of the module because tooling will automatically
|
||||
Consider including a visual diagram depicting the infrastructure resources
|
||||
the module may create and their relationship. The README doesn't need to
|
||||
document inputs or outputs of the module because tooling will automatically
|
||||
generate this. If you are linking to a file or embedding an image contained
|
||||
in the repository itself, use a commit-specific absolute URL so the link won't
|
||||
point to the wrong version of a resource in the future.
|
||||
|
|
|
|||
|
|
@ -16,8 +16,8 @@ resource. The `chef` provisioner supports both `ssh` and `winrm` type
|
|||
|
||||
The `chef` provisioner has some prerequisites for specific connection types:
|
||||
|
||||
- For `ssh` type connections, `cURL` must be available on the remote host.
|
||||
- For `winrm` connections, `PowerShell 2.0` must be available on the remote host.
|
||||
* For `ssh` type connections, `cURL` must be available on the remote host.
|
||||
* For `winrm` connections, `PowerShell 2.0` must be available on the remote host.
|
||||
|
||||
Without these prerequisites, your provisioning execution will fail.
|
||||
|
||||
|
|
@ -62,8 +62,8 @@ resource "aws_instance" "web" {
|
|||
The following arguments are supported:
|
||||
|
||||
* `attributes_json (string)` - (Optional) A raw JSON string with initial node attributes
|
||||
for the new node. These can also be loaded from a file on disk using the [`file()`
|
||||
interpolation function](/docs/configuration/interpolation.html#file_path_).
|
||||
for the new node. These can also be loaded from a file on disk using
|
||||
[the `file` function](/docs/configuration/functions/file.html).
|
||||
|
||||
* `channel (string)` - (Optional) The Chef Client release channel to install from. If not
|
||||
set, the `stable` channel will be used.
|
||||
|
|
@ -131,8 +131,8 @@ The following arguments are supported:
|
|||
|
||||
* `secret_key (string)` - (Optional) The contents of the secret key that is used
|
||||
by the Chef Client to decrypt data bags on the Chef Server. The key will be uploaded to the remote
|
||||
machine. This can also be loaded from a file on disk using the [`file()` interpolation
|
||||
function](/docs/configuration/interpolation.html#file_path_).
|
||||
machine. This can also be loaded from a file on disk using
|
||||
[the `file` function](/docs/configuration/functions/file.html).
|
||||
|
||||
* `server_url (string)` - (Required) The URL to the Chef server. This includes the path to
|
||||
the organization. See the example.
|
||||
|
|
@ -153,12 +153,12 @@ The following arguments are supported:
|
|||
the new Chef Client and optionally configure Chef Vaults.
|
||||
|
||||
* `user_key (string)` - (Required) The contents of the user key that will be used to
|
||||
authenticate with the Chef Server. This can also be loaded from a file on disk using the [`file()`
|
||||
interpolation function](/docs/configuration/interpolation.html#file_path_).
|
||||
authenticate with the Chef Server. This can also be loaded from a file on disk using
|
||||
[the `file` function](/docs/configuration/functions/file.html).
|
||||
|
||||
* `vault_json (string)` - (Optional) A raw JSON string with Chef Vaults and Items to which the new node
|
||||
should have access. These can also be loaded from a file on disk using the
|
||||
[`file()` interpolation function](/docs/configuration/interpolation.html#file_path_).
|
||||
should have access. These can also be loaded from a file on disk using
|
||||
[the `file` function](/docs/configuration/functions/file.html).
|
||||
|
||||
* `version (string)` - (Optional) The Chef Client version to install on the remote machine.
|
||||
If not set, the latest available version will be installed.
|
||||
|
|
|
|||
|
|
@ -73,8 +73,8 @@ provisioner "file" {
|
|||
**Additional arguments only supported by the `ssh` connection type:**
|
||||
|
||||
* `private_key` - The contents of an SSH key to use for the connection. These can
|
||||
be loaded from a file on disk using the [`file()` interpolation
|
||||
function](/docs/configuration/interpolation.html#file_path_). This takes
|
||||
be loaded from a file on disk using
|
||||
[the `file` function](/docs/configuration/functions/file.html). This takes
|
||||
preference over the password if provided.
|
||||
|
||||
* `agent` - Set to `false` to disable using `ssh-agent` to authenticate. On Windows the
|
||||
|
|
@ -97,6 +97,7 @@ provisioner "file" {
|
|||
* `cacert` - The CA certificate to validate against.
|
||||
|
||||
<a id="bastion"></a>
|
||||
|
||||
## Connecting through a Bastion Host with SSH
|
||||
|
||||
The `ssh` connection also supports the following fields to facilitate connnections via a
|
||||
|
|
@ -118,6 +119,6 @@ The `ssh` connection also supports the following fields to facilitate connnectio
|
|||
Defaults to the value of the `password` field.
|
||||
|
||||
* `bastion_private_key` - The contents of an SSH key file to use for the bastion
|
||||
host. These can be loaded from a file on disk using the [`file()`
|
||||
interpolation function](/docs/configuration/interpolation.html#file_path_).
|
||||
host. These can be loaded from a file on disk using
|
||||
[the `file` function](/docs/configuration/functions/file.html).
|
||||
Defaults to the value of the `private_key` field.
|
||||
|
|
|
|||
Loading…
Reference in New Issue