2014-09-26 23:23:38 +02:00
|
|
|
---
|
|
|
|
layout: "docs"
|
|
|
|
page_title: "Configuring Modules"
|
|
|
|
sidebar_current: "docs-config-modules"
|
2014-10-22 05:21:56 +02:00
|
|
|
description: |-
|
2018-05-06 05:38:38 +02:00
|
|
|
Modules allow multiple resources to be grouped together and encapsulated.
|
2014-09-26 23:23:38 +02:00
|
|
|
---
|
|
|
|
|
2018-05-06 05:38:38 +02:00
|
|
|
# Modules
|
2014-09-26 23:23:38 +02:00
|
|
|
|
2018-05-06 05:38:38 +02:00
|
|
|
A _module_ is a container for multiple resources that are used together.
|
2018-12-11 01:14:33 +01:00
|
|
|
|
2018-05-06 05:38:38 +02:00
|
|
|
Every Terraform configuration has at least one module, known as its
|
|
|
|
_root module_, which consists of the resources defined in the `.tf` files in
|
|
|
|
the main working directory.
|
2014-09-26 23:23:38 +02:00
|
|
|
|
2018-12-11 01:14:33 +01:00
|
|
|
A module can call other modules, which lets you include the child module's
|
|
|
|
resources into the configuration in a concise way. Modules
|
2018-05-06 05:38:38 +02:00
|
|
|
can also be called multiple times, either within the same configuration or
|
|
|
|
in separate configurations, allowing resource configurations to be packaged
|
|
|
|
and re-used.
|
2014-09-26 23:23:38 +02:00
|
|
|
|
2018-05-06 05:38:38 +02:00
|
|
|
This page describes how to call one module from another. Other pages in this
|
|
|
|
section of the documentation describe the different elements that make up
|
|
|
|
modules, and there is further information about how modules can be used,
|
|
|
|
created, and published in [the dedicated _Modules_ section](/docs/modules/index.html).
|
|
|
|
|
|
|
|
## Calling a Child Module
|
|
|
|
|
|
|
|
To _call_ a module means to include the contents of that module into the
|
|
|
|
configuration with specific values for its
|
2018-12-11 01:14:33 +01:00
|
|
|
[input variables](./variables.html). Modules are called
|
2018-05-06 05:38:38 +02:00
|
|
|
from within other modules using `module` blocks:
|
2014-09-26 23:23:38 +02:00
|
|
|
|
2017-04-05 17:29:27 +02:00
|
|
|
```hcl
|
2018-05-06 05:38:38 +02:00
|
|
|
module "servers" {
|
|
|
|
source = "./app-cluster"
|
|
|
|
|
2017-04-05 17:29:27 +02:00
|
|
|
servers = 5
|
2014-09-26 23:23:38 +02:00
|
|
|
}
|
|
|
|
```
|
|
|
|
|
2018-12-11 01:14:33 +01:00
|
|
|
A module that includes a `module` block like this is the _calling module_ of the
|
|
|
|
child module.
|
|
|
|
|
|
|
|
The label immediately after the `module` keyword is a local name, which the
|
|
|
|
calling module can use to refer to this instance of the module.
|
2018-05-06 05:38:38 +02:00
|
|
|
|
|
|
|
Within the block body (between `{` and `}`) are the arguments for the module.
|
2018-12-11 01:14:33 +01:00
|
|
|
Most of the arguments correspond to [input variables](./variables.html)
|
2018-05-06 05:38:38 +02:00
|
|
|
defined by the module, including the `servers` argument in the above example.
|
|
|
|
|
2018-12-11 01:14:33 +01:00
|
|
|
All modules require a `source` argument, which is a meta-argument defined by
|
|
|
|
Terraform CLI. Its value is either the path to a local directory of the
|
|
|
|
module's configuration files, or a remote module source that Terraform should
|
|
|
|
download and use. This value must be a literal string with no template
|
|
|
|
sequences; arbitrary expressions are not allowed. For more information on
|
|
|
|
possible values for this argument, see [Module Sources](/docs/modules/sources.html).
|
2018-05-06 05:38:38 +02:00
|
|
|
|
|
|
|
The same source address can be specified in multiple `module` blocks to create
|
|
|
|
multiple copies of the resources defined within, possibly with different
|
|
|
|
variable values.
|
|
|
|
|
|
|
|
## Accessing Module Output Values
|
2014-09-26 23:23:38 +02:00
|
|
|
|
2018-05-06 05:38:38 +02:00
|
|
|
The resources defined in a module are encapsulated, so the calling module
|
|
|
|
cannot access their attributes directly. However, the child module can
|
2018-12-11 01:14:33 +01:00
|
|
|
declare [output values](./outputs.html) to selectively
|
2018-05-06 05:38:38 +02:00
|
|
|
export certain values to be accessed by the calling module.
|
2017-10-31 01:34:04 +01:00
|
|
|
|
2018-05-06 05:38:38 +02:00
|
|
|
For example, if the `./app-cluster` module referenced in the example above
|
|
|
|
exported an output value named `instance_ids` then the calling module
|
|
|
|
can reference that result using the expression `module.servers.instance_ids`:
|
2017-10-31 01:34:04 +01:00
|
|
|
|
2018-05-06 05:38:38 +02:00
|
|
|
```hcl
|
|
|
|
resource "aws_elb" "example" {
|
|
|
|
# ...
|
|
|
|
|
|
|
|
instances = module.servers.instance_ids
|
|
|
|
}
|
|
|
|
```
|
2017-10-31 01:34:04 +01:00
|
|
|
|
2018-12-11 01:14:33 +01:00
|
|
|
For more information about referring to named values, see
|
|
|
|
[Expressions](./expressions.html).
|
|
|
|
|
2018-05-06 05:38:38 +02:00
|
|
|
## Other Meta-arguments
|
|
|
|
|
|
|
|
Along with the `source` meta-argument described above, module blocks have
|
|
|
|
some more meta-arguments that have special meaning across all modules,
|
|
|
|
described in more detail in other sections:
|
2017-10-31 01:34:04 +01:00
|
|
|
|
|
|
|
* `version` - (Optional) A [version constraint](/docs/modules/usage.html#module-versions)
|
|
|
|
string that specifies which versions of the referenced module are acceptable.
|
|
|
|
The newest version matching the constraint will be used. `version` is supported
|
|
|
|
only for modules retrieved from module registries.
|
|
|
|
|
|
|
|
* `providers` - (Optional) A map whose keys are provider configuration names
|
|
|
|
that are expected by child module and whose values are corresponding
|
|
|
|
provider names in the calling module. This allows
|
|
|
|
[provider configurations to be passed explicitly to child modules](/docs/modules/usage.html#providers-within-modules).
|
|
|
|
If not specified, the child module inherits all of the default (un-aliased)
|
|
|
|
provider configurations from the calling module.
|
2018-05-06 05:38:38 +02:00
|
|
|
|
|
|
|
In addition to the above, the argument names `count`, `for_each` and
|
|
|
|
`lifecycle` are not currently used by Terraform but are reserved for planned
|
|
|
|
future features.
|
|
|
|
|
|
|
|
Since modules are a complex feature in their own right, further detail
|
|
|
|
about how modules can be used, created, and published is included in
|
|
|
|
[the dedicated section on modules](/docs/modules/index.html).
|