Introduction to Ansible - Part 5

Introduction to Ansible - Part 5

In the past 4 posts I did a quick Introduction to Ansilble, a quick overview of some of the important config files that you should be familiar with, along with how to run Ansible commands and Ansible playbooks. You can find the links to Part 1, 2, 3  and 4 here:

https://bobbyiliev.com/blog/introduction-to-ansible-part-1

https://bobbyiliev.com/blog/introduction-to-ansible-part-2

https://bobbyiliev.com/blog/introduction-to-ansible-part-3

https://bobbyiliev.com/blog/introduction-to-ansible-part-4

Overview

In this last post of the 5 part blog post series I'll give you a quick introduction to the Ansible Facts, some useful tips and a quick overview of the Ansible handlers.

If you don't have your 3 servers yet make sure to check the part 2 of the series! You can get a free $50 credit that you could use to deploy your virtual machines and test the guide yourself on a few Digital Ocean servers:

Digital Ocean $50 Free Credit

Ansible Facts

The Ansible facts are simply some data that Ansible would collect for us from the remote system.

Here's an example:

ansible your_server -m setup

As this would return a lot of information you could use the filter tag to look for a specific thing:

ansible your_server -m setup -a filter=*ip*

ansible your_server -m setup -a filter=*hostname*

Output:

Ansible Facts Bobby Iliev

The best part about the ansible facts is that you could use this information in your playbooks.

Example:

"{{ ansible_hostname }}"

You don't have to define this var as this is already available for you via the Ansible facts.

As a side note you can use the --tree flag to forward the output to a file.

Also as gathering the facts takes some time, we could set the gather_facts to no in our playbook, but by default it is set to yes:

gather_facts: no

Ansible Tips

You could use the debug module to do some troubleshooting. It would print out some debug information about the tasks that are running.  You could use one of the following two arguments but you can not use both at the same time:

msg - this would basically print out a message out while you run the playbook

var - it would print out the variable content on your screen.

Example:

- hosts: webservers
tasks:
- debug:
  msg: "System {{ inventory_hostname }} has uuid {{ ansible_product_uuid }}"

Another important module is the register module. It takes the output of a task and puts it in a variable. Example:

- hosts: all
tasks:
- name: Register example
  shell: cat /etc/os-release
  register: os_version_var
- debug:
   msg: "The OS version is: {{ os_version_var }}"

This can be really handy for troubleshooting, you can register the output of a command with register, and then make decisions based on the exit code.

Here's the output that you would get:

Ansible Bobby Iliev Introduction

Ansible Handler

We can use handlers to restart services only when needed - for example only if a change is made to the apche2 config and not every single time when we run the playbook.

One thing that you have to keep in mind is that the handler should be on the same level as the task and should trigger the name of the action.

For more information take a look at the official documentation here:

https://docs.ansible.com/ansible/latest/user_guide/playbooks_intro.html#handlers-running-operations-on-change

# Example playbook
---
- hosts: webservers
become: yes
tasks:
- name: Install Apache2 Latest
  apt:
    name: apache2
    state: latest
- name: create index.html
  file:
    name: /var/www/html/index.html
    state: touch
- name: Add some content to the index.hml file
  lineinfile:
    line: "Bobby Iliev Ansible"
    path: /var/www/html/index.html
  notify: "restart apache2"
- name: Start Apache2
  service:
    name: apache2
    state: started
handlers:
  - name: Restart Apache2
    service:
      name: apache2
      state: restarted
      listen: "restart apache2"

The key part here is the listen keyword, this means that the handler task would be triggered only if the "restart apache2" is called with the notify module.

Ansible Handlers Bobby

Conclusion

Hopefully this was helpful! I would strongly recommend deploying a few droplets on Digital Ocean and testing all of the above yourself.

What's next? I would recommend testing all that by yourself so you could get a better feeling of the tool! Also you could go though a more advanced course on the linux academy site: https://linuxacademy.com

If you have any questions please feel free to reach out to me!

 

 

Coffee For Me