github.com/paybyphone/terraform@v0.9.5-0.20170613192930-9706042ddd51/website/docs/modules/usage.html.markdown (about)

     1  ---
     2  layout: "docs"
     3  page_title: "Using Modules"
     4  sidebar_current: "docs-modules-usage"
     5  description: Using modules in Terraform is very similar to defining resources.
     6  ---
     7  
     8  # Module Usage
     9  
    10  Using modules in Terraform is very similar to defining resources:
    11  
    12  ```shell
    13  module "consul" {
    14    source  = "github.com/hashicorp/consul/terraform/aws"
    15    servers = 3
    16  }
    17  ```
    18  
    19  You can view the full documentation for configuring modules in the [Module Configuration](/docs/configuration/modules.html) section.
    20  
    21  In modules we only specify a name rather than a name and a type (as in resources). This name can be used elsewhere in the configuration to reference the module and its variables.
    22  
    23  The existence of the above configuration will tell Terraform to create the resources in the `consul` module which can be found on GitHub at the given URL. Just like a resource, the module configuration can be deleted to remove the module.
    24  
    25  ## Multiple instances of a module
    26  
    27  You can instantiate a module multiple times.
    28  
    29  ```hcl
    30  # my_buckets.tf
    31  
    32  module "assets_bucket" {
    33    source = "./publish_bucket"
    34    name   = "assets"
    35  }
    36  
    37  module "media_bucket" {
    38    source = "./publish_bucket"
    39    name   = "media"
    40  }
    41  ```
    42  
    43  ```hcl
    44  # publish_bucket/bucket-and-cloudfront.tf
    45  
    46  variable "name" {} # this is the input parameter of the module
    47  
    48  resource "aws_s3_bucket" "the_bucket" {
    49    # ...
    50  }
    51  
    52  resource "aws_iam_user" "deploy_user" {
    53    # ...
    54  }
    55  ```
    56  
    57  In this example you define a module in the `./publish_bucket` subdirectory. That module has configuration to create a bucket resource, set access and caching rules. The module wraps the bucket and all the other implementation details required to configure a bucket.
    58  
    59  We can then define the module multiple times in our configuration by naming each instantiation of the module uniquely, here `module "assets_bucket"` and `module "media_bucket"`, whilst specifying the same module `source`.
    60  
    61  The resource names in your module  get prefixed by `module.<module-instance-name>` when instantiated, for example the `publish_bucket` module creates `aws_s3_bucket.the_bucket` and `aws_iam_access_key.deploy_user`. The full name of the resulting resources will be `module.assets_bucket.aws_s3_bucket.the_bucket` and `module.assets_bucket.aws_iam_access_key.deploy_user`. Be cautious of this when extracting configuration from your files into a module, the name of your resources will change and Terraform will potentially destroy and recreate them. Always check your configuration with `terraform plan` before running `terraform apply`.
    62  
    63  ## Source
    64  
    65  The only required configuration key for a module is the `source` parameter. The value of this tells Terraform where the module can be downloaded, updated, etc. Terraform comes with support for a variety of module sources. These
    66  are documented in the [Module sources documentation](/docs/modules/sources.html).
    67  
    68  Prior to running any Terraform command with a configuration that uses modules, you'll have to [get](/docs/commands/get.html) the modules. This is done using the [get command](/docs/commands/get.html).
    69  
    70  ```shell
    71  $ terraform get
    72  ```
    73  
    74  This command will download the modules if they haven't been already.
    75  
    76  By default, the command will not check for updates, so it is safe (and fast) to run multiple times. You can use the `-update` flag to check and download updates.
    77  
    78  ## Configuration
    79  
    80  The parameters used to configure modules, such as the `servers` parameter above, map directly to [variables](/docs/configuration/variables.html) within the module itself. Therefore, you can quickly discover all the configuration
    81  for a module by inspecting the source of it.
    82  
    83  Additionally, because these map directly to variables, module configuration can have any data type available for variables, including maps and lists.
    84  
    85  ## Outputs
    86  
    87  Modules can also specify their own [outputs](/docs/configuration/outputs.html). These outputs can be referenced in other places in your configuration, for example:
    88  
    89  ```hcl
    90  resource "aws_instance" "client" {
    91    ami               = "ami-408c7f28"
    92    instance_type     = "t1.micro"
    93    availability_zone = "${module.consul.server_availability_zone}"
    94  }
    95  ```
    96  
    97  This purposely is very similar to accessing resource attributes. Instead of mapping to a resource, however, the variable in this case maps to an output of a module.
    98  
    99  Just like resources, this will create a dependency from the `aws_instance.client` resource to the module, so the module will be built first.
   100  
   101  To use module outputs via command line you have to specify the module name before the variable, for example:
   102  
   103  ```shell
   104  $ terraform output -module=consul server_availability_zone
   105  ```
   106  
   107  ## Plans and Graphs
   108  
   109  Commands such as the [plan command](/docs/commands/plan.html) and [graph command](/docs/commands/graph.html) will expand modules by default. You can use the `-module-depth` parameter to limit the graph.
   110  
   111  For example, with a configuration similar to what we've built above, here is what the graph output looks like by default:
   112  
   113  ![Terraform Expanded Module Graph](docs/module_graph_expand.png)
   114  
   115  If instead we set `-module-depth=0`, the graph will look like this:
   116  
   117  ![Terraform Module Graph](docs/module_graph.png)
   118  
   119  Other commands work similarly with modules. Note that the `-module-depth` flag is purely a formatting flag; it doesn't affect what modules are created or not.
   120  
   121  ## Tainting resources within a module
   122  
   123  The [taint command](/docs/commands/taint.html) can be used to _taint_ specific resources within a module:
   124  
   125  ```shell
   126  $ terraform taint -module=salt_master aws_instance.salt_master
   127  ```
   128  
   129  It is currently not possible to taint an entire module.