This post was originally published on the
XLAB Steampunk blog.
If you are reading this, you are no stranger to the Ansible update and upgrade process. The fact that Ansible is constantly being improved is great. And while the community is making its best effort to minimize breaking changes, there are times when keeping your Ansible content up to date requires additional work. To make things as clear as possible, let’s tackle this topic step by step.
In this post, we’ll explain:
- Why is it vital to keep Ansible up to date?
- What is the Ansible update and upgrade process?
- What is the difference between an “update” and an “upgrade”?
- What are the implications of performing such an action?
- How can we prevent potential problems?
Why is it vital to keep Ansible up to date?
Maintaining your Ansible environment up-to-date is essential for many reasons, but the main ones are:
- Security: In many cases, Ansible updates include multiple security fixes that will make your deployment more secure and reliable. As Ansible is a crucial part of your infrastructure management practice, a security breach can have severe and harmful implications.
- Functionality: With new versions of Ansible, you can get new features that will help you to maximize your Ansible possibilities.
- Support: You can find supported Ansible versions on their official site and specific information about collections on Red Hat’s site.
What is the difference between an “update” and an “upgrade”?
Like every other software program, there is a difference between an “update” and an “upgrade”:
- An update in the Ansible context is related to a relatively small change, where no significant changes are happening, for instance, if you want to update Ansible from version 2.8.1 to version 2.8.2. In these updates, you should not expect any major impact. Playbooks, collections, and other Ansible artifacts are usually not affected by this update.
- An upgrade usually involves a major change in Ansible, for instance an upgrade from version 2.8 to version 2.9, where Ansible provides a porting guide that lists the changes in the Ansible behaviour.
What is the Ansible update and upgrade process?
The action of performing an update is the same as performing an upgrade, so we must be very careful of what we want if we use Ansible’s recommended way, which is upgrading the ansible Python package with the pip package installer.
python3 -m pip install - -upgrade - -user ansible
However, if we want to specify an ansible package version we can specify which version we want and therefore, if we want to perform an update or an upgrade. Note that Ansible Community Package (called ansible) is not using classic Ansible versioning (e.g., 2.9), but rather new versioning (e.g., 5.0.0), which is specific to the package itself. So, before you select your target Ansible version to update/ upgrade to, use Ansible docs (or run ansible - -version after installing) to verify which Ansible version does a specific ansible Python package include. It’s also important to know that ansible package has a dependency package called ansible-core, which uses classic Ansible versioning.
What are the implications of performing such an action?
As per their Ansible 2.9 Porting Guide there are several things we need to consider (and these things can vary from version to version):
- At the playbook level, there are differences at the inventory level and loops
- There might be some deprecated items
- Changes in the collections
- Changes in the modules (including some modules being removed or renamed)
- Changes in the plugins
- Changes in the networking
And potentially other changes.
This means that we should analyze each of our playbooks to evaluate how these changes impact the execution of our playbooks and if we need to update them to reflect these changes as your playbooks might not work properly. Well, that sounds exhausting!
How can we prevent potential problems?
We live in a day and age where we have all kinds of gadgets taking care of mundane tasks for us. Would it be too much to expect someone has come up with a tool that acts as a scanner that checks your playbooks and helps you understand the impact of updating your Ansible version and tells you how to deal with them?
If you are familiar with Visual Studio Code, you already know that there are tools (including the Ansible Addons) that provide some sort of autopilot, or if you use GitHub you might be familiar with Copilot. But these tools are meant to be used while you are creating a new playbook, which does not solve your problem of the pile of your existing playbooks, waiting for a thorough and not so thrilling investigation of all the things that can go south when updating. Wouldn’t it be great if you had someone do that instead of you? Well, you do now!
Steampunk Spotter, a quality scanner for Ansible Playbooks, checks if your playbooks are compatible with the latest Ansible version, pinpoints issues they might cause, and suggests what to do to prevent downtime and facilitate your migrations across different versions.
The open-source steampunk-spotter CLI enables the use of Ansible Playbook scanner from the console with the ability to scan Ansible task files, playbooks, roles and collections.
