Total Pageviews


November 26, 2017

WebServer Provisioning using Ansible

by 4hathacker  |  in Python at  2:26 PM

Hi folks!

This blog post is in continuation with the previous blog post in which we have discussed about Ansible Ad-hoc commands. In this post, we will be covering the playbook writing for Ansible automation.

Plays or Playbooks are nothing but a list of instructions describing the steps to bring the server to a certain configuration state. For example, if we want to host a website on a system, we need apache to be installed. The initial state of the system is the one in which apache is not present.  We can write a play/playbook to install apache on it. This is a use case of Change Management and provisioning using Ansible.

In the previous post, I have described a default hosts file for my development scenario.

[root@server Desktop]# cat /etc/ansible/hosts
node218 ansible_ssh_host=
node227 ansible_ssh_host=
node228 ansible_ssh_host=
node229 ansible_ssh_host=






Playbooks are written in YAML format with file name extension as .yaml or .yml. This is a human readable data serialization language. YAML offer an "in-line" style for denoting associative arrays and lists. Ansible playbook usually starts with 3 hyphens as "---". The most important thing to keep in mind while writing ansible playbook is indentation and spaces.

Here I am going to accomplish the task of installing apache server in webservers list.

A. To check whether SELinux is enforced or not, and install apache server in webservers machine.

 [root@server hands_on_ansible]# vim apache.yml

- name: check SELinux then install and start apache
  hosts: webservers

  - name: Check to see if SELinux is working
    command: getenforce
    register: sestatus
    changed_when: false

  - name: install and start webserver
     - yum: name=httpd state=present
     - service: name=httpd state=started enabled=yes
    when: ansible_distribution == "RedHat"

  - name: install and start webserver
     - apt: name=apache2 state=present
     - service: name=apache2 state=started enabled=yes
    when: ansible_distribution == "Debian"

1. As we can see, the very first line is '---' which means the starting of apache.yml file. 

2. In the next line, there is '- ' (a dash and a space) with name of the task. A YAML file consists of dictionary means a key and a value (key: value). Here I have defined my hosts as webservers, which will take care of apache installation in only webserver ips.

3. The next line is showing the name of the task to be accomplished. In our case, it is to install apache and checking SELinux. Please note that 'name' is not a module in this line, it is just a way to enhance the readability of user.

4. A list of dictionary is defined as tasks and it contains name of different tasks and modules to accomplish them.

5. The first task is to check if SELinux is working or not. For this command module is used. In command module, a raw command is passed as 'getenforce'. The result is then saved using 'register' in a variable called sestatus. After that, changed_when is used to mark the  task evaluation on a specific condition. The command module will always return a change so to overcome that, 'changed_when' is used and initialised to false. Note that to run SELinux using ansible, the required python bindings to be installed in the host-controller are 'libsemanage-python' and 'libselinux-python'.

6. In the next task, I have separated the installation for apache server, for RedHat machine as well as for Ubuntu machine. For RedHat, I have used 'yum' module to install httpd and then started the httpd service using 'service' module. The whole thing I wrote in a block, using a 'block' module, which will run only after checking whether the ansible_distribution for that node is 'RedHat'. In a similar fashion, the next task check for 'Debian' distribution to install 'apache' using 'apt' module.

Now to run the same, I will write in the terminal:

[root@server Desktop]# ansible-playbook hands_on_ansible/apache.yml

We can observe clearly, the very first, ansible gathers information about the nodes. And then it starts working on the tasks to accomplish as above explained. For Debian tasks, it is showing skipping. Finally it provides a summary of tasks, to take account of change management.


Like Our Facebook Page

Nitin Sharma's DEV Profile
Proudly Designed by 4hathacker.