Ansible

Ansible is an open-source automation tool that automates configuration management, Infrastructure provision (cloud, vmware and etc), application deployments and etc.

The Ansible configuration file is usually located at /etc/ansible/ansible.cfg. If ansible didn’t find the ansible.cfg file in the current directory or parent directory then it will use /etc/ansible/ansible.cfg.  Here we can find an example ansible.cfg file at the directory below


location is /home/ec2-user. So all Ansible variables will load from /home/ec2-user/ansible.cfg file.

How ansible Works

Ansible uses SSH to push configurations.

Inventory

“Inventory” is a file which contains IP address or Hostnames. By default the Ansible inventory file is /etc/ansible/hosts. We can mention the path of inventory file in Ansible.cfg file or we can use the “–i” option while running play books or adhoc commands. Here my inventory file is /home/ec2-user/invent/inventory

There are three types of inventories.

  • Static Inventory
  • Dynamic Inventory.
  • In memory Inventory

Static Inventory

Static Inventory is file which contains hosts, groups of hosts and groups of groups


Dynamic Inventory

Hosts in inventory are dynamically generated as “dynamic inventory”. Usually, this can be used for public or private clouds and other applications. Maintaining a static inventory for cloud providers is very difficult because some resources will spin up automatically. Some cloud providers (AWS) have some scripts (ec2.py) to get host details and can be used as inventory for Ansible.

  1. One of the advantages of Ansible is resource provisioning for public and private clouds. For example, some Ansible scripts are responsible for creating instances in AWS. While scripts are running, Ansible can deploy applications and install packages on a newly launched instance. The module “add-host” is responsible for creating inventory for newly created instances.

Tags

Tags play an important role in Ansible playbooks. Tags can be used for roles and tasks and If we run playbook by default, all tasks will be run one by one. If we need to run some particular task or role, tags will be useful and vice versa. If we didn’t want to run some tasks we can skip using tags

For This example only ec2 tag will run.


Resource tags

For Public and Private Clouds resources can be identified with resource tags. Tags contain key and value pairs.


Here, the key is name and value is ansible


Sample Stack (Detailed explanation)

Ansible is a powerful automation tool that can be used for continuous integration and deployment processes. Here are some examples for CI/CD .

Preface

Here we will demonstrate how Ansible can be used for CI/CD process.

Goal

The creation of a playbook that will be responsible for provisioning resources and deploying applications. The same playbook can also be reused for provisioning and deploying different applications.

Scenario

Two web servers running with Apache behind a load balancer in AWS.

Here our goal is:

  • spin up two servers
  • install an Apache package
  • deploy an application
  • create an elastic load balancer
  • add instances to load balancer

In order to reuse the play book, some roles are created below

  • Instances provision.
  • Apache package installation
  • Deploy application
  • ELB provision
  • Registering instances to ELB.

Role 1(. Instances provision)

Role name is ec2provision.


ec2 (ansible ec2 module)

This module will create new instances. For snipping up new instances a few things are required:

  • key name,
  • instance type
  • image
  • region
  • security group
  • number of instances
  • vpc subnet id

Instance tags will be used to identify instances.

  1. Wait_for:- to check instances are up running and able to ssh instances.
  2. Ec2.py –refresh-cache will be used to refresh dynamic inventory. So that this particular instances will add in to dynamic inventory
  3. Meta: refresh inventory also will do same thing. It will refresh local inventory. All variables were initialised at defaults/main.yml file.

Role 2(Apache package installation)

Here any package can installed by giving the package name variable.The default value is httpd, initialized at defaults/main.yml file

Role 3 (Deploy application)

Simply, just copy files to instances.


Role 4(ELB provision)

ec2_elb_lb module will responsible for creating ELB. All variables were initialized at: defaults/main.yml file.Ec2_elb_facts will gather facts for ELB .


  1. Role (Registering instances to ELB)

Ec2_instance_facts is useful for instance facts and will query using tags. Using instance facts can register instances to a specified ELB name.


Final script deploy, full stack.

Here all roles are called and Ansible tags have been attached. A dynamic inventory has been used for the Apache installation and deploy application roles. This will create a full stack as per target plan within a web server’s instance tag and WebELB as ELB name.

If you want to create another stack, change the tag values and ELB names respectively, but, you can also reuse this playbook for other purposes


 

About iZeno

iZeno was founded in 2003 on the principle of providing enterprises with best-in-class solutions they need to keep their business running seamlessly. With a team of 70+ innovators, in-house, we have delivered over 500 Enterprise Solutions, implemented and optimized to enable smarter insights.

Our team draws on industry experiences in accomplishing a portfolio of mission-critical applications, integrating Cloud, CRM, Data Analytics, and other leading technologies with our clients existing IT frameworks.

With a leading presence in the region, headquartered in Singapore and operation in Malaysia, Indonesia, Thailand and Philippines, no project is too complex for us, and our team is always ready for a new challenge.

Get in touch with us here.