Ansible: Do more with ease.

Table of contents

Reading Time: 5 minutes

In software engineering, software configuration management (SCM or S/W CM) is the task of tracking and controlling changes in the software, part of the larger cross-disciplinary field of configuration management. SCM practices include revision control and the establishment of baselines. If something goes wrong, SCM can determine what was changed and who changed it. If a configuration is working well, SCM can determine how to replicate it across many hosts.

We now have talked that talk but is it easy enough to walk that talk? Since most of the challenges faced during configuration management are generally related to learning. Configuration management should require minimal learning which means we should be able to do away with complexities of the configuration with ease in syntax too.

In this blog, we’re going to take the first leap of faith into the world of ansible.

INTRODUCTION

Let’s start with some of the requirements which are often challenging to deliver by an SCM. Here we go…

Reliability in operation is one of the demands in configuration management since most of the operation we will delegate to remote hosts will affect the state of the system. We need to ensure idempotency in these operations so that multiple executions of the same operations will not disturb the state of the machine.

“We can include that as a dependency” sounds easy when you hear it but not when executed. Management needs to ensure the lightness of the environment. They should not impose any additional dependency on the environment.

Where we need to hit the home run is that with consistency along with the crispness of having an agentless architecture. By Agentless architecture we should be able to handle the events of the modules. We shall not require a daemon which constantly polls the controlling mechanism for the response. This polling and installing a daemon is both time-consuming and heavy.

Ansible takes all those challenges one by one and hits the home run with yaml powered Playbook.

Ansible

Category of fictional device or technology capable of instantaneous or faster-than-light communication. We will hope to do just that but first, But let’s walk before we start to run.

What to do with Ansible

We will perform just one of the many tasks it makes easy. Currently, we will focus on a couple of simple tasks to elucidate the ease with which we can delegate tasks to remote servers.

PREREQUISITES

Ansible installed on your system.

Have an AWS account and Create a simple EC2 server.

PROCESS

For starting out with ansible, we must discuss two key terms related to ansible.

Inventory: contains the description of the nodes that can be accessed by Ansible. By default, the Inventory is described by a configuration file, in INI format, whose default location is in /etc/ansible/hosts. Hosts file also contains the description in commented form to describe how on must define servers, server groups, and stand-alone IP addresses.

Open your terminal and hit the following commands to check the list of hosts.

 >cd /etc/ansible/
 >cat hosts         #this will display the file.

You can later edit the same with vi or gedit.

Playbooks: expresses configurations, deployment, and orchestration in Ansible. By orchestration, we mean to control various nuances of the infrastructure with detailed control over how many machines to handle over time.

Also, Playbooks do not require any special IDEs you just need a simple text editor. The filename of the playbook should be named: <filename>.yml.

Playbooks always start with a —. Playbooks allow us to define hosts, groups, and tasks which host will perform. All this can be done in a simple, human-readable way.

I hope you have created your EC2 server. Get the local IPv4 address of the remote machine.

Now lets’ append that I.P address to /etc/ansible/hosts.
You can do this as follows:

[webserver]
10.25.1.56

Save the file and on the command prompt, run

>cat hosts

and see that the change persists.

If you’re not able to make changes to the host’s file, you may try the following:

>sudo vi hosts

Now that we know that the server is running, we should be able to connect to the remote server through our machine. We can do so as follows:

>ssh -i `location of your.pem` `username`@`remote IP address`

If you have already generated ssh keys the simply type the following:

>ssh user-name@remote IP address

Now that, we have our server up and running, let’s create a playbook file. In this example, we will create a simple playbook which will create a file on the remote machine in location: /tmp

Create a folder to place the .yml file. Open the file in your favorite text editor.

---
 -hosts: webservers
  tasks: 
   -name: Create file
    file:
      path: /tmp/helloWorld.txt
      state: touch

Make sure you do not use tab while you edit this file. It will pose a syntax error.

Here hosts have machine/ groups which are in your infrastructure and you want to target it to complete a particular task. They consist of one or more groups separated by colons.:

Here our group is webservers so we will put: hosts: webservers

tasks contain the module which a host needs to run. Tasks block contains the following pieces of information:

name: contains the textual description of the task we are to run. This description is required in case our task fails.

file: This block consists of information about the file we are going to create.

path: contains the location of the remote machine where we are going to create the file. the path has aliases: dest, name

state: If touch (new in 1.4), an empty file will be created if the path does not exist, while an existing file or directory will receive updated file access and modification time, just as it runs in a local machine.

Save the file and run the following command:

>ansible-playbook locations of the file

Once the file executes, successfully you will be able to see its results in the server you connected to with ssh. Change to that tab where your server is logged in and run the following command:

>cd /tmp
>ls

And you will be able to see the file you’ve created. Simple, isn’t it?

Now we will take another step and will add some content to this file we have created.

Let’s create another playbook. Go to your directory and create a new .ymlfile.

Contents of the file are as follow:

---
....
   tasks:
    -name: append some content to helloWorld.txt
     copy:
       content: |
                hello, server
                -user.
       dest: /tmp/helloWorld.txt

The copy, used here, module copies a file from the local or remote machine to a location on the remote machine. Here we are using text to be copied from local to the remote server.

Here we have used content, When used instead of src, sets the contents of a file directly to the specified value. For formatting purposes, we will use templates.

Having edited the file, save and execute it using the ansible-playbook command given above with file name changed to the current file.

After successful execution, you can check the content of the file on your remote machine as follows: