Spotlight on Terraform
This post was originally published here.
Named from the Latin “terra” for earth plus ‘forming’, the Terraform software is designed for infrastructure shaping at its core. An open source infrastructure automation tool, Terraform completely changes the way that users approach virtualization in the cloud. Terraform is able to serve many of the same templating functions as CloudFormation on Amazon Web Services (AWS) or Azure Resource Manager on Microsoft Azure, but is far more flexible and make use of over 80 official providers.
Infrastructure-as-Code
Infrastructure-as-code (IAC) is a revolutionary approach to building application and software infrastructure. In fact, for many businesses that make extensive use of cloud computing power, IAC is already making a radical difference in the way they approach infrastructure management as well as creation. Just from the name alone, you can probably guess what IAC is broadly about; taking a purely code-based approach to managing infrastructure via virtual machines, rather than utilizing physical on-premise hardware components.
However, there is more to IAC than this.
While not necessarily a ‘breakthrough’ technology, full adoption of IAC remains inaccessible for many still due to the level of expertise required to navigate infrastructure complexity. That being said, it is already underpinned by the same software development practices that are advantageous in the field of application development. Specifically, the use of reusable design patterns, version control and numbering, and robust testing practices. These makes IAC codebases a reliable way of delivering powerful results.
Enter Terraform
If you know anything about the IAC space, you will have come across other Hashicorp products before—the team behind Terraform. Its name is actually a very apt one considering its functions—primarily to create and destroy IT resources. When running an IAC virtual machine, you need virtualized code-based versions of hardware. Terraform allows software developers to auto create and destroy networks, storage instances, DNS addresses, workspaces, modules and a whole host of other infrastructure components.
This makes Terraform a very powerful tool, allowing for the creation and destruction of infrastructure components on the go. To truly understand the potential power of the IAC concept, it helps to compare it with the development situation that existed before Terraform.
Traditional IAC approaches depended upon a configuration manager (CM) to handle the configuration of operating system environments (OSEs) running on every virtual machine created. The virtual machines would have to be offloaded to the CM every time they needed patching, altering, or configuring in any way.
Terraform, however, is able to handle all of this on its own.
Who Needs Terraform?
There are a variety of use cases where Terraform is of tremendous benefit. The tool effectively eliminates the need for extra configuration layers in many applications. For example, Software Defined Networking (SDN) is growing in popularity within data centers. SDN enables more control on the part of both ops and devs, while also offering better support for any applications running on top of it. In most cases, both a control and an infrastructure layer would be needed. With Terraform, however, the configuration settings can be codified. Terraform can then apply the appropriate settings automatically and modify them directly.
Using Terraform to Manage Kubernetes
Terraform can be utilized to provide full lifecycle management for Kubernetes resources. This includes the ability to create and delete services, replication controllers, and Kubernetes Pods themselves. Not only this, but Terraform can handle the configuration of those resources without having to inspect the API.
Because Terraform is able to understand the relationships between components better than Kubernetes, it is able to set its own order of operations and will avoid attempting commands that it knows will fail.
Best Practices
In order to get the most out of Terraform as an IAC management tool, you should try and stick to the following Terraform best practices:
Use Modules
In Terraform, writing your code into modules will make managing your projects considerably easier, while also allowing you to reuse your most common pieces of code with just a few lines in any application. For example, if you have a node-app that consists of security groups, auto scaling groups, and a few other components, you can write the code to initialize and configure these, then save it as a module. This allows you to write shorter resource blocks that hold specific variables, thus giving you flexibility and standardization in a few lines of code.
Organize Variables
When used correctly, Terraform can dramatically improve the efficiency of your workflow. In order to get the best out of both Terraform and your software developers, one of the simplest things you can do is to set the rules regarding variables early on.
In order to properly implement variables in Terraform, make use of TFVFARS files. You can specify and set these variables in code or at the Terraform command line. Terraform’s official best practices indicate that users should always place variables in external files.
Workspaces
Leverage maps and the Terraform workspace variable to deploy similar stacks of dev, staging, and production. Workspaces allow you to manage multiple environments and independent states on the same configuration.
Before this feature, handling multiple environments meant creating a folder per environment/cloud provider account and attempting to keep track of many duplicate .tf files. Now, it’s just a case of configuring the workspaces you require and Terraform will store your tfstate in the environment folder in an S3 bucket.
Protect Privacy by Controlling Access
As with all software solutions, Terraform is only as secure as the administrator controlling it. Fortunately, if you remember to stay vigilant, and get into the habit of always placing private data in files that have the appropriate security policies in place, Terraform makes it easy to maintain privacy and access control.
Any DevOps environment is going to be in danger of a distracted team member unwittingly overwriting vital configurations. Implementing appropriate access control measures is the best defense against this. A lock table such as Amazon’s DynamoDB is a popular choice and makes for an effective access control mechanism helping to keep your systems safe and secure.
Remote States and Backup
Terraform supports remote states, which allows for teams to ensure they are all working off the most current network state no matter where they are in the world. It also enables the aforementioned security levels and allows for better backup procedures too.
Backups are vital to any network, and yet many system administrators make the rudimentary error of placing their backups on the same storage medium as the original. Remote backups are much more secure and can be stored in a cloud storage service, such as AWS Simple Storage Service, or Microsoft Azure storage. Given how easily available these solutions are today, there is no reason not to take this approach.
If like us you’re keen to adopt DevOps, understanding infrastructure-as-code is a must and we would highly recommend Terreform as the way forward. Cloud computing is an area of continued importance and growth to both consumers and industries, and Terraform is as exciting today as when it was released in 2014.
If you’re keen to get your hands dirty with Terraform but don’t know where to start, check out my beginner through to advanced Udemy course on Terraform with AWS—which is currently on offer for a limited time only.
Caylent offers DevOps-as-a-Service to high growth companies looking for help with microservices, containers, cloud infrastructure, and CI/CD deployments. Our managed and consulting services are a more cost-effective option than hiring in-house and we scale as your team and company grow. Check out some of the use cases and learn how we work with clients by visiting our DevOps-as-a-Service offering.