BlogAnsibleInfrastructure AutomationRed HatAutomation & Orchestration
Blog • • 4 minute read

5 Things to Know About Ansible 2.10

The newest version of Ansible introduces some major changes. Here are the things you need to know now before moving to Ansible 2.10.

In this blog

  1. 1. No playbook re-writes necessary
  2. 2. Do not upgrade to Ansible 2.10
  3. 3. Ansible Collections are front and center
  4. 4. Support redirected
  5. 5. Change in order to scale the community

 1. No playbook re-writes necessary

First and most importantly, if your playbook worked on 2.9, it should work in 2.10. Even though Ansible has gone through pretty significant changes, the community has put in a lot of effort into making sure that this upgrade is backward compatible with 2.9. 

With that said, if you were already utilizing Ansible features that were en-route to be deprecated, your playbook may not work. However, you should have been seeing deprecation warnings in your playbook runs if you were running a relatively recent version of Ansible.

 2. Do not upgrade to Ansible 2.10

Don't get the wrong idea. We want you to use Ansible 2.10. However, you can't simply run pip install --upgrade ansible . Doing so will throw an error. Why is that? As of 2.10, when you install Ansible, it will actually install two different packages, Ansible-base and Ansible. Ansible-base is the package that contains all of the binaries and supporting files to be able to execute Ansible. The ansible package now contains the individual collections that made up all of the modules and plugins that were supported in 2.9.

Instead of doing pip install --upgrade ansible, first uninstall Ansible by running pip uninstall ansible and then execute pip install ansible. This assumes that you installed Ansible via pip when you setup your environment. It also assumes your pip is setup to be able to pull packages from the internet vs going through an internal pypi repository.

 3. Ansible Collections are front and center

We have been talking about Ansible Collections for what seems to be years now. Ansible Collections was first introduced in preview form back in Ansible 2.8. Collections were designed to provide a framework for Ansible content creators to build, host and distribute reusable Ansible playbooks, modules and plugins.

I can hear you Ansible developers now. "We have Ansible Roles, what about that?" 

Yes, Ansible Roles is a method to provide reusable sets of tasks and modules. However, Ansible Roles provided only a subset of capabilities that Ansible Collections provide. With a collection, you can now package in playbooks. Instead of instructing the consumer of your role on how to consume your role, you are just telling them how to use the playbook.  

With collections, you can have multiple roles and a playbook(s) with multiple plays that execute against different groups all from within the collection. Now your three-tier application deployment doesn't need to be held together by three different repositories of roles and a fourth to hold your playbook.

 4. Support redirected

Did you run into an issue with that asa_config Ansible Module? Typically, we would point you over to the Ansible repository to open an issue or search for existing issues. However, in Ansible 2.10 all of the modules have been moved into their own Ansible Collection repositories, hosted by Ansible or under a Github organization hosted by the company maintaining the collection.

 5. Change in order to scale the community

So why did the community decide to take Ansible in this new direction? Ansible has always been referenced as a 'batteries included' tool. When you installed Ansible, you would also get all the modules developed for Ansible. This includes modules from Infoblox, NetApp, Pure Storage, AWS, Azure, etc.

The number of individual Ansible modules had exceeded 3,000. While this helped Ansible remain simple to build automation with, it didn't help the contributors to Ansible. As of writing this article, there have been over 270 active contributors in the last month, with 43,000 lines of code changed. There are backend CI/CD tooling to help automate the testing of any code changes. However, at the end of the day, there are contributors that have to validate that the code changes are needed and meet the level of quality that the Ansible community has come to expect.

Moving modules to collections has decoupled the tight integration of Ansible to module versioning. This allows ansible-core developers and Ansible module developers to add features and integrations at the speed they are comfortable with. This was always a constant battle in the development process of Ansible and has been solved with this move to collections.

The F5 Ansible Automation Training Lab has been upgraded to 2.10, and we are working to update all the ATC labs. Login and launch in order to take Ansible 2.10 for a ride.

Technologies