How to write a basic playbook in Ansible : Basics Of Ansible

In this tutorial we are going to learn how to install ansible and its configuration. Later we are going to look at the ansible role structure and try to write a simple playbook. We are going to give a detailed explanation to give a good start and post this tutorial we all shall be able to write many other playbooks as well on our own.

1. Installing and Configuring Ansible

a. Installing ansible on Ubuntu

In  your Ubuntu system or Debian based system we can run the following command to install ansible :

                               sudo apt-get update

                               sudo apt-get install software-properties-common

                               sudo apt-add-repository –yes –update ppa:ansible/ansible

                               sudo apt-get install ansible

This machine will act as the ansible control machine . Fom here we will run scripts and commands to configure and make changes to target machines .

b. Configuring Ansible

To perform any management from the ansible control machine to the remote hosts , ansible makes use of ssh . So we will first have to generate an ssh key and copy it to the remote machine . We can generate an ssh key as follows :

ssh-keygen

To copy the ssh keys to the remote target machine

ssh-copy-id [email protected]_IP_ADDRESS

For example :

ssh-copy-id [email protected]

Now we can use adhoc commands or run ansible scripts to make changes to the remote target machine which will make use of ssh agent.

c. Node Inventory Management

Now we create a directory under which we shall write all our ansible related scripts and inventory files. Under this directory we create a file called hosts. This file will contain the ip addresses or dns names to our remote target machines that we would want to make changes to, and also contains the associated variables necessary to access the target machines. By default the file is present in /etc/ansible/hosts location , but we can create one of our own in the directory we just create and use it only instead.

A sample hosts file would like as follows :

When we run adhoc commands or playbooks we can specify this location of the inventory file, which would be accessed instead of the default hosts file .

We can make this our default hosts file by assigning the path of the hosts file to inventory in ansible.cfg file , from next the hosts file will be used by default and we don’t need to specify the path of the hosts file every time we run an adhoc command or an ansible-playbook. Sample ansible.cfg file looks as follows :

We need to uncomment the inventory and assign it the path to our new hosts file.

So the new location of the hosts file will handle all the remote target machines, if we need to make any changes we shall make it to this file henceforth. All the variables also associated with the target machines are also assigned in this very same file.

2. Adhoc Commands

a. Simple Commands

We can run a simple ping command on a target machine to check whether it is up and running or not.

ansible all -m ping

We can run the same command and target only a group of target servers. We can just specify the group-name while running the ansible command (all targets all the servers present in the hosts file).

b. Adhoc commands using other modules

There are hundreds of modules other than ping and each module in turn has many options to achieve the specific task. We can find all the modules and its documentation in the following link : https://docs.ansible.com/ansible/latest/modules/modules_by_category.html

We can specify the arguments to the command using –a option. A simple ‘apt’ module works as follows :

We can see the status of the target machine to be changed .

If we run the same command again .

This is because apache has already been installed. And we can see that the state has remained the same ,i.e, changed is equal to false.

To uninstall the same thing we can give the state as ‘absent’ instead.

3. Ansible Playbook

a. Creating roles

Ansible, the role is the primary mechanism for breaking a playbook into multiple files. This simplifies writing complex playbooks, and it makes them easier to reuse. The directory structure of the roles can be created as shown:

  • tasks contains the main list of tasks to be executed by the role.
  • handlers contains handlers, which may be used by this role or even anywhere outside this role.
  • templates contains templates which can be deployed via this role.
  • vars other variables for the role.

Here we are going to use the webserver role only. The contents of the file is as follows :

handlers/main.yml looks like,

tasks/main.yml looks like,

vars/main.yml looks like,

The templates httpd.j2 is a configuration file of the apache2 server and index.j2 is just a html page to be hosted on the server. You can find all these files in the following github repository.

https://github.com/reviewscholar/Ansible_Version_Control

  • As we can see in the vars/main.yml file , I have declared a variable called username. This variable is used in the index page of the simple app being deployed on the apache server. If we make changes to this file and apply the playbook, the corresponding data on the web app also changes accordingly .
  • Role for System reboot and changing configuration

Here I have created a role to reboot the system weekly by using a cron module. The role registers a crontab entry in the cron.weekly directory. And runs a command to reboot an Ubuntu system every week.

When we apply these two the hosts in an ansible-playbook it would appear as follows:

And when we can run the playbook using the following command to ensure that it is applied properly to the remote servers.

ansible-playbook PLAYBOOK_NAME.yaml

Replace PLAYBOOK_NAME.yaml with the name of your playbook file.

b. Role to insert the playbooks into github

There are a certain number of prerequisites for this to be done.

  • Firstly we need to initialize our current working directory by using the command.

git init

  • Then we need to create a repository on github and add the link of the remote repository as a remote in the local server.
  • Lastly we need to configure our git credentials on the local system using the following commands :

git config credential.helper store

git push YOUR_REMOTE_REPOSITORY_LINK

Now enter your username and password. This will be stored to push the code to only that particular remote repository. Now the role is simple using basic commands to be run on the localhost:

You can check all my playbooks in the following repository:

https://github.com/reviewscholar/Ansible_Version_Control

Leave a Reply

Your email address will not be published. Required fields are marked *