The Why’s and What’s
Before the concept of DevOps, the deployment of apps into various environments was a daunting task requiring time, effort, and high skills. A separate Operations Team with extensive knowledge and experience of various servers, virtual machines, and host OS’s (Windows, Linux) used to manually access the server and configure it according to the requirements of the app. And in the cases of small organizations usually, developers of the app are in charge of doing this activity - Well, not a good sight to imagine.
Now thanks to the improvements in the fields of cloud applications and DevOps in recent years, these tasks are becoming less complex. The virtual servers on clouds and onsite physical servers can be provisioned and configured easily in minutes just by executing a script written in a user-friendly language (mostly YAML). This is possible by a concept known as Infrastructure as Code (IaC) which allows us to deal with servers, networks, security groups, databases, etc. as if they are a part of a software. The leading solutions in the market nowadays for IaC are provided by Terraform, Ansible, Chef, Puppet, and some more.
Let’s look at some of the advantages offered by Infrastructure as Code:
- Code once, iterate multiple times: This is possible as the configuration files are coded initially for creating and configuring the environment for an app. These files can be used to spin up multiple environments (for example testing, production, staging, etc.) but also these can be used again to deploy similar environments for apps with the same OS and Package requirements. They can also be tweaked a little bit if the configurations change and “Voilà!”: a new environment is configured and ready to use.
- Immune to Human error: As previously the infrastructure was configured manually and by different people, there used to be errors known as infrastructure deviations. These were minor differences in the configuration of environments due to the manual process of deployment by different people on multiple servers. Now because of using scripts for provisioning and configuration, this process is standardized and immune to human errors.
- Easy scaling: When there is high incoming traffic in your app at a particular time of the day or year, you can create new environments with just a few clicks and commands and deploy multiple instances of your app. Similarly, you can bring down environments when there is less traffic leading to cost efficiency. Scaling environments up and down is as easy as it gets.
Now let’s understand a bit about terraform and ansible and how they can be used in conjunction with each other.
Terraform – The Maestro Provisioner
Think of Terraform as a Master Civil Engineer/Builder, whom you will provide your needs and it will go ahead and build it for you in a matter of minutes. Further, before building the actual thing it will inform and take your consent about the plan it is going to implement.
In the language of software development: It is a tool for creating, modifying, and versioning infrastructures safely, swiftly, and efficiently.
The General structure of Terraform:
- main.tf – For more simpler projects this is the file that has all the code to build up the infrastructure. It contains all the modules and data sources that are needed. If the project is bigger and complex, the files are logically split based on the functionalities.
- variables.tf – It stores the declarations for the variables which are referenced in main.tf.
- terraform.tfvars – It is used to define the default values of the variables.
The configuration files written in HashiCorp Configuration Language (HCL) describe the resources and components which are required to run an app. Terraform then will go ahead and produce an execution plan describing the steps to reach the desired state, and then goes ahead and executes it. If there are changes that are applied to the configuration files, Terraform sees what have been changed and based on this it creates incremental execution plans.
Terraform is supported by multiple cloud providers and the infrastructure that can be provisioned by it includes app instances, networking resources, databases, SaaS features, DNS items, and more.
The main difference between Terraform and other IaC tools is that it does not re-provision resources that are already successfully provisioned if it encounters them in some future execution of the configuration script. Instead, it focuses on the new additions and the failed resources from the previous executions.
Understanding Terraform Workflow
A basic workflow for using Terraform to build the cloud infrastructure will follow the steps shown in the block diagram bellow.
Scope: Identify the resources for the project. Some examples of resources are virtual machines, resource groups, network security groups, load balancer, etc.
Author: In this step, we need to create the configurations of identified resources using HashiCorp Configuration Language (HCL).
Git Repository: After creating the Terraform configuration for the given project, these configuration files are added into the Git repository of the project (or any other version control system which is being used to store and manage the code).
Cloud: Then the repository is linked with the cloud provider for example AWS or Azure to run the scripts in their particular environments to generate the infrastructure.
Initialize: To download the appropriate provider plug-ins for the project and initialize a working directory with the Terraform configuration files, the Terraform initialize command is executed in the project directory containing the Terraform configuration files.
Plan & Apply: Execution of the Terraform plan command creates the execution plan to verify the infrastructure creation process. Further, Terraform performs a refresh in order to determine the necessary actions to be performed to achieve the expected state of the infrastructure. This command helps users to know in advance that the infrastructure being created is matching the expected infrastructure.
After a successful verification of the execution plan, the Terraform apply command is executed to build the real infrastructure with the specified resources. It also creates a state file that stores the existing state of infrastructure and compares the configuration modification files with the existing configuration of the deployed environment.
Ansible – The Configuration Expert
Now after having the basic infrastructure, you find out that it requires some modifications and touch-ups. For this Ansible is your Go-to-guy. Think of it as an experienced craftsman.
Although Ansible is a tool that can do a lot more than configuring existing infrastructures. It is primarily known for the configuration tasks as it is very handy while using Ansible. A whole network of computers can be configured at once using Ansible.
The primary architecture of Ansible consists of two kinds of nodes – Control and Managed Nodes
A Control Node is the main system that Ansible has installed, while the Managed Nodes are the client ones that are connected to the Master Node using SSH or any other authentication technique. The Control Node has a host inventory file containing the IP addresses of the Managed Nodes.
The Control Node sends configuration programs which are known as modules to the Managed Nodes. These programs are saved as Ansible playbooks (terminology for the Ansible specific Configuration files written in YAML) on the Control Node. These modules compare the states of various Managed Nodes to what is mentioned in the modules, finds the mismatch, and then updates the state of the Managed Nodes.
Why using Ansible for Configuration Management
Simple and easy to use – The syntax of Ansible is written in YAML which is a human-readable data serialization language. That means it is very user-friendly and the learning time required to understand it is comparably less. Also, the tasks executed by Ansible are in a synchronous manner by default (no asynchronous-ity involved, phew!). That is why people who are not into software development can also understand the logic written in certain Ansible playbooks.
Community Support – Ansible has good community support and has 1400+ modules on its official site for certain tasks which can involve network management, databases, security groups, web servers, containerization, and monitoring.
No special Needs – Ansible is designed to work on the push technology, and it does not require any additional software to be installed on the client’s side (Managed Nodes). A SSH connection is all that is required by it to start managing remote clients.
Extensible and Flexible – The primary component of a Ansible module is JSON, which means the modules can be tweaked easily according to specific requirements. So, we can say that Ansible is extensible via any programming language. Further, Ansible uses the ‘Batteries included’ approach which means there is no for a custom plugin or code required by it for integration with various cloud platforms. It tries to give the best and out-of-the-box functionalities by itself.
We hope that with this short explanation on Terraform and Ansible, you know a little more on the frameworks used to automate cloud infrastructures. Let us know if you have something to add!
