The Definition of Terraform
So, what does Terraform mean? By using Terraform, developers can programmatically provision the physical resources their applications require in order to run. Terraform is a free open source infrastructure as code (IaC) tool created by HashiCorp.
Terraform allows you to create increasingly complex configurations as you manage your infrastructure with it. Terraform configuration files and directories do not have an intrinsic complexity limit, so you can continue to write and update your configuration files in the same directory. Nevertheless, if you continue, you may run into the following problems:
- You’ll have a much harder time understanding the configuration files.
- Configuration updates will become more complicated since one section’s update can have unintended consequences for other sections.
- As you configure separate development, staging, and production environments, you will have more duplication of configuration blocks, which will cause an increasing amount of burden when updating your configuration.
- Sharing configurations between projects and teams is extremely error-prone and difficult to maintain if you cut and paste blocks between projects.
Learn how modules can solve these problems, how Terraform modules are structured, and how to create and use modules effectively in this tutorial.
Then, you will learn how to use and build Terraform modules to simplify your current workflow.
Why Do We Use Modules?
Starting with its common files, such as main.yml, might be a good place to begin working with Terraform. Particularly when you initially have a simple infrastructure, it is easier to fall into the “we’ll fix it later” trap. The problem with working against the clock (infrastructure, operation, and reliability engineers) is that you will not be able to spend much time refactoring code in the future. In the process of writing your code, you should be considering the quality and best practices. This is important, so let’s explain why:
As your infrastructure grows (or as it gets more complex), you will face more challenges. In this case, your infrastructure will need to be scaled. Engineers face the challenge of scalability on a daily basis. It is very difficult to maintain and utilize a codebase that is intricate without any need for it. If you can’t reuse your code, you’ll have a hard time with maintenance. So, you will need to spend a lot of time studying the code, modifying, testing, and deploying it. These things should happen automatically through a CI/CD pipeline, but you will still have to wait. All engineers and end-users/customers are forced to pay a fraction of this overhead.
What are Terraform Modules?
We should define Terraform modules. A Terraform module consists of all the Terraform configuration files in one directory. Modules can even be made up of a single directory and a few .tf files. Terraform commands run directly from a directory like this are considered root modules. Thus each Terraform configuration can be considered to be a part of the module. It is possible to create a simple set of Terraform configuration files in the following format:
In this case, the contents of the minimal-module directory are taken into account as the root module when running terraform commands from that directory.
There is only one directory in which Terraform commands will use the configuration files directly, which is typically the current working directory. Using module blocks in your configuration, you can call modules located in other directories. Terraform loads and processes the configuration files associated with a module block that it encounters.
When one configuration calls another, it is sometimes called a “child module” of that configuration.
Remote and local modules
It is possible to load modules either from the local file system or from a remote source. Several remote sources are supported by Terraform, including the Terraform Registry, most version control systems, HTTP URLs, and private module repositories on Terraform Cloud and Terraform Enterprise.
What Are Modules Used For?
With Terraform modules, you can abstract some resource sets logically. Modules are a means of grouping resources together and using them again and again.
We’ll consider a cloud-hosted virtual server with a few features. How might one describe that server based on its resources? As an example:
- A virtual machine created from an image
- For additional storage, a block device with a specific size
- A static IP that is also public, and is assigned to the server’s virtual network interface
- To attach to the server a set of firewall rules
- Additional block devices, additional network interfaces, etc.
In this case, let’s assume that you will be building the server with a set of resources regularly. Here, modules are an excellent resource for you – don’t you hate repeating the same configuration code repeatedly?
In this example, we will show how this “server” module can be called.
In a configuration file, calling a module means using it.
Here we create five instances of “server” using a single configuration (in the terraform module example):
How is the Module Organized?
Creating multiple modules makes sense. Here are a few examples:
- An example would be a virtual private cloud (VPC)
- static content hosting (i.e. buckets)
- Load balancers and their resources
- Configuration logs
- As well as any other logical component of the infrastructure that you consider crucial
Imagine there are two modules: one called “server” and another named “network”.The module named “network” is where we identify and configure our virtual network and place servers in it:
The custom modules we create can be referred to as “child” modules. A configuration file that refers to child modules is part of the root module.
It is possible to source a child module from the following sources:
- local paths
- the official Terraform Registry – this is similar to the Docker Registry, so you know what it is
- a Git repository (a custom one or GitHub/BitBucket)
- an HTTP URL to a .zip archive with the module
Is it possible to pass details about resources between modules?
Servers need to be created as part of a network in our example. Is it possible to tell the “server” module to create VMs in a network that has been created within the “network” module?
Terraform Modules: Best Practices
Likewise, Terraform modules provide many of the same benefits as libraries, packages, or modules found in most programming languages. To provide the benefits described above, Terraform configurations should almost always use modules, just like almost any other non-trivial computer program.
Following these terraform modules best practices is recommended for every Terraform practitioner:
- Provider names should be terraformed–. If you wish to publish Terraform Cloud or Terraform Enterprise modules, you must follow this convention.
- Consider modules when writing your configuration. In many cases, the benefits of using Terraform modules outweigh the time it takes to use them correctly, even in modestly complex configurations managed by a single person.
- Your code should be organized and encapsulated using local modules. It is still beneficial to organize your configuration in terms of modules from the start so that as your infrastructure becomes more complex, it will become easier to maintain and update your configuration.
- Find useful Terraform modules at the public Terraform Registry. Utilizing the work of others in implementing common infrastructure scenarios will make it easier to implement your configurations more quickly and confidently.
- Modules can be published and shared with your team. Modules are an important way for teams to collaborate when creating and maintaining infrastructure, as most infrastructure is managed by teams of people. Modules can either be published publicly or privately, as mentioned earlier. The next tutorial in this series will show us how.
Now you should have a better understanding of what modules are.
We’ve tried to provide you with some suggestions for the next steps if you’re just beginning your Terraform journey.
We are happy to answer any questions you may have. With a wealth of tools and technologies, IT Outposts can optimize your business’ success.
Dmitry has 5 years of professional IT experience developing numerous consumer & enterprise applications. Dmitry has also implemented infrastructure and process improvement projects for businesses of various sizes. Due to his broad experience, Dmitry quickly understands business needs and improves processes by using established DevOps tools supported by Agile practices. The areas of Dmitry’s expertise are extensive, namely: version control, cloud platform automation, virtualization, Atlassian JIRA, software development lifecycle, Confluence, Slack, Service Desk, Flowdock, Bitbucket, and CI/CD.