cancel
Showing results for 
Search instead for 
Did you mean: 
Cody_Green
F5 Employee
F5 Employee

As a recovering developer, I found my first ventures down the path of automation a little more challenging than my peers. You see, I cut my teeth on object-oriented programming, which heavily emphasizes reusable design patterns; if you have never heard of Design Patterns by the "Gang of Four," I highly recommend you check it out. The problem for me was that most examples of automation scripts tend to be single-use strategies that rarely emphasize code reuse.


So why is code reuse significant? Essentially, you only want to do something once! This concept is also known as the don’t repeat yourself (DRY) principle which states that “every piece of knowledge must have a single, unambiguous, authoritative representation within a system”[1]. Repeating code, also known as write every time or we enjoy typing (WET), is inefficient and causes substantial operational overhead.


In F5's State of Application Services 2019 report, only thirty-seven percent of respondents had automated infrastructure in their pipelines. Based on this data, almost two-thirds of respondents are about to start their automation journey. The goal of this article is to help you avoid the common mistake of repeating boilerplate code and show how you can accelerate your path to automation utilizing code reuse patterns with the Hashicorp Terraform Registry.


Terraform Registry Overview

Terraform is a leading automation tool that helps customers build infrastructure-as-code and provides over 160 partner integrations. The Terraform Registry provides a central repository where people can share common Terraform deployment patterns. These deployment patterns are available in a Terraform module, which allows for easy integration into your project. The Terraform Registry categorizes each module into a category based on the cloud provider: AWS, Azure, Alibaba, GCP, OCI, and VMware. The category-based system makes it easy to find a deployment pattern to fit the cloud of your choice.

Systems like the Terraform Registry are prevalent in the software development world. Examples include the NodeJS Package Module (NPM), Kubernetes Helm Charts, and the Python package index (PyPi). If you are new to module/library registries, there are a few considerations you should evaluate when choosing your module.

  1. How active is the module's GitHub repository? Active development allows you to identify modules that are likely to:
  2. address security bugs
  3. add new features
  4. If a module does not cover your specific use case, consider incorporating that use case into an existing module with a pull request versus creating one from the ground up.
  5. Pin the module to a particular release version. Pinning provides stability and repeatability across terraform scripts, which ensures any module updates will not break your code.
  6. Always leverage the most stable and secure release of the module. Add a workflow to periodically check which version of the modules you are using and try to stay within 1-2 versions if possible.
  7. Consider the use of private registries and a secrets management system if the module contains sensitive information. Terraform Cloud offers a private registry that looks and feels very similar to the public Terraform Registry, but the modules are only usable by your organization.


Using Terraform Registry Modules

To leverage a Terraform Registry module in your HCL code, you'll need to add two steps to your normal workflow process.

First, you'll need to reference the desired module, source, and a particular version:

module "bigip" {
 source = "f5devcentral/bigip/aws"
 version = "0.1.2"
}


Secondly, if the module is in a private repository, you'll need to configure the credentials to access the module:

credentials "app.terraform.io" {
 #valid user API token:
 token = "xxxxxx.atlasv1.zzzzzzzzzzzzz"
}


Using the BIG-IP AWS Terraform Registry Module

When leveraging Terraform to deploy a BIG-IP into the public cloud, there is quite a bit of boilerplate code: create a VPC or resource group, create subnets across availability zones, create security groups... you get the point. While these processes are not difficult, it adds complexity to a deployment pattern that should be simple and self-contained. What I mean by this is your Terraform file often has more code on deploying the infrastructure than the BIG-IP itself. While you can split these processes into separate HCL files, my preference is to reuse code whenever possible.

Solution reuse is the prime reason for using the Terraform Registry. With a few lines of code, you can reference a solution to easily create the underlying infrastructure by using Terraform Registry modules for creating VPCs, Subnets, and the likes. F5 DevCentral has also recently published an AWS BIG-IP Terraform Registry module to simplify the deployment of a BIG-IP virtual appliance into AWS, reducing the amount of HCL code to only a few lines. Implementing Terraform modules helps ensure that your BIG-IP deployment is leveraging best practice patterns for the desired cloud provider.


Roadmap and Contributions

While the examples in this blog post focus primarily on AWS, no limitation prevents you from creating modules for Azure, Alibaba, GCP, OCI, and VMware. We are currently working on the release of a BIG-IP Azure Terraform Registry, and we hope to have that out soon. I would also like to note that these projects are open source and code contributions are much appreciated.


Conclusion

In conclusion, by eliminating the amount of boilerplate code and single-use scripts, we can accelerate the speed of completion for infrastructure automation projects, and significantly reduce the lines of code you have to maintain. Leveraging tools like Hashicorp's Terraform Registry make it easy to practice code reuse, which allows you to focus on the unique aspects of your infrastructure versus the common deployment patterns everyone shares.


[1] https://en.wikipedia.org/wiki/Don%27t_repeat_yourself


Comments
MichaelOLeary
F5 Employee
F5 Employee

Nice article Cody!

Version history
Last update:
‎28-Jan-2020 17:00
Updated by:
Contributors