Ansible 2.9, or maybe just this time in history, was a great time for simple configuration management that (mostly) just worked. Even when using Ansible across hundreds of different Managed nodes, it was relatively simple to setup.
Side note: I still use Ansible today, including the first Role I ever created to Manage Users with Ansible.
Fast forward to today, and as a user of Ansible it’s just annoying. Take a minute to think about the ansible-core Version Support Matrix.
And then you need to think about:
- Certain Ansible versions only work on certain Control nodes, because they need to use a certain version of Python.
- Certain Ansible versions only work on certain Managed nodes, because they need to use a certain version of Python.
- Make sure you have the specific version of Python on your Control node to work with the version of Ansible you need. Is that version of Python available on your OS?
- Install and update all the Ansible Collections you need. Which ones?
- Install the dependencies for all your Ansible Collections using Python pip (or whatever you use), because those are separate! Which ones?
- If you are upgrading from an old version of Ansible: fix all your Ansible Playbooks and Ansible Roles to work with the new version of Ansible.
What happened to Ansible?
If you want to manage a Red Hat Enterprise Linux (RHEL) 8 host? Good luck with that, you are basically stuck on Ansible 2.16. At least it appears Ansible 2.16 will stick around for a long time (Until the end of RHEL 8 lifecycle). Ansible 2.16 is the new Ansible 2.9 I guess.. At least until RHEL 11 comes out which will probably use an unsupported version of Python.
I’ve continued using Ansible 2.9 for as long as possible but it is inevitable. Newer hosts will use newer versions of Python, so the upgrade from Ansible 2.9 must begin because Ansible 2.9 doesn’t work with Managed hosts using newer versions of Python. RHEL 10 will be using Python 3.12. So now it is time to start moving to a new version of Ansible.
Ansible 2.16 to the rescue
The only option at this point (for me) is Ansible 2.16. You *just* need to install it, do all the other install requirements, upgrade all your playbooks & roles, etc. Easier said than done, but let’s go. Clean up some technical debt this holiday season!
Cheat sheet to setup Ansible 2.16 on a RHEL 9 Control node
On a RHEL 9 Control node, you need to install a newer version of Python. Then proceed to install all the rest of Ansible’s requirements.
For example:
# On Control node as Ansible user (not root):
sudo dnf install python3.11 python3.11-pip
ln -s /usr/bin/python3.11 ~/.local/bin/python
python3.11 -m pip install -U --user ansible-core<2.17 ansible-lint netaddr jmespath jc
ansible-galaxy collection install ansible.posix
ansible-galaxy collection install ansible.netcommon
ansible-galaxy collection install community.general
ansible-galaxy collection list
You will now be using Ansible 2.16 on a RHEL 9 Control node which should work across all “modern” Linux hosts, even RHEL 7 (which is not modern, but Python 2.7 still works in Ansible 2.16).
Next up, change every single Ansible Playbook and Role and hope for the best. These Porting Guides do not look fun!! Don’t forget to Ansible Lint & syntax check everything.
ansible-lint *.yml
ansible-playbook --syntax-check *.yml
Conclusion – RIP Ansible 2.9
RIP Ansible 2.9
Long live Ansible 2.16