Terraform allows infrastructure to be expressed as code … in a simple, human-readable language.
That’s how HashiCorp describes Terraform on its website.
But why do I need Infrastructure as Code? And is Terraform really the tool we’ll be using in the future?
I’ll be answering these very questions – but let’s start with the basics:
What does “Infrastructure as Code” mean?
The basic concept is simple:
During programming we explicitly describe a particular solution. If a program has to perform a certain task, we give an exact definition of what the input into the program as well as the subsequent output should look like.
So, if a simple calculation is to be performed, say:
1+2=3
we define the numbers and the result of the calculation in the form:
X+Y=Z
Infrastructure as Code extends this basic concept to the resources required:
Infrastructure as Code (IaC) is the process of managing and provisioning computer data centers through machine-readable definition files, rather than physical hardware configuration or interactive configuration tools.
In other words, the infrastructure adapts itself to the program. In the past, the server and its hardware determined which program could be used.
For this new approach to work, a certain “flexibility of resources” (= a high amount of hardware) is required. And that’s just what the Cloud provides.
A system is required that manages these resources like a single programmable computer. Once the system is to be “programmed” as a whole, we need a list of dependencies and their interplay.
The IaC approach takes the configuration management as its model, automating methods and processes in the service life of a (classic, physical) product. In this way, the systems are also managed and coordinated during their transitional states. We say a system is in a “transitional state” if (for example) a server is currently “being created” and is held between the states of “order for creation” and “ready for operation”.
We generally distinguish between two variants of configuration management software:
- Declarative systems fully define the final state of the infrastructure. The system must contain a flow chart of the processes in order to attain its end result as a defined state.
A declarative system can be illustrated with Excel. For example, if you enter the following code in an excel field:
=SUM(X1;X2),
Excel will add field X1 and field X2.
The “result field” need not be modified if only field X1 and X2 are to be summed. This formula therefore “always” applies under certain preconditions.
- Imperative systems record instructions required by the system guidelines. The final state of the infrastructure is then the result of the sequence of instructions.
Illustrating an imperative system by means of a calculation would be too complex. Rather, a set of LEGO building instructions serves as a much better comparison. In imperative systems, as in LEGO, the different elements are successively stuck onto one another according to the instructions, until the desired construction is achieved.
In IT, fully automated processes – i.e. imperative instructions – are completed according to the system (e.g. in Chef). Alternatively, a final state is assigned to a system or objective and “built up” using various modules (Puppet, Ansible, Terraform).
Since cloud solutions can become very complex and may consist of a dozen or several hundred interconnected resources, automating the solution has become essential. It’s the only way to ensure reliable and repeated availability of the solutions.
Can’t scripts be used as well?
One possible way to achieve these objectives is to create scripts in (e.g.) Bash, PowerShell or even a programming language such as Python.
But adding to scripts and keeping them flexible enough for adapting to constantly broadening and changing conditions is a lot of work.
A configuration management software such as Terraform takes on this work by covering various provider APIs in a single program.
All these plug-ins are addressed via the easily readable Terraform syntax. This unifies deployment – regardless of the cloud provider being used.
Since Terraform provides the basic functionality of every service for all APIs, “all that remains to be done” is a declaration of the completed infrastructure, and the configuration files for Terraform can be provided.
Completed sample libraries are already available for various configurations of certain parts of the Azure infrastructure.
These libraries always consist of a “main.tf” and several “variables.tf”.
How can I use Terraform?
So far, so good…
There are various ways to create and use an infrastructure in Azure with Terraform:
- The Terraform Binary can be downloaded for free at:
https://www.terraform.io/downloads.html (licensed under MPL2, by the way).
Operation can then start on the administrator’s local machine – given a login into the correct tenant in Azure as well as the correct subscription.
- Things are even easier in the Azure Cloud Shell: merely a storage account with 5GB storage space need be reserved: Documentation
Source: own representation
Here Terraform is placed directly adjacent to the resources to be operated and is already fully preconfigured. All features that can be started locally via installation of the Terraform files are already programmed in the Cloud Shell.
The Cloud Shell also allows managing shared data from different administrators in the Storage Account. All administrators using Terraform can then work in the same directory.
But Terraform becomes really attractive when combined with a version control system such as Git or AzureDevOps, with the infrastructure also being versioned according to the version of the provided APP.
Moreover, these systems simplify testing and working on the code, especially for a larger number of subscribers.
All that remains is therefore to determine what the final solution should look like given the customer’s expectations:
