What is a Module?
Modules are reusable code components that encapsulate the configuration and resource definitions needed to deploy and manage a specific piece of infrastructure, such as a VPC, ECS cluster, or Auto Scaling Group. Each module defines several AWS resources. For example, the VPC module contains resource definitions for subnets, NAT gateways, and more. Modules promote code reusability, modularity, and consistency in infrastructure deployments and can be customized in a variety of ways.
Gruntwork modules are tested in AWS, in a randomly selected region, each time it changes to verify the infrastructure created matches the desired configuration.
When should I use a module?
The Gruntwork Infrastructure as Code (IaC) Library contains hundreds of modules that you can use and combine. These modules are fairly generic building blocks, so you don’t typically deploy a single module directly. Instead, you write code that combines the modules you need for a specific use case.
For example, one module might deploy the control plane for Kubernetes and a separate module could deploy worker nodes; you may need to combine both modules together to deploy a Kubernetes cluster.
We recommend our Service Catalog for common use cases, but our full Module Catalog is available if you have a more complex use case. For a full list of modules available, refer to the Gruntwork Infrastructure as Code Library.
How modules are structured
The code in the module repos are organized into three primary folders:
modules: The core implementation code. All of the modules that you will use and deploy are defined within. For example to ECS cluster module in theterraform-aws-ecsrepo inmodules/ecs-cluster.examples: Sample code that shows how to use the modules in themodulesfolder and allows you to try them out without having to write any code:cdinto one of the folders, follow a few steps in the README (e.g. runterraform apply), and you’ll have a fully working module up and running. In other words, this is executable documentation.test: Automated tests for the code in modules and examples.
We follow Hashicorp's Standard Model Structure for our files (main.tf, variables.tf, outputs.tf). In the variables.tf file we always put the required variables at the top of the file, followed by the optional variables. Although there are often a lot of ways to configure our modules, we set reasonable defaults and try to minimize the effort required to configure the modules to the most common use cases.