How to make your own Ansible roles

In this and next post, we will explain how Ansible works , how to install it and how to create your own roles.

what is ansible
Ansible is an Open Source orchestrator , a software that is responsible for automating the configuration, coordination and control of systems.

Manage nodes via SSH and Python . A controller system contains Ansible and all the files, settings, and tasks that apply to node machines. In this way, it allows centralizing automation and facilitates the administration of groups of systems.

Installing Ansible
To install and use Ansible we will need a minimum of two machines. A Control Node , where the Ansible installation will be done, and another machine controlled by Ansible.

In this case, we will use two Ubuntu Server 20 with these characteristics:

Name   hostname   IP
cnode   cnode.test.com   192.168.1.36
host1   host1.test.com   192.168.1.37
We start the installation on 'cnode' by running these commands:

sudo apt-add-repository ppa:ansible/ansible
sudo apt update
sudo apt install ansible

We generate a pair of keys and copy them to 'host1' , in order to execute the SSH connection:

ssh-keygen
ssh-copy-id 192.168.1.37

Now we create a file /etc/ansible/hosts , in which the groups and machines that Ansible controls are stored. In this case, it will have this content:

[test]
host1.test.com ansible_host=192.168.1.37

We can test that the connection is correct via Ansible:

ansible all -m ping

It should give a result similar to this:

Playbooks
Playbooks are files that contain all the information to execute tasks in a reusable way. For example, a Playbook may contain instructions for installing a service, its prerequisites, and applying a desired configuration.

They are the basic building block for doing operations in Ansible, beyond sending ad-hoc commands. In addition, they give us a lot of flexibility, especially in simpler projects. Next, we are going to test a Playbook with the machines that we have prepared:

– name: Install and configure apache server
hosts: test
tasks:
   – name: Install latest apache2
       apt:
        name: apache2
        state: latest
  – name: Apply apache2 configuration template
     template:
       src: /DATA/files/apache2conf/apache2.conf
      dest: /etc/apache2/apache2.conf
 – name: Restart apache2
   service:
      name: apache2
      state: restarted

Here we use several Ansible tools, the apt, template, and service modules. Each module takes different parameters for the tasks that will be executed in the systems that we indicate. In this case, the hosts in the 'test' group , and thus the machine host1.test.com . This playbook installs Apache2, copies a configuration file from the Control Node, and restarts the service. We try to run it:

ansible-playbook testPlaybook.yml

This is the result we get:

Ansible indicates with the green color the tasks that have been carried out without changes, in yellow those that have caused changes in the server and in red those that have given an error. In this case, the configuration file was invalid and the Apache service could not be restarted. If we relaunch the Playbook with a correct file, the following happens:

This time there has been no change in the installation task, since Apache2 is already present, and with the correct configuration file it has been able to restart without errors.

Conclution
One of the advantages that Ansible offers us is to use these files again, to make changes or solve previous bugs, as we have seen in this post. The large number of modules and flexibility of Ansible allows us to do much more complicated tasks, which would be very heavy to do manually repeatedly.

The next step in Ansible administration is to solve the problem of organizing the files that appear when scaling the number of machines to control. This means increasing the number of playbooks, configuration files, templates, etc.