Introduction 😇
Ansible is an Open source IT automation engine that automates orchestration, app deployment, provisioning, config management, and numerous other IT activities.
Ansible runs by connecting with your nodes and sending short scripts, known as modules, to these nodes. In Ansible, operations that require automation are carried out via modules. These programs were created as resource models for the ideal system state. After their action, Ansible removes these modules.

In this blog, we will learn the Ansible 2.7 Porting Guide in detail.
Playbook 📖
The first topic of the "Ansible 2.7 Porting Guide" series is Playbook. This will help you to learn how to use a Playbook.
Ansible Playbooks are a method for using scripts to transmit commands to remote systems. By running a script on one or more systems, Ansible playbooks are used to configure complex system environments. It is used to increase flexibility. Playbooks written in Ansible often resemble config languages more than programming languages.
There are some changes in the new version of Ansible 2.7. Let's discuss this in our Ansible 2.7 Porting Guide article.
Role Precedence Fix during Role Loading
Roles make it simpler to split the tasks when working with lengthy playbooks. Also, it makes it easier to reuse the roles later. A role is a group of tasks that may be transferred from one Playbook to another. It is operated freely, but only by using a playbook file.
There is a small change in the updated version, which is Ansible 2.7. The changes say that the role vars and defaults are parsed before tasks/main.yml. Before Ansible 2.7, when loading a role, the vars/main.yml and defaults/main.yml variables were not accessible when parsing the tasks/main.yml file for the role.
include_role and import_role variable exposure
There is an addition in the module named public in the include_role section. It controls whether or not the role's defaults and vars will be made available outside of the role, enabling later actions to utilize those variables.
There is a notable change between how import_role (static) and include_role (dynamic) reveal the role's variables. The variables are available to tasks and roles listed at any point in the play via the import_role pre-processor, which is used to assess defaults and vars at playbook parsing.
Since it is a conditional task, the variables are made available to tasks and roles mentioned after the include_role task, and the defaults and vars are evaluated at execution time.
include_tasks/import_tasks inline variables
The inline variables can no longer be used with include_tasks and import_tasks in the updated Ansible 2.7 version. The vars keyword should be used by tasks to supply variables rather than inline variables.
Let's learn this using an example:
In the earlier versions of Ansible, like 2.6 or below, it follows the syntax shown below:
- include_tasks: include_me.yml variable=value
But now, In the updated version of Ansible (version 2.7), we have to use the vars keyword. Follow the below syntax:
- include_tasks: include_me.yml
vars:
variable: value
vars_prompt
A prompt that defines one or more variables can be made using the vars_prompt function. If the controller does not support the hash algorithm given in encrypt, the vars_prompt now throws an exception. Vars_prompt is now more secure because it no longer returns None when the algorithm is unknown.








