Introduction to Ansible Playbooks
Ansible playbook is a file that contains a set of instructions or configurations that needs to be applied on a specific server or a group of servers. It is written in YAML know as Yet Another Markup Language. It describes the Desired State Configuration of the servers in our environment. We can also use Ansible Playbook to orchestrate some of our manual ordered processes. Ansible playbook is more powerful than the ad-hoc commands in Ansible as we can run only one task in ad-hoc command, however, we can write multiple plays and run multiple tasks under one play in Ansible Playbook. We use the‘ansible-playbook’ command to execute the playbook.
Attributes of Ansible Playbooks
Let’s understand the attributes of Ansible Playbook using below playbook (nginx.yml):
- hosts: ansible_client.lab.com
- name: Install nginx
- name: copy configuration file
- restart nginx
- name: Check nginx service is running and enabled
- name: restart nginx
1. hosts: It defines a server or a group of servers on which we want to run the tasks mentioned under it. We can use a pattern to define the hosts. We can use patterns to define hosts. We can run tasks against one or more servers or one or more groups separated by colons, like host1:host2 or webserver:dbserver. We can use wildcards as well like ‘web*’ defines all hosts that start with the ‘web’. Defined hosts must exist in the inventory. Example of some patterns are as below: –
|all or (*)||All hosts in the inventory|
|node1 or group1||only one host or one group|
|node1:node2:node3 or group1:group2:group3||Multiple hosts or all hosts in group1, group2, and group3|
|group1:!group2||All hosts in group1 but not in group2|
|group1:&group2||All hosts in group1 that are also in group2|
If we are running a playbook on all hosts in inventory then we can control the order of the hosts. We can define ‘order’ as inventory, reverse_inventory, sorted, reverse_sorted, and shuffle.
2. vars: It defines variables that we can use in the playbook. Same as the other programming language.
3. remote_user: It defines user under which tasks are going to run on the hosts. We can define different remote_user to each task if requires. We can use ‘become’ keyword and make it ‘yes’ to provide sudo access to the remote_user if the remote user is not root, however, in the above example, we are running tasks under ‘root’ user.
4. tasks: We define tasks in a playbook. It defines what to do on the mentioned hosts. Tasks execute in sequence as define in the playbook from top to bottom. Each task has one module associated with it that tells tasks what action has to perform on the hosts. The power of the Ansible is modules, there are a lot of pre-built modules available in Ansible and we can create our own modules as well. For example, it has a ‘yum’ module to install the package on RedHat based OS, ‘service’ module to work with services, ‘file’ module to work with files, ‘shell’ module to execute shell command on the hosts, etc.
We have used ‘yum’, ‘template’, and ‘service’ module in the above example.
5. tags: We can give a tag to the task and we can specify the tag while running the playbook so that only those tasks will run which has the same tag. It is useful if there are many tasks in the same play, for example, few tasks are related to web servers and few tasks are related to DB servers then we can tag the tasks related to web servers with one tag and DB servers with different tag and whenever we need to run only tasks that is related to web servers we can use the tag associated with web servers and vice-versa.
We have used the tag ‘nginx_service’ in the above example.
6. handlers: It defines the next action if there is any change made to the host after completion of any tasks that has a ‘notify’ attribute associated with it. Handler executes only once even if the same handler notified by multiple tasks. It runs at the end when all tasks in the play have been completed. There are multiple handlers can be notified by a single task.
We have one handler named ‘restart nginx’ in the above example and it will be triggered by the task ‘Copy configuration file’ as we need to restart the nginx service if any configuration changes have been made.
Let’s run the above playbook using below command and understand the options that we can pass while executing the playbook from the command line: –
Explanation: – In the above example, we have run the Ansible playbook ‘nginx.yml’ without any optional arguments. There is one play in the playbook. It starts the play and runs a default task called ‘Gathering Facts’. After gathering the facts about the host, it runs the first task from the play i.e. ‘Install nginx’ and then second task ‘copy configuration file’, this tasks also triggers the handler as there is some changes made to the hosts by this task and then the last task executes that ensure nginx service is running and it is enabled. Handler ‘restart nginx’ runs at the end once all tasks are completed.
Let’s understand the color code: –
- Green – No changes made to the hosts
- Yellow – Changes have been made to the hosts
- Red – Task failed due to some reason
Arguments of Ansible Playbooks
There are many optional arguments can be passed to the ansible-playbook command, let’s discuss some essential options: –
1. –list-hosts: It does not change anything on the hosts, just displays the list of hosts on which that play is going to execute.
ansible-playbook nginx.yml –list-hosts
2. –list-tags: It shows all available tags in the playbook.
ansible-playbook nginx.yml --list-tags
3. –list-tasks: It shows all available tasks in the playbook and also associated tags with that task: –
ansible-playbook nginx.yml --list-tasks
4. –skip-tags: We can skip the tasks that is specified with –skip-tags. It will run other tasks that do not match the tag or any tasks that do not have any tags at all. Here, it runs ‘copy configuration file’ as this task does not have any tag specified in the above playbook. Other tasks have tag ‘nginx_service’
ansible-playbook nginx.yml --skip-tags nginx_service
5. -e: It allows us to set any extra variables as a key=value pair that is used by the playbook. We can also use ‘–extra-var’ or ‘extra-vars’.
ansible-playbook nginx.yml–e max_client=100
6. -i or –inventory or inventory-file: It is used to provide different inventory file instead of default while running the playbook.
ansible-playbook -i inventory.ini nginx.yml
Ansible playbook allows us to reuse the code as we can save the file as a YAML file and run whenever required. It organizes all the tasks in a file for better understanding. We can put these playbooks on any SCM(Source Code Management) tool and used the advantage of the SCM tool as well.
This is a guide to Ansible Playbooks. Here we discuss the attributes and arguments of Ansible Playbook along with respective examples for better understanding. You may also look at the following articles to learn more –