Long, long time ago …
Most of the engineers with at least several years of experience, who used to deal with infrastructure in the past, remember how complicated and time-consuming the IT infrastructure management process was. System administrators or hardware engineers had to assemble servers in the datacenter, attach them to network and storage, install the operating system and configure it based on different teams requirements. Common requests involved the database installation or web server setup and with its configuration. You can imagine how many issues were related with this manual process. Engineers had to tackle simple human errors, lack of consistency in the environment which lead to configuration drifts between infrastructure elements. It was a real challenge for applications which relied on high availability and scalability.
The birth of automation
At the beginning, engineers were using different scripts to achieve the desired state of infrastructure. It was the beginning of the automation process which was evolving through last years. Development of virtualization technologies from virtual machines to containers and increased usage of cloud-native and public cloud platforms had significantly changed the point of view at infrastructure provisioning and management. Most of you came across with a term “Infrastructure as Code” which is the result of the mentioned IT revolution.
Infrastructure as code definition
There are several definitions of IaC, but in general the conclusion is the same:
IaC is the automation of infrastructure provisioning and management using software development principles and practices.
It means that code used to define IT infrastructure is stored under a version control system, you write the code, test it and deploy. It is worth mentioning that here by code I mean a language specific to the tool which is used to automate the setup, provisioning and management of desired infrastructure.
You have a choice from a wide range of easy-to-use tools. You might have heard about Puppet, Ansible, Azure Resource Manager, Chef, SaltStack and many others. Although they are all included in the group of IaC tools, the right choice of one of them depends on the use case and actual goal which you want to achieve. You will pick up different tool for managing infrastructure, installing applications, one time configurations and post install changes.
Image source: medium.com
When it comes to infrastructure management, there is actually one most popular tool to choose – Terraform, which I intentionally left at the end of the list of known ones, as we will explore it in more detail.
Quick look at Terraform
Terraform tool is a single binary written in Golang that can be downloaded from Hashicorp download page (https://releases.hashicorp.com/terraform/).
Terraform consists of three stages:
- write – you define your infrastructure in HCL (Hashicorp Configuration Language) to describe resources to be deployed across cloud provide
- plan – generates an execution plan describing the infrastructure, which may create, update, or destroy resources depending on the existing infrastructure configuration stored in state file
- apply – Terraform performs actions detected in planning phase, taking into account resource dependencies
The main question here would be, how does Terraform know what resources are already deployed, what needs to be created, modified or destroyed. Terraform stores information about the infrastructure in a state file. Terraform compares your configuration with the state file and your existing infrastructure to create plan and make changes to your infrastructure. When you run terraform apply or terraform destroy against your initialized configuration, Terraform writes metadata about your configuration to the state file and updates your infrastructure resources accordingly. By default, the state file is stored on your local machine, however you can configure Terraform to store it on a shared location with additional protection mechanisms like file locking or encryption.
Together with the state file, Terraform offers another useful feature – workspaces. It is nothing more than independently managed and isolated state files. It allows you to separate the state of the infrastructure without any additional effort on the development side.
There might be several use cases in which you may find workspaces extremely useful:
- proof of concept, testing, research
- multiple subscriptions used across company
- multiple environments (development, testing, staging, uat, production)
- multiple regions or locations