About Ansible & Ansible Playbooks

Why Ansible:

The major difference between other Configuration Management tools and Anisble, is that underneath Ansible is just SSH. Chef and Puppet both have dependencies that must be installed on the server before you can use them, Ansible does not. It runs on your machine and uses SSH to connect to the servers and run the required commands.

Why not just use Bash scripts, then? Ansible has an edge over Bash scripts because of its simplicity. Ansible just uses a list of tasks to run in YAML2 format. Ansible also comes with idempotency out of the box. That means you can run the same operation numerous times, and the output will remain consistent (i.e. It won't do anything twice unless you ask it to). You can write Bash scripts this way, but it requires quite a bit more overhead.

Ref: 
www.ansible.com

Ansible Playbooks: 

Playbooks to Ansible are what manifests to Puppet , yes , Ansible playbooks contains the policies and configurations you want on your managed system , in a step wise manner , just like the manifests.The modules which we use while running adhoc commands in Ansible can be used with the playbooks. Ansible Playbooks are probably the largest part of Ansible learning so we will go slow and divide it into several articles.In this article we will see why use playbooks,how are they written,what language do they use and then we will write a couple of basic playbooks ourself.

Playbooks are a powerful way of using Ansible , they can not only declare configurations but also orchestrate steps of any manual deployment.There are several websites and github projects which provide sample playbooks so I recommend you to kindly go through them and in case you need my help , just leave a comment below.

Playbook Language : Playbooks are written in Yaml , which provides a human readable form in a way that it has some really simple syntax and it describes the whole process in a step-by-step form.The playbooks link a group of hosts to certain tasks which needs to be performed on them with the help of modules.Each playbook can have multiple plays or what you call tasks which can help you in streamlining several processes like suppose you can install apache , configure the configuration file and then restart the service , all in a single playbook.Let’s write a small playbook which installs Apache and starts its service.

—
– hosts : webserver
  remote_user : apache
  tasks:
        – name : install apache
          yum : pkg=httpd state=latest
        – name : start apache service
          service: name=httpd state=started

Now let’s breakdown the above playbook and see different parts of it.
Hosts : Here hosts lets you choose on which machine you want to run your playbook , like for instance here we have defined a host named ‘webserver’ , so ansible will look into the inventory file and if it finds the host entry for webserver , it will execute this playbook on that machine.
User : By default ansible connects to the remote machine as the same user logged in on the ansible server , to override this behaviour , we have defined a user which forces ansible to SSH on the remote machine with the user defined in the playbook.
Tasks : Each playbook has a list of tasks which it needs to be performed on each host defined in the playbook.The goal of each task is to run or re run the modules with specific arguments.Modules in ansible are idempotent , which means that even if you re run a playbook several times , the modules will only make changes if they find a deviation in the configuration otherwise they will not make any change.Modules like “command” and “shell” will only re run the commands which is totally fine , unless the commands are not making any major changes , although we do have a flag to counter this behaviour of these modules.Each task is given a name which is displayed when the playbook is executed , so that one knows what is going on at the back end.

To execute a playbook we use a different command that /usr/bin/ansible
# ansible-playbook playbookname.yml
Where playbookname.yml can be any name which you give to your playbook and yml is the file extension for Yaml files.Also remember that Yaml files begin with three hyphens(—) at the top.