Ansible Playbooks vs Roles: Part I - The Playbook - Knoldus Blogs

I assume you know with basics of Ansible and familiar with the terminologies of Ansible. If not, you can visit our previous starter blog.  In this blog, we will take a look on how we can quickly start writing Ansible playbooks with a simple example and in the later or next part of the blog, we will look at how they can be reused to write Ansible roles.

What is a Playbook?

A playbook in Ansible is script files to organize all the tasks which we want to perform along with all the ingredients which are required to put the application in the execution state.  The ingredients I am talking about are Application configurations, all the machines or application hosts (called Inventory in Ansible language) which are going to be used to execute the application.  We will explore more through an example. Using the below playbook, we will deploy an Application written in Scala using sbt.

YAML: The Playbook Language

The playbooks are written using a human-readable language called YAML. As you can see in the example above the playbook which pretty much seems like a config file but has many powers. As you can see this playbook contains currently three components. 1. hosts, 2. vars,  and 3. tasks. Let us explore the meaning of each component written in the playbook.

hosts:This component tells the Ansible which machine you will use to run the tasks written in the playbook. The current playbook is fairly simple and it contains the only localhost. For production applications where a multi-machine deployment is required, a playbook can orchestrate tasks on a group of hosts specified in the playbook. For e.g. you can specify a group slave hosts and a master node for Spark or Hadoop cluster.

vars: All variables and configurations are defined using vars. It is simply a variable which is fixed with some values. e.g. message: “Hello Ansible World” is a variable containing text type value.

tasks: Each task in a playbook is a call to an Ansible module to execute a certain task which is utility function. This playbook contains only three tasks which are self-explanatory by their names. It is always a good practice to define each task in Ansible with a good description which will appear in output while running a playbook. For e.g. the template module will generate a configuration file appliction.conf using a predefined template source called template.conf.

Ansible uses jinja2 templating which provide rich language features for specifying the config files using dynamic expressions. Here the template is using a jinja2 expression: msg = {{message}} to define a message text. The quoted expression “{{}}” is used to enclose a dynamic variable. In the above playbook, the variable “message” assigned a value “Hello Ansible World” which is eventually used by Ansible at runtime. The above file shown in the image is an output after running the playbook.

How to Run the example:

I assume you’ve ansible installed on the machine. You can install it from here if not done already. To run the playbook hit: ansible-playbook playbookname.yml. For e.g.

What Next?

The playbook written here is fairly simple and basic which is introductory. Often production applications sometimes use complicated playbooks which contains a ton of tasks and variables and config file. In the next blog, We will extend our current example and talk about creating re-usable playbooks and Ansible Roles. 

Example Source: sbt-ansible-deploy

Hope you enjoyed reading!! Thanks!!