Updated March 28, 2023

Introduction to Ansible Versions

Ansible is a software deployment tool. It also used for software provisioning and configuration management as well. It is an open-source tool. Ansible is known as simple, agentless IT automation tool also. In this topic, we are going to learn about Ansible Versions.

List of Versions

Every Ansible version gets released on every 4-6 month cycle depending upon the changes from version to version. For every new version, it can be tested before its release made available.

All the versions of Ansible are shown below and an explanation of each follows:

Before 1.9
1.9 (1.9.1 to 1.9.6)
2.0 (2.0.1 to 2.0.3)
2.1 (2.1.1 to 2.1.6)
2.2 (2.2.1 to 2.2.4)
2.3 (2.3.1 to 2.3.4)
2.4 (2.4.1 to 2.4.7)
2.5 (2.5.1 to 2.5.15)
2.6 (2.6.1 to 2.6.20)
2.7 (2.7.1 to 2.7.16)
2.8 (2.8.1 to 2.8.8)
2.9 (2.9.1 to 2.9.4)

1. Version before 1.9

It started as a project, come by various bug fixes and manage upgrades from there onwards. I started using inventory and playbooks.
Roles were added in Ansible 1.2 release
Improved conditionals in the form of ‘when’ command with improved variable support.
In 1.4 release around 33 new modules.
The great feature in 1.5 is the ‘implicit localhost’ object, as a result, we are no longer to add localhost to do ‘’hosts:localhost’ or ‘local action’ commands. Instead of these, we can use ‘all’ which refers to all the servers involved.
30+ great new modules added in Ansible 1.6.
In 1.7 and 1.8 it succeeded in fully supported windows along with many improvements.

2. Version 1.9

New modules and filters added. New lookup, callback plugins are also added.
Many new enhancements to the Amazon web service modules and new docker improvements added.
Many bugs were fixed in 1.9.1 version which leads to enhance s3 module, service module, user module and Unicode handling in some module situations.
9.2 comes up with security fixes that check the hostnames match certificates with https urls, time zone, jail and chroot plugins.
Change the yum module to install all packages specified in a single transaction which fixes problems with dependencies between packages specified by filename or URL.

3. Version 2.0

The new block directives allow for making task blocks and exception like semantics.
Error handling improved, with more detailed parser messages.
meta: refresh_inventory has added to force reading the inventory in a playbook. As a result of this, the inventory scripts can be re-executed but do not force them to ignore any cache they might use.
Using ‘su’ as a privilege escalation method some local connections work now.
Some ‘ssh’ is depreciated as follows ‘ansible_ssh_user’ to ansible_user, ‘ansible_ssh_host’ to ‘ansible_host’ and ‘ansible_ssh_port’ to ‘ansible_port’.
In 2.0 newlines now remain as specified in the template file.
Callbacks don’t need to be copied as they shipped in the active directory now.
Many API changes like callback, connection, cache and lookup plugin APIs have changed.
Some new strategy plugins added which allow control over the flow of task execution per play and the default will be the same as before.
Improvements have done in support of additional shell types and in the code which is used to calculate checksums for remote files.

4. Version 2.1

New modules were added to Azure.
‘debug’ is the new strategy that has added to allow per-task debugging of playbooks.
Improved winrm argument validation and feature sniffing along with winrm error handling: basic parsing of stderr from the command-line interface XML stream.
The retry file feature had been re-implemented.
Ansible-console tool, the facility for modules to send back, ability to send per-item, ability to filter facts, etc. were added.
Expanded and refactored support for Docker with new modules.
Many improvements to existing modules, as well as a new Kubernetes module.

5. Version 2.2

New privilege escalation becomes the method ‘ksu’.
Windows ‘async:’ support for long-running tasks.
Roles can now be included in the middle of the task list via the new ‘include_role’
‘meta’ tasks can now use conditionals.
Added support for binary modules and the ability to specify serial batches as a list as a part of major performance improvements.
‘listen’ feature had added for modules, which allows tasks to more easily notify multiple handlers, as well as making it easier for handlers from decoupled roles to be notified.

6. Version 2.3

To complain about invalid arguments ‘include_role’ added.
To work with newer releases of RHEL7, the hostname has been updated.
A major security fix had done to avoid provider password leaking in the logs for the network modules.
For enabling the classification, ‘metadata’ added to modules.
Most windows modules were standardized and or refactored by adding check mode and diff support where possible.
Usage of more modern system polling API instead of select in the ssh connection plugin to remove one limitation on how many parallel forks are feasible on the systems.
Custom modules can be placed in site-specific directories and shipped in roles by allowing ‘module_utils’.
Detection of change in docker image when published ports are changed and can be handled.

7. Version 2.4

Old keywords include/import are replaced by the new keywords.
For better management, the inventory classes have been split.
The command-line interface has been updated for better interaction with the inventory.
For creating inventory some new inventory plugins were added at the same time old inventory formats were being supported by the plugins.
A keyword ‘order’ added which allows the user to change the order when dispatching the tasks.
Some parameters in the ‘fetch’ module were deprecated along with the ‘unsafe_proxy’ module which avoids circular import.
From yaml definitions, the configuration has been changed from a hardcoded listing in the constants module to dynamically loaded.

8. Version 2.5

Many Network improvements have taken place in this version.
To replace ‘connection=local’, the new plugins ‘network_cli’ and ‘netconf’ were created.
A new filter is added to convert the XML response to the JSON object from a network.
To work on standard administrator users without disabling UAC on windows hosts, they improved ‘become’ elevation process.
‘–export’ is now supported by ansible-inventory.
A site administrator can use to specify modules to exclude as a configuration file being added.
‘loop’ added for the use of task loops.

9. Version 2.6

‘encoding’ has been added to the appropriate filters to specify the encoding of the string.
‘AnsibleParserError’ has been fixed which was missing in the previous versions.
‘argv’ option has been added to allow the command to be specified as a list.
VMware supported modules and it’s parameters were changed.
Most importantly some unused or unnecessary features were removed. They are like win_feature, win_package, etc,
‘always_run’ changed to ‘check_mode: no’

10. Version 2.7

‘ignore_unreachable’ is a new keyword added which allows in ignoring tasks that fail due to unreachable hosts.
A new module ‘yumdnf’ has added which defines the shared argument specification for both ‘yum’ and ‘dnf’ modules and they are now at feature parity.
Support for simplejson has been removed.
A new feature of locking a file has been added to gain exclusive access.
Most module changes and security fixes have taken place.

11. Version 2.8

‘- become’ has been changed to a plugin architecture.
One of the best features is added in Ansible is ‘Python interpreter discovery’, which is a first python module runs on the target.
Some command-line arguments were deprecated. They are like –sudo, –sudo-user, etc. and they now can be used as –become, –become-user, etc.
A k8s (kubernetes) module has been added which reduces the parameters which are required for multiples tasks in k8s.

12. Version 2.9

Among the various modules in the Ansible, they fixed the typos.
Supporting features are being added for the docker, zabbix and other IDEs.
Here in this latest version, some additional info about the collection namespace name restrictions.

Conclusion

Development is still under process for further enhancements and add new features to Ansible. It is most widely using continuous deployment tools in recent years. The language used in the Ansible scripting is user-friendly and can be understood easily. The programming language is used for it is ‘yaml’ which has inherited by python. More importantly, Ansible Tower serves as a great add-on to Ansible.

Quiz Result
Total Questions	Correct Answers	Wrong Answers	Percentage