You might have already heard about Ansible-Playbook, Let’s take a brief look in ‘What is Ansible Playbook?’ and ‘How it works?’.

An Ansible playbook is an equipped unit of scripts that defines work for a server configuration managed via the automation tool Ansible. Ansible is a configuration management tool that automates the configuration of more than one servers via the use of Ansible playbooks. Playbooks are the archives where Ansible code is written. Playbooks are written in YAML format. Playbooks are one of the core points of Ansible and inform Ansible what to execute. They are like a to-do list for Ansible that consists of a list of tasks.

Playbooks are a very unique way to apply ansible than in ad-hoc task execution mode, and are specially powerful. Simply put, playbooks are the basis for a really simple configuration management and multi-machine deployment system, unlike any that already exist, and one that is thoroughly desirable to deploying complicated applications.

Playbooks can declare configurations, but they can also orchestrate steps of any manual ordered process, even as specific steps must bounce back and forth among sets of machines in particular orders. They can execute tasks synchronous or asynchronous manner. While you may run the main /usr/bin/ansible program for ad-hoc tasks, playbooks are more likely to be kept in source control and used to push out your configuration or to ensure that the remote systems configurations are in specification.

Playbook Language

Playbooks are expressed in YAML structure and have a minimum of syntax, which deliberately tries to not be a programming language or script, but alternatively a mannequin of a configuration or a process.

Each playbook is composed of one or extra ‘plays’ in a list. The goal of a play is to map a team of hosts to some nicely described roles, represented through matters ansible calls tasks. At a simple level, a undertaking is nothing greater than a name to an ansible module.

By composing a playbook of multiple ‘plays’, it is possible to orchestrate multi-machine deployments, jogging sure steps on all machines in the webservers group, then positive steps on the database server group, then extra instructions returned on the webservers group, etc.

“plays” are extra or much less a sports activities analogy. You can have pretty a lot of plays that have an effect on your structures to do extraordinary things. It’s now not as if you had been simply defining one precise nation or model, and you can run exceptional plays at one of a kind times.

here’s one playbook, “apache.yml” that contains just one play:

--- - hosts: webservers
   vars:     
http_port: 80     
max_clients: 200   
remote_user: root   
tasks:   
- name: ensure apache is at the latest version     
yum:       
name: httpd       
state: latest   
- name: write the apache config file     
template:       
src: /srv/httpd.j2       
dest: /etc/httpd.conf     
notify:     
- restart apache   
- name: ensure apache is running     
service:       
name: httpd       
state: started   
handlers:     
- name: restart apache       
service:         
name: httpd         
state: restarted

Playbooks can contain multiple plays. Check the below example playbook “webservers.yml” that targets first the web servers, and then the database servers:

---                                                                    - -  hosts: webservers   
remote_user: root   
tasks:   
- name: ensure apache is at the latest version     
yum:       
name: httpd       
state: latest   
- name: write the apache config file     
template:       
src: /srv/httpd.j2       
dest: /etc/httpd.conf 
- hosts: databases   
remote_user: root   
tasks:   
- name: ensure postgresql is at the latest version     
yum:       
name: postgresql       
state: latest   
- name: ensure that postgresql is started     
service:       
name: postgresql       
state: started

If you are a begginer to YAML, the syntax can be tricky at first, particularly with spacing (no tabs). Using vim with syntax highlighting is useful not solely in learning yaml, however to find syntax issues. A fast way to enable vim for yaml syntax is by adding the below line to your ~/.vimrc file:

$ vi ~/.vimrc

autocmd Filetype yaml setlocal tabstop=2 ai colorcolumn=1,3,5,7,9,80

If you’d like something with a few more features, including color, one such plugin can be found here.

Before running a playbook, you can check the syntax using:

$ ansible-playbook –syntax-check playbook.yml

You can test a playbook without actually making any changes to the target hosts:

$ ansible-playbook –check playbook.yml

Stepping through a playbook may also be useful:

$ ansible-playbook –step playbook.yml

Executing A Playbook

Now let’s look on ‘how do you run a playbook?’ It’s simple. Let’s run a playbook ‘playbook.yml’

$ ansible-playbook playbook.yml 

Advanced Playbooks Features

Here are some playbook features that not everyone may need to learn, but can be quite beneficial for specific applications.

• Understanding Privilege Escalation
• Asynchronous Actions and Polling
• Check Mode (“Dry Run”)
• Playbook Debugger
• Delegation, Rolling Updates, and Local Actions
• Setting the Environment (and Working With Proxies)
• Working With Language-Specific Version Managers
• Error Handling In Playbooks
• Advanced Syntax
• Working With Plugins
• Prompts
• Tags
• Using Vault in playbooks
• Start and Step
• Playbook Keywords
• Lookups