Update of the module creation page
Updated some style, grammar and formatting.
This commit is contained in:
parent
59b67efd8a
commit
93308a2b36
|
@ -2,31 +2,21 @@
|
||||||
layout: "docs"
|
layout: "docs"
|
||||||
page_title: "Creating Modules"
|
page_title: "Creating Modules"
|
||||||
sidebar_current: "docs-modules-create"
|
sidebar_current: "docs-modules-create"
|
||||||
description: |-
|
description: How to create modules.
|
||||||
Creating modules in Terraform is easy. You may want to do this to better organize your code, to make a reusable component, or just to learn more about Terraform. For any reason, if you already know the basics of Terraform, creating a module is a piece of cake.
|
|
||||||
---
|
---
|
||||||
|
|
||||||
# Creating Modules
|
# Creating Modules
|
||||||
|
|
||||||
Creating modules in Terraform is easy. You may want to do this to better
|
Creating modules in Terraform is easy. You may want to do this to better organize your code, to make a reusable component, or just to learn more about Terraform. For any reason, if you already know the basics of Terraform, then creating a module is a piece of cake.
|
||||||
organize your code, to make a reusable component, or just to learn more about
|
|
||||||
Terraform. For any reason, if you already know the basics of Terraform,
|
|
||||||
creating a module is a piece of cake.
|
|
||||||
|
|
||||||
Modules in Terraform are just folders with Terraform files. In fact,
|
Modules in Terraform are folders with Terraform files. In fact, when you run `terraform apply`, the current working directory holding
|
||||||
when you run `terraform apply`, the current working directory holding
|
the Terraform files you're applying comprise what is called the _root module_. This itself is a valid module.
|
||||||
the Terraform files you're applying comprise what is called the
|
|
||||||
_root module_. It itself is a valid module.
|
|
||||||
|
|
||||||
Therefore, you can enter the source of any module, run `terraform apply`,
|
Therefore, you can enter the source of any module, satisfy any required variables, run `terraform apply`, and expect it to work.
|
||||||
and expect it to work (assuming you satisfy the required variables, if any).
|
|
||||||
|
|
||||||
## An Example
|
## An Example Module
|
||||||
|
|
||||||
Within a folder containing Terraform configurations, create a subfolder
|
Within a folder containing Terraform configurations, create a subfolder called `child`. In this subfolder, make one empty `main.tf` file. Then, back in the root folder containing the `child` folder, add this to one of your Terraform configuration files:
|
||||||
"child". In this subfolder, make one empty "main.tf" file. Then, back in
|
|
||||||
the root folder containing the "child" folder, add this to one of the
|
|
||||||
Terraform files:
|
|
||||||
|
|
||||||
```
|
```
|
||||||
module "child" {
|
module "child" {
|
||||||
|
@ -34,25 +24,18 @@ module "child" {
|
||||||
}
|
}
|
||||||
```
|
```
|
||||||
|
|
||||||
This will work. You've created your first module! You can add resources
|
You've now created your first module! You can now add resources to the `child` module.
|
||||||
to the child module to see how that interaction works.
|
|
||||||
|
|
||||||
Note: Prior to running the above, you'll have to run
|
**Note:** Prior to running the above, you'll have to run [the get command](/docs/commands/get.html) for Terraform to sync
|
||||||
[the get command](/docs/commands/get.html) for Terraform to sync
|
your modules. This should be instant since the module is a local path.
|
||||||
your modules. This should be instant since the module is just a local path.
|
|
||||||
|
|
||||||
## Inputs/Outputs
|
## Inputs/Outputs
|
||||||
|
|
||||||
To make modules more useful than simple isolated containers of Terraform
|
To make modules more useful than simple isolated containers of Terraform configurations, modules can be configured and also have outputs that can be consumed by your Terraform configuration.
|
||||||
configurations, modules can be configured and also have outputs that can be
|
|
||||||
consumed by the configuration using the module.
|
|
||||||
|
|
||||||
Inputs of a module are [variables](/docs/configuration/variables.html)
|
Inputs of a module are [variables](/docs/configuration/variables.html) and outputs are [outputs](/docs/configuration/outputs.html). There is no special syntax to define these, they're defined just like any other variables or outputs. You can think about these variables and outputs as the API interface to your module.
|
||||||
and outputs are [outputs](/docs/configuration/outputs.html). There is no
|
|
||||||
special syntax to define these, they're defined just like any other
|
|
||||||
variables or outputs.
|
|
||||||
|
|
||||||
In the "child" module we created above, add the following:
|
Let's add a variable and an output to our `child` module.
|
||||||
|
|
||||||
```
|
```
|
||||||
variable "memory" {}
|
variable "memory" {}
|
||||||
|
@ -62,8 +45,7 @@ output "received" {
|
||||||
}
|
}
|
||||||
```
|
```
|
||||||
|
|
||||||
This will create a required variable "memory" and then an output "received"
|
This will create a required variable, `memory`, and then an output, `received`, that will be the value of the `memory` variable.
|
||||||
that will simply be the value of the memory variable.
|
|
||||||
|
|
||||||
You can then configure the module and use the output like so:
|
You can then configure the module and use the output like so:
|
||||||
|
|
||||||
|
@ -79,24 +61,13 @@ output "child_memory" {
|
||||||
}
|
}
|
||||||
```
|
```
|
||||||
|
|
||||||
If you run `apply`, you'll again see that this works.
|
If you now run `terraform apply`, you see how this works.
|
||||||
|
|
||||||
And that is all there is to it. Variables and outputs are used to configure
|
|
||||||
modules and provide results. Resources within a module are isolated,
|
|
||||||
and the whole thing is managed as a single unit.
|
|
||||||
|
|
||||||
## Paths and Embedded Files
|
## Paths and Embedded Files
|
||||||
|
|
||||||
It is sometimes useful to embed files within the module that aren't
|
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.
|
||||||
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
|
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).
|
||||||
are generally relative to the working directory that Terraform was executed
|
|
||||||
from. Instead, you want to use a module-relative path. To do this, use
|
|
||||||
the [path interpolated variables](/docs/configuration/interpolation.html).
|
|
||||||
|
|
||||||
An example is shown below:
|
|
||||||
|
|
||||||
```
|
```
|
||||||
resource "aws_instance" "server" {
|
resource "aws_instance" "server" {
|
||||||
|
@ -108,20 +79,13 @@ resource "aws_instance" "server" {
|
||||||
}
|
}
|
||||||
```
|
```
|
||||||
|
|
||||||
In the above, we use `${path.module}` to get a module-relative path. This
|
Here we use `${path.module}` to get a module-relative path.
|
||||||
is usually what you'll want in any case.
|
|
||||||
|
|
||||||
## Nested Modules
|
## Nested Modules
|
||||||
|
|
||||||
You can use a module within a module just like you would anywhere else.
|
You can nest a module within another module. This module will be hidden from your root configuration, so you'll have re-expose any
|
||||||
This module will be hidden from the root user, so you'll have re-expose any
|
variables and outputs you require.
|
||||||
variables if you need to, as well as outputs.
|
|
||||||
|
|
||||||
The [get command](/docs/commands/get.html) will automatically get all
|
The [get command](/docs/commands/get.html) will automatically get all nested modules.
|
||||||
nested modules as well.
|
|
||||||
|
|
||||||
You don't have to worry about conflicting versions of modules, since
|
You don't have to worry about conflicting versions of modules, since Terraform builds isolated subtrees of all dependencies. For example, one module might use version 1.0 of module `foo` and another module might use version 2.0, and this will all work fine within Terraform since the modules are created separately.
|
||||||
Terraform builds isolated subtrees of all dependencies. For example,
|
|
||||||
one module might use version 1.0 of module "foo" and another module
|
|
||||||
might use version 2.0 of module "foo", and this would all work fine
|
|
||||||
within Terraform since the modules are created separately.
|
|
||||||
|
|
Loading…
Reference in New Issue