Introduction
Ansible is a straightforward open-source IT engine that automates the deployment of applications, intra-service orchestration, cloud rendering, and numerous other IT technologies.
It is designed in a particular way such that it helps you update your playbooks, plugins, and other Ansible infrastructure components so that they are compatible with this version of Ansible.
In this article, we will learn the introduction to Ansible 2.3 porting guide, playbooks, modules, plugins, porting custom scripts, networking, and their types.

Playbook

⭐Restructured async to work with action plugins

We cannot use the async keyword with action plugins like the service in Ansible 2.2 (and possibly before). In Ansible 2.3, this restriction has been removed.
New in Ansible 2.3
- name: Installing Nginx asynchronously
service:
name: nginx
state: restarted
async: 45
⭐OpenBSD version facts

On OpenBSD systems, Ansible 2.2 and earlier reversed the ansible distribution release and ansible distribution version facts. facts has updated so that the version now contains the version number and the release now contains the name.
Old in Ansible 2.2 version
"ansible_distributions": "OpenBSD"
"ansible_distributions_release": "6.0",
"ansible_distributions_version": "release",
NEW in Ansible 2.3 version
"ansible_distributions": "OpenBSD",
"ansible_distributions_release": "release",
"ansible_distributions_version": "6.0",
⭐Names Blocks

Now we can give the names to that blocks, you can avoid the offensive # this block is for comments.
NEW in Ansible 2.3
- name: Block test cases
hosts: localhost
tasks:
- name: Attempt to setup foo
block:
- debug: msg='Ansible 2.3 porting guide
- commands: /bin/false
- debug: msg='I never execute, cause ERROR!'
rescue:
- debug: msg='I caught an error
- command: /bin/false
- debug: msg='I also never execute :-('
always:
- debug: msg="this always executes, Ansible 2.3 porting guide"
⭐Use of Multiple tags

Currently, if —tags (or —skip-tags) are supplied more than once on the command line, the last specified tag takes precedence over all other specified tags. This behavior is out of date. If you specify tags more than once in the future, they will be combined. Using —tags more than once on a single command line will produce a deprecation notice. The new behavior can be activated by setting the ansible.cfg file's merging multiple cli tags option to True.
The default setting for 2.4 will be to merge the tags. The config option allows you to activate the previous overwriting behavior. There is no way to revert to the previous behavior when using multiple —tags options in version 2.5.
⭐Other Caveats
Here are a few unusual situations that could arise when updating. The capture of previously overlooked mistakes and stricter parser validation are primarily to blame for this.
made all objects from play to task, as well as those in between, inheritable for any errors fatal.
Modules
This version has minimal changes.

📑Modules removed
This version has minimal changes.
📑Deprecation Notices
Ansible 2.5 will eliminate the below-mentioned modules. Please revise your playbooks as necessary.
🔻ec2_vpc
🔻cl_bond
🔻cl_bridge
🔻cl_img install
🔻cl_interface
🔻cl_interface policy
🔻cl_license
🔻cl_ports
🔻instead of nxos_mtu, use nxos_system
📑Noteworthy Module Changes

🧾AWS Lambda
Changes that simply changed one parameter previously went unnoticed. This problem remedy may require additional changes for current deployments.
🧾Mount
Bind mounts won't be mounted every time the playbook is executed thanks to certain changes.
Plugins
This version has minimal changes.
Porting Custom Scripts
This version has minimal changes.
Networking
The way that Networking Modules function has undergone several changes.
Playlists must continue to utilize connection: local.
The modifications below relate to:
✴️dellos6
✴️dellos9
✴️dellos10
✴️eos
✴️ios
✴️iosxr
✴️junos
✴️sros
✴️vyos
Types of Networking

🔺Deprecation of top-level connection arguments
OLD in Ansible 2.2
- name: example to use top-level options for connection properties
ios_command:
commands: show version
host: "{{ inventory_hostname }}"
username: Ansible 2.3 porting guide
password: Ansible 2.3 porting guide
authorize: yes
auth_pass: cisco
Results in
[WARNING]: argument username has been deprecated and should be removed in a future version
[WARNING]: argument host has been deprecated and should be removed in a future version
[WARNING]: argument password has been deprecated and should be removed in a future version
NEW in Ansible 2.3
- name: Gather facts
eos_facts:
gather_subset: all
provider:
username: Ansible 2.3 porting guide
password: "{{ Ansible 2.3 porting guide}}"
transport: cli
host: "{{ ansible_host }}"
🔺Delegate_to vs proxy command
The delegate to the directive is no longer supported by Ansible 2.3's new connection framework for Network Modules that leverages cli transport. Network modules now enable the usage of ProxyCommand to connect to network devices using cli transport using a bastion or intermediate leap host.
Configure the proxy options in the Ansible inventory file to indicate the proxy host using ansible ssh common args when using ProxyCommand.
Frequently Asked Questions
Do you know Ansible is a CI tool?
Yes, it is a CI/CD process that can leverage Ansible, a potent tool for IT automation, to configure the target environment before deploying the application on it.
What distinguishes Ansible from Jenkins?
Ansible is an effective tool for automating the creation of the target environment and subsequent application deployment. Jenkins, a well-known IT automation tool, is used for Continuous Integration/Continuous Delivery (CI/CD) to provision the target environment.
How does Ansible architecture work?
Cloud provisioning, configuration management, application deployment, intra-service orchestration, and many more IT requirements can all be automated with Ansible, a radically simple IT automation engine.





