DevOps Classroom Series – 02/Aug/2020

Anatomy of Ansible Playbook

• In Ansible, we write Playbooks. Playbook consists of one or more plays. A Play associates an unordered set of hosts and ordered list of tasks. Each task will have exactly one module.
• Playbook: Collection of Plays

---
- name: configure apache
  hosts: webservers
  become: True
  tasks:
    - name: install apache
      apt:
        name: apache2
        update_cache: yes
        state: present
    - name: enable service
      service:
        name: apache2
        state: enabled

- name: configure Java
  hosts: appservers
  become: True
  tasks:
    - name: install java
      apt:
        name: openjdk-8-jdk
        state: present

• Play: Each play must have the following

  • A set of hosts to configure
  • A list of tasks to be executed

• Hosts: collection of names/ip addresses from inventory file

• Tasks: Each task is atomic activity in the deployment step. To perform tasks ansible provides modules

• Modules: Modules are the scripts (python) that come packaged with Ansible and they perform some action on the host. Each task can have only one module

  • do we remember this command ansible -m ping all, Here -m stands for module

Ansible Way of Working

• Ansible gives us two major ways of working
  1. Adhoc-commands:
     • We use ansible command line tool to build commands and then execute from ansible control node
  2. Playbooks:
     • We write a playbook using YAML syntax which will have our deployment steps described in declarative fashion
     • We execute the playbook using ansible-playbook command
• Lets evaluate building command lines to do deployment
  • We create multiple commands to deploy application. Every time when we need to do the deployment on different server?
  • How will you track changes in the deployment steps?
• Lets evaluate building playbooks for automation
  • We create a playbook & store it in Version Control System(VCS)
  • Whenever any change happens in deployment steps we will change the playbook & upload the changes to VCS
  • Do we have history of every change?
  • If we need to run deployment on different server, do we need to rewrite playbook?
• In Ansible we use adhoc commands for non-repetitive activities

How to be effective in Configuration Management using Ansible

• If you don’t know manual steps of deployment, you can never be good at Configuration Management.
• Ensure you do the deployment manually once before you try to automate the deployment using ansible/ any other CM
• Generally all the organizations some kind of documentation to deploy applications, from ansible we automate that.
• We take each step of deployment and convert that to task using ansible module

Lets check this by installing an apache server on ubuntu node

• Manual Steps for Apache Server installation:

sudo apt-get update 
sudo apt-get install apache2 -y
sudo systemctl enable apache2

• Lets find modules for apt-get, To find modules there are two ways
  1. Search for modules from here
  2. Go to the Google and search apt-get in ansible
• Once you find ansible module documentation
  • Every module has parameters
  • In module documentation we have examples
• Go through the parameters and use the necessary ones
• From apt module document we found the following parameters to be filled
  1. name = ‘apache2’
  2. state = ‘present’
  3. update_cache = yes
• Basic Task syntax

name: <name of the task as per your docs>
<name of module>:
  <param-1>: <value-1>
  ..
  <param-n>: <value-n>
  state: <value of state>

• From the above parameters my task will be some thing

name: install apache and update packages
apt:
  name: apache2
  update_cache: yes
  state: present

• We need to create play now. For play we need inventory, so lets create a simple inventory called as webhosts

172.31.8.187

• Lets look at basic playbook structure

- name: <name of the play>
  hosts: <where do you want to execute this play>
  become: <if yes it would execute with root permissions>
  tasks:
   - <task1>
   - <task2>

• So our playbook for installing and configuring apache would be

---
- name: 'Install and configure apache server'
  hosts: all
  become: yes
  tasks:
    - name: install apache2 and update ubuntu package definitions
      apt:
        name: apache2
        update_cache: yes
        state: present

• Now adding service enabling the playbook looks like

---
- name: 'Install and configure apache server'
  hosts: all
  become: yes
  tasks:
    - name: install apache2 and update ubuntu package definitions
      apt:
        name: apache2
        update_cache: yes
        state: present
    - name: enable and start apache2
      service:
        name: apache2
        enabled: yes
        state: restarted

• To execute the playbook run the following command

ansible-playbook --help
ansible-playbook -i webhosts apache2.yaml

• Now lets rerun the command

ansible-playbook -i webhosts apache2.yaml

• Now lets change our playbook to this

---
- name: 'Install and configure apache server'
  hosts: all
  become: yes
  tasks:
    - name: install apache2 and update ubuntu package definitions
      apt:
        name: apache2
        update_cache: yes
        state: present
    - name: enable and start apache2
      service:
        name: apache2
        enabled: yes
        state: started

• Now execute ansible-playbook stop the apache manually and re-execute
• When we try to execute ansible it will try to maintain state, so the result of execution will be same, if you are running playbook once or n number of times. This feature is called as idempotance.