Understanding playbooks in Ansible
My previous blog talks about overview of ansible, installation steps and a small demo on basic functionality of ansible.
Ref Link
Ansible-Configuration Management System
Scope
This blog will help you understand the basics of playbook and its terminologies.
Ansible Playbook
A playbook consists of simple set of steps called tasks that run on remote machines defined in inventory file. These tasks are written in simple text language(YAML), which is much easier to understand as compared to XML, JSON, etc.
YAML basics required to understand playbooks can be found in ansible documentation.
Ref Link
http://docs.ansible.com/ansible/YAMLSyntax.html
A playbook can have ‘n’ number of plays in a list. In the following example, the first play has set of tasks for ubuntu servers and the second for centos servers. Grouping of hosts can be done in the inventory file.
Sample inventory file
[js]
[ubuntu]
172.0.0.1
172.0.0.2
[centos]
172.0.0.3
[/js]
Sample playbook
[js]
1st Play
– hosts: ubuntu
gather_facts:yes
sudo : yes
tasks:
– name: Install Jetty
apt: pkg=jetty state=installed
notify:
– restart jetty
– name: ensure jetty is running (and enable it at boot)
service: name=jetty state=started enabled=yes
handlers:
– name: restart jetty
service: name=jetty state=restarted
2nd Play
– hosts: centos
remote_user: root
tasks:
– name: Install mysql
yum: pkg=mysql state=installed
[/js]
Basic Terminologies
- hosts: It can be all/ubuntu/centos(group names as defined in inventory)
- gather_facts: Whenever ansible interacts with hosts it gathers some information about them such as distribution, os family, etc. This information is called FACTS. We can see this information by calling “setup” module from our command line(ansible hostname -m setup)
- sudo: Some tasks like installation of packages require root access. This can be achieved by setting sudo directive as yes
- Handlers: They will only run if a ‘notify’ directive is declared. It is useful in scenarios where a configuration file is changed multiple times and each time it requires a service to be restarted or a machine reboot is required. Handler will make sure that the service is restarted only ONCE.
- remote_user: We can define remote_user in playbooks. It can be any username that run a set of tasks in remote machines. For eg: If we are running ansible in control node as ubuntu user and we are trying to install a package in centos machine that requires user to be root, in that case we can set remote_user directive.
Command to run ansible playbook
[js]
ansible-playbook demo.yml
[/js]
where ‘demo.yml’ is playbook name
Dry Run mode
[js]
ansible-playbook demo.yml –check
[/js]
This mode does not make any changes to remote machines. This only shows what changes would have been made.
TASKS
In simple words, tasks can be defined as calls to ansible modules. They are executed from top to bottom. By default ansible run tasks synchronously. Synchronous tasks wait for the current task to complete before moving to the next task.
Example of synchronous Task (Default Behaviour)
[js]
tasks:
– name: Install Jetty
apt: pkg=jetty state=installed
– name: Copies a file from control machine to all hosts
copy: src=/opt/sample.txt dest=/tmp/
[/js]
name – We can give any descriptive name to a task
apt,copy – modules in ansible
Asynchronous Tasks
Async mode is useful in scenarios where a task takes longer than required say SSH timeout. These tasks can run in background mode and can be checked at a later point of time. We can set ‘poll’ to check the status of a task after ‘n’ number of seconds or we can also set poll to 0 where we fire a task and forget about it. By default, value of poll is 10.
Example of asynchronous Task
[js]
tasks:
– name: asynchronous task example
command: /bin/sleep 20
async: 40
poll: 6
[/js]
MODULES
- Modules are also called as ‘task plugins’ or ‘library plugins’
- Module is what gets executed in each playbook task
- All the modules and options supported by them can be found in ansible documentation
Link:http://docs.ansible.com/ansible/list_of_all_modules.html - We can also get list of all modules from command line.
[js]ansible-doc -l[/js]
- Options available for each module and sample examples can be found using ansible-doc tool.
[js]ansible-doc yum[/js]
where yum is a module name
- Modules are always shipped with ansible whenever it is installed.
- Modules are idempotent in nature. It means they are safe to run again and again. They do not make changes if a desired state is already achieved.
- In the above examples we saw modules such as apt, service, copy, etc. take key value arguments. Most modules except ‘command’ and ‘shell’ do not take key value arguments
- Some modules (such as ping) donot take any arguments at all
For eg:
[js]
– name: Copy properties file to hosts
shell: mv /tmp/sample.properties /usr/share/mars.properties
[/js]
If you want to explore more about playbooks please refer ansible documentation
