We automate and speed up the process of setting up cloud servers with Ansible. Part 2: output, debug, and reuse a playbook

In a previous article, we started exploring Ansible, a popular tool for automating the configuration and deployment of IT infrastructure. Ansible was successfully installed in InfoboxCloud , the principles of work, basic setup are described. At the end of the article, we showed how to quickly install nginx on several servers.

In this article, we will continue to explore Ansible: we will analyze the output of a playbook, learn how to debug them and separate them for easy reuse.

Configuration management

Analysis of our first playbook

In the last article, we got a conclusion from the execution of our first playbook. Let's take it apart.



Gathering facts is the first default task in any playbook. The task collects useful metadata about servers in the form of variables that can be used in the playbook in the future. For example, such variables can be ip-address, OS architecture, and host name.
You can view these variables using the command:

ansible -m setup experiments

where experiments is the name of the section in your inventory.
or write it to a file

ansible -m setup experiments >> facts

Below in the output are the TASK tasks , according to the progress of the playbook: installing nginx, starting the service.

Let's run the playbook again.

ansible-playbook playbooks/setup_nginx.yml

Compared to the previous output, the Install nginx package task was completed unchanged. Status already reached: nginx is installed. The task of starting the nginx service in both cases was completed without changes, since the nginx service starts immediately after installation. If you stop the nginx service on one of the servers manually, it will rise after starting the playbook.



As we see, one of the key properties of Ansible systems is performed: idempotency (an operation that, if applied to any value several times, it always turns out the same value as when applied once). Most configuration management systems follow this principle and apply it to the infrastructure.

Let's look at the PLAY RECAP section.below in the conclusion. The changed parameter shows how many times the status of the server has changed in tasks. ok - the number of tasks performed along with Gathering facts .

Debug playbook

Understanding what happened while playing a playbook can be very helpful in fixing bugs.
There are 3 levels of debugging output (Verbose).

-v . Output basic information.

ansible-playbook playbooks/setup_nginx.yml -v

-vv . More detailed conclusion.

ansible-playbook playbooks/setup_nginx.yml -vv

-vvv . The most detailed conclusion.
This output identifies the SSH commands that Ansible uses to create temporary files on the remote host to run the script remotely.

ansible-playbook playbooks/setup_nginx.yml -vvv

You can output any ansible variables for debugging. To do this, add the following section to the playbook:

 - name: Debug
    debug: msg={{ ansible_distribution }}

When you start the playbook, you will see the output of this variable. Each Ansible variable begins with the ansible_ prefix .



Another useful command is the ability to look at all the tasks that are performed in the playbook. It is especially useful when there are several playbooks that play on other playbooks.

ansible-playbook playbooks/setup_nginx.yml --list-tasks

You can only perform a specific task from the playbook:

ansible-playbook playbooks/setup_nginx.yml --start-at-task="Debug"

Reuse on Playbook

If a task or a set of tasks is often used by you, it makes sense to arrange it as a separate file that can be used in other playbooks.

Create a folder for reusable tasks:

mkdir ~/ansible/playbooks/tasks

Let's create an OS update task in the file ~ / ansible / playbooks / tasks / os_update.yml :

---
#Update and upgrade apt-based linux
- name: Update and upgrade apt-based Linux
  apt: update-cache=yes state=latest
  sudo: yes

Now we can enable the OS update section in ~ / ansible / playbooks / setup_nginx.yml :

---
- hosts: experiments
  remote_user: root
  tasks:
  - include: tasks/os_update.yml
  - name: Install nginx package
    apt: name=nginx update_cache=yes
    sudo: yes
  - name: Starting nginx service
    service: name=nginx state=started
    sudo: yes

Now, before installing nginx, Ubuntu on the serviced servers from Inventory will be updated.
It is worth installing nginx (~ / ansible / playbooks / tasks / pkg_nginx_install.yml ) into a separate task if you often install nginx.

---
#Install NGINX package
  - name: Install nginx package
    apt: name=nginx update_cache=yes
    sudo: yes
  - name: Starting nginx service
    service: name=nginx state=started
    sudo: yes

As a result, our playbook will become very simple:

---
- hosts: experiments
  remote_user: root
  tasks:
  - include: tasks/os_update.yml
  - include: tasks/pkg_nginx_install.yml

You can also write a task to remove nginx (~ / ansible / tasks / pkg_nginx_remove.yml ):

---
#Remove NGINX package
 - name: Stopping nginx service
   service: name=nginx state=stopped
   sudo: yes
 - name: Remove nginx package
   apt: name=nginx state=removed
   sudo: yes

and call it (~ / ansible / playbooks / remove_nginx.yml ):

---
- hosts: experiments
  remote_user: root
  tasks:
  - include: tasks/pkg_nginx_remove.yml

ansible-playbook ~/ansible/playbooks/remove_nginx.yml -i ~/ansible/inventory

, where through -i we specify the path to the inventory file, which allows us to run ansible-playbook not only from the ansible folder.

In the next article, we will talk about Ansible variables and conditions. Finally, our playbooks will work correctly on different operating systems.

Conclusion

The writing of the article was greatly helped by the book Learning Ansible and of course the official documentation .

All experiments with Ansible are convenient to do in InfoboxCloud , since it is possible for each virtual server to set exactly the amount of resources that is needed for the task (CPU / Ram / disk independently of each other) or use autoscaling.

If you find a mistake in the article, the author will gladly correct it. Please write to the PM or e-mail about it. There you can ask questions about Ansible for coverage in subsequent articles.

Part 3: Variables and the inventory file
Part 4: working with modules
Part 5: local_action, conditions, loops and roles

Successful work!