2014-07-28 19:43:00 +02:00
|
|
|
---
|
2020-08-15 03:51:06 +02:00
|
|
|
layout: "language"
|
2018-12-20 05:34:34 +01:00
|
|
|
page_title: "Output Values - Configuration Language"
|
2014-07-28 19:43:00 +02:00
|
|
|
sidebar_current: "docs-config-outputs"
|
2014-10-22 05:21:56 +02:00
|
|
|
description: |-
|
2018-05-06 04:53:38 +02:00
|
|
|
Output values are the return values of a Terraform module.
|
2014-07-28 19:43:00 +02:00
|
|
|
---
|
|
|
|
|
2018-05-06 04:53:38 +02:00
|
|
|
# Output Values
|
2014-07-28 19:43:00 +02:00
|
|
|
|
2020-12-17 17:53:43 +01:00
|
|
|
> **Hands-on:** Try the [Output Data From
|
|
|
|
Terraform](https://learn.hashicorp.com/tutorials/terraform/outputs?in=terraform/configuration-language&utm_source=WEBSITE&utm_medium=WEB_IO&utm_offer=ARTICLE_PAGE&utm_content=DOCS)
|
|
|
|
tutorial on HashiCorp Learn.
|
|
|
|
|
2018-12-11 01:14:33 +01:00
|
|
|
Output values are like the return values of a Terraform module, and have several
|
|
|
|
uses:
|
|
|
|
|
|
|
|
- A child module can use outputs to expose a subset of its resource attributes
|
|
|
|
to a parent module.
|
|
|
|
- A root module can use outputs to print certain values in the CLI output after
|
|
|
|
running `terraform apply`.
|
2021-01-15 23:13:53 +01:00
|
|
|
- When using [remote state](/docs/language/state/remote.html), root module outputs can be
|
2018-12-11 01:14:33 +01:00
|
|
|
accessed by other configurations via a
|
2021-01-15 23:13:53 +01:00
|
|
|
[`terraform_remote_state` data source](/docs/language/state/remote-state-data.html).
|
2014-07-28 19:43:00 +02:00
|
|
|
|
2018-05-06 04:53:38 +02:00
|
|
|
Resource instances managed by Terraform each export attributes whose values
|
|
|
|
can be used elsewhere in configuration. Output values are a way to expose some
|
|
|
|
of that information to the user of your module.
|
2014-07-28 19:43:00 +02:00
|
|
|
|
2018-12-11 01:14:33 +01:00
|
|
|
-> **Note:** For brevity, output values are often referred to as just "outputs"
|
|
|
|
when the meaning is clear from context.
|
|
|
|
|
2018-05-06 04:53:38 +02:00
|
|
|
## Declaring an Output Value
|
2014-07-28 19:43:00 +02:00
|
|
|
|
2018-05-06 04:53:38 +02:00
|
|
|
Each output value exported by a module must be declared using an `output`
|
|
|
|
block:
|
2014-07-28 19:43:00 +02:00
|
|
|
|
2017-04-05 17:29:27 +02:00
|
|
|
```hcl
|
2018-05-06 04:53:38 +02:00
|
|
|
output "instance_ip_addr" {
|
|
|
|
value = aws_instance.server.private_ip
|
2016-08-21 21:17:31 +02:00
|
|
|
}
|
|
|
|
```
|
|
|
|
|
2019-03-22 23:08:55 +01:00
|
|
|
The label immediately after the `output` keyword is the name, which must be a
|
2021-01-15 23:13:53 +01:00
|
|
|
valid [identifier](/docs/language/syntax/configuration.html#identifiers). In a root module, this name is
|
2019-03-22 23:08:55 +01:00
|
|
|
displayed to the user; in a child module, it can be used to access the output's
|
|
|
|
value.
|
2014-07-28 19:43:00 +02:00
|
|
|
|
2021-01-15 23:13:53 +01:00
|
|
|
The `value` argument takes an [expression](/docs/language/expressions/index.html)
|
2018-05-06 04:53:38 +02:00
|
|
|
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
|
|
|
|
as an output value.
|
2014-07-28 19:43:00 +02:00
|
|
|
|
2019-12-17 13:33:11 +01:00
|
|
|
-> **Note:** Outputs are only rendered when Terraform applies your plan. Running
|
|
|
|
`terraform plan` will not render outputs.
|
2019-11-02 21:56:16 +01:00
|
|
|
|
2019-03-22 23:08:55 +01:00
|
|
|
## Accessing Child Module Outputs
|
2014-07-28 19:43:00 +02:00
|
|
|
|
2019-03-22 23:08:55 +01:00
|
|
|
In a parent module, outputs of child modules are available in expressions as
|
|
|
|
`module.<MODULE NAME>.<OUTPUT NAME>`. For example, if a child module named
|
|
|
|
`web_server` declared an output named `instance_ip_addr`, you could access that
|
|
|
|
value as `module.web_server.instance_ip_addr`.
|
|
|
|
|
|
|
|
## Optional Arguments
|
|
|
|
|
|
|
|
`output` blocks can optionally include `description`, `sensitive`, and `depends_on` arguments, which are described in the following sections.
|
|
|
|
|
2020-12-17 00:10:49 +01:00
|
|
|
<a id="description"></a>
|
|
|
|
|
2019-03-22 23:08:55 +01:00
|
|
|
### `description` — Output Value Documentation
|
2016-07-12 00:37:51 +02:00
|
|
|
|
2018-12-11 01:14:33 +01:00
|
|
|
Because the output values of a module are part of its user interface, you can
|
|
|
|
briefly describe the purpose of each value using the optional `description`
|
|
|
|
argument:
|
2017-04-06 10:46:18 +02:00
|
|
|
|
2018-05-06 04:53:38 +02:00
|
|
|
```hcl
|
|
|
|
output "instance_ip_addr" {
|
|
|
|
value = aws_instance.server.private_ip
|
|
|
|
description = "The private IP address of the main server instance."
|
|
|
|
}
|
|
|
|
```
|
2016-11-12 03:17:46 +01:00
|
|
|
|
2018-12-11 01:14:33 +01:00
|
|
|
The description should concisely explain the
|
|
|
|
purpose of the output and what kind of value is expected. This description
|
|
|
|
string might be included in documentation about the module, and so it should be
|
2018-05-06 04:53:38 +02:00
|
|
|
written from the perspective of the user of the module rather than its
|
|
|
|
maintainer. For commentary for module maintainers, use comments.
|
2014-07-28 19:43:00 +02:00
|
|
|
|
2020-12-17 00:10:49 +01:00
|
|
|
<a id="sensitive"></a>
|
|
|
|
|
2019-03-22 23:08:55 +01:00
|
|
|
### `sensitive` — Suppressing Values in CLI Output
|
2014-07-28 19:43:00 +02:00
|
|
|
|
2018-05-06 04:53:38 +02:00
|
|
|
An output can be marked as containing sensitive material using the optional
|
|
|
|
`sensitive` argument:
|
2014-07-28 19:43:00 +02:00
|
|
|
|
2018-05-06 04:53:38 +02:00
|
|
|
```hcl
|
|
|
|
output "db_password" {
|
|
|
|
value = aws_db_instance.db.password
|
|
|
|
description = "The password for logging in to the database."
|
|
|
|
sensitive = true
|
2014-07-28 19:43:00 +02:00
|
|
|
}
|
|
|
|
```
|
2016-05-09 21:46:07 +02:00
|
|
|
|
2021-04-14 15:04:40 +02:00
|
|
|
Terraform will hide values marked as sensitive in the messages from
|
|
|
|
`terraform plan` and `terraform apply`. In the following scenario, our root
|
|
|
|
module has an output declared as sensitive and a module call with a
|
|
|
|
sensitive output, which we then use in a resource attribute.
|
2020-10-06 20:14:29 +02:00
|
|
|
|
|
|
|
```hcl
|
|
|
|
# main.tf
|
|
|
|
|
|
|
|
module "foo" {
|
|
|
|
source = "./mod"
|
|
|
|
}
|
|
|
|
|
|
|
|
resource "test_instance" "x" {
|
|
|
|
some_attribute = module.mod.a # resource attribute references a sensitive output
|
|
|
|
}
|
|
|
|
|
|
|
|
output "out" {
|
|
|
|
value = "xyz"
|
|
|
|
sensitive = true
|
|
|
|
}
|
|
|
|
|
|
|
|
# mod/main.tf, our module containing a sensitive output
|
|
|
|
|
|
|
|
output "a" {
|
|
|
|
value = "secret"
|
2020-12-03 16:05:19 +01:00
|
|
|
sensitive = true
|
2020-10-06 20:14:29 +02:00
|
|
|
}
|
|
|
|
```
|
|
|
|
|
2021-04-14 15:04:40 +02:00
|
|
|
When we run a plan or apply, the sensitive value is redacted from output:
|
2020-10-06 20:14:29 +02:00
|
|
|
|
|
|
|
```
|
|
|
|
Terraform will perform the following actions:
|
|
|
|
|
|
|
|
# test_instance.x will be created
|
|
|
|
+ resource "test_instance" "x" {
|
|
|
|
+ some_attribute = (sensitive)
|
|
|
|
}
|
|
|
|
|
|
|
|
Plan: 1 to add, 0 to change, 0 to destroy.
|
|
|
|
|
|
|
|
Changes to Outputs:
|
|
|
|
+ out = (sensitive value)
|
|
|
|
```
|
|
|
|
|
2021-04-14 15:04:40 +02:00
|
|
|
-> **Note:** In Terraform versions prior to Terraform 0.14, setting an output
|
|
|
|
value in the root module as sensitive would prevent Terraform from showing its
|
|
|
|
value in the list of outputs at the end of `terraform apply`. However, the
|
|
|
|
value could still display in the CLI output for other reasons, like if the
|
|
|
|
value is referenced in an expression for a resource argument.
|
2016-05-09 21:46:07 +02:00
|
|
|
|
2021-04-14 15:04:40 +02:00
|
|
|
Terraform will still record sensitive values in the [state](/docs/language/state/index.html),
|
|
|
|
and so anyone who can access the state data will have access to the sensitive
|
|
|
|
values in cleartext. For more information, see
|
2021-01-15 23:13:53 +01:00
|
|
|
[_Sensitive Data in State_](/docs/language/state/sensitive-data.html).
|
2016-05-09 21:46:07 +02:00
|
|
|
|
2020-12-17 00:10:49 +01:00
|
|
|
<a id="depends_on"></a>
|
|
|
|
|
2019-03-22 23:08:55 +01:00
|
|
|
### `depends_on` — Explicit Output Dependencies
|
2016-05-09 21:46:07 +02:00
|
|
|
|
2018-05-06 04:53:38 +02:00
|
|
|
Since output values are just a means for passing data out of a module, it is
|
|
|
|
usually not necessary to worry about their relationships with other nodes in
|
|
|
|
the dependency graph.
|
2016-05-09 21:46:07 +02:00
|
|
|
|
2018-05-06 04:53:38 +02:00
|
|
|
However, when a parent module accesses an output value exported by one of its
|
|
|
|
child modules, the dependencies of that output value allow Terraform to
|
|
|
|
correctly determine the dependencies between resources defined in different
|
|
|
|
modules.
|
2016-05-09 21:46:07 +02:00
|
|
|
|
2018-05-06 04:53:38 +02:00
|
|
|
Just as with
|
2021-01-15 23:13:53 +01:00
|
|
|
[resource dependencies](/docs/language/resources/behavior.html#resource-dependencies),
|
2019-03-01 17:25:49 +01:00
|
|
|
Terraform analyzes the `value` expression for an output value and automatically
|
2018-05-06 04:53:38 +02:00
|
|
|
determines a set of dependencies, but in less-common cases there are
|
|
|
|
dependencies that cannot be recognized implicitly. In these rare cases, the
|
|
|
|
`depends_on` argument can be used to create additional explicit dependencies:
|
|
|
|
|
|
|
|
```hcl
|
|
|
|
output "instance_ip_addr" {
|
|
|
|
value = aws_instance.server.private_ip
|
|
|
|
description = "The private IP address of the main server instance."
|
|
|
|
|
|
|
|
depends_on = [
|
|
|
|
# Security group rule must be created before this IP address could
|
|
|
|
# actually be used, otherwise the services will be unreachable.
|
|
|
|
aws_security_group_rule.local_access,
|
|
|
|
]
|
|
|
|
}
|
|
|
|
```
|
2017-04-05 17:29:27 +02:00
|
|
|
|
2018-05-06 04:53:38 +02:00
|
|
|
The `depends_on` argument should be used only as a last resort. When using it,
|
|
|
|
always include a comment explaining why it is being used, to help future
|
|
|
|
maintainers understand the purpose of the additional dependency.
|