My previous blog talks about overview of ansible, installation steps and a small demo on basic functionality of ansible.
This blog will help you understand the basics of playbook and its terminologies.
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.
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
[ubuntu] 22.214.171.124 126.96.36.199 [centos] 188.8.131.52
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
- 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
where ‘demo.yml’ is playbook name
Dry Run mode
ansible-playbook demo.yml --check
This mode does not make any changes to remote machines. This only shows what changes would have been made.
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)
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/
name – We can give any descriptive name to a task
apt,copy – modules in ansible
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
tasks: - name: asynchronous task example command: /bin/sleep 20 async: 40 poll: 6
- 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
- We can also get list of all modules from command line.
- Options available for each module and sample examples can be found using ansible-doc tool.
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
- name: Copy properties file to hosts shell: mv /tmp/sample.properties /usr/share/mars.properties
If you want to explore more about playbooks please refer ansible documentation