Chapter 2: Migrating from Earlier Ansible Versions

As Ansible has grown over the years, certain headaches have presented themselves to the team that develops and manages the Ansible code base. In many ways, these headaches have been the price of Ansible's own growth and success, and have resulted in a need to structure the code a little differently. Indeed, anyone with a little prior experience of Ansible from versions before 2.10 will have noticed that our example code presented in this book looks a little different, along with a new term, Collections.

In this chapter, we will explain these changes in detail, along with how they came about. We will then take you through some practical examples so you can see how these changes work in the real world, before finally teaching you how to migrate any existing or legacy playbooks you might have to Ansible 4.3 and beyond.

Specifically, in this chapter, we will cover the following topics:

• Changes in Ansible 4.3
• Upgrading...

Technical requirements

To follow the examples presented in this chapter, you will need a Linux machine running Ansible 4.3 or newer. Almost any flavor of Linux should do. For those interested in specifics, all the code presented in this chapter was tested on Ubuntu Server 20.04 LTS unless stated otherwise, and on Ansible 4.3. The example code that accompanies this chapter can be downloaded from GitHub at this URL: https://github.com/PacktPublishing/Mastering-Ansible-Fourth-Edition/tree/main/Chapter02. We will make use of a module that we develop in Chapter 10, Extending Ansible, to show you how to build your own collection, so it is worthwhile making sure you have a copy of the accompanying code for this book.

Check out the following video to view the Code in Action: https://bit.ly/3DYi0Co

Changes in Ansible 4.3

While we touched on this topic in Chapter 1, The System Architecture and Design of Ansible, it is important that we look in greater depth at these changes to help you fully understand how Ansible 4.3 differs from prior releases. This will help you greatly in writing good playbooks and maintaining and upgrading your Ansible infrastructure – it is an essential step to mastery of Ansible 4.3!

First off, a little history. As we discussed in the preceding chapter, Ansible possesses a number of strengths in its design that have led to its rapid growth and uptake. Many of these strengths, such as its agentless design and easy-to-read YAML code, remain the same. Indeed, if you read the change logs for Ansible releases since 2.9, you will observe that there have been few changes of note to the core Ansible functionality since that release—rather, all the development effort has gone into another area.

Ansible's modules were undoubtedly one of its...

Upgrading from earlier Ansible installations

The splitting of Ansible into two packages, one of which is dependent on the other, has created some headaches for package maintainers. Whereas packages were readily available for CentOS and RHEL, there are no current packages of Ansible 4.3.0 or ansible-core 2.11.1. A quick look inside the EPEL packages directory for CentOS/RHEL 8 shows that the latest RPM available for Ansible is version 2.9.18. The official Ansible installation guide goes further:

Since Ansible 2.10 for RHEL is not available at this time, continue to use Ansible 2.9.

This will change in due course as package maintainers work out the pros and cons of the various upgrade paths and packaging technologies, but at the time of writing, there is a very clear expectation on your upgrade path if you want to get started with Ansible 4.3.0 now, and the easiest way to get your hands on this latest and greatest release is to install it using the Python packaging technology,...

Installing Ansible from scratch

As discussed in the preceding section, Ansible 4.3 is largely packaged and distributed using a Python package manager called pip. This is likely to change in due course, but at the time of writing, the key installation method you will need to use is to install via pip. Now, it's fair to say that most modern Linux distributions already come with Python and pip pre-installed. If for any reason you get stuck and need to install it, the process is well documented on the official website here: https://pip.pypa.io/en/stable/installing/.

Once you have pip installed, the process of installing Ansible is as simple as running this command, and the beauty is, the command is the same on all operating systems (though note that on some operating systems, your pip command might be called pip3 to differentiate between the Python 2.7 and Python 3 releases that may coexist):

sudo pip install ansible

There are, of course, a few variations on this command...

What are Ansible Collections?

Ansible Collections represent a major departure from the traditional monolithic approach to Ansible releases, where over 3,600 modules were being released along with the Ansible executables at one point. This, as you can imagine, was making Ansible releases unmanageable, and also meant that end users had to wait for an entirely new release of Ansible to receive a feature update or bug fix to a single module—obviously a very inefficient approach.

Thus, Ansible Collections were born, and their premise is quite simple: they are a mechanism for building, distributing, and consuming multiple different types of Ansible content. When you first migrate from Ansible 2.9 or earlier, your experience with Ansible Collections will come in the form of modules. As we discussed earlier in this chapter, what we call Ansible 4.3 is actually a package comprising around 85 collections…it does not contain the Ansible executables at all! Each of these collections...

Installing additional modules with ansible-galaxy

Most of the time when you work with collections, you won't be building them yourself. There are already 780 available on Ansible Galaxy at the time of writing and, there will probably be many more by the time you read this book. Nonetheless, it is the author's personal belief that we all learn better when we can get our hands dirty, and thus, developing our own, albeit simple, collection was a great way for us to look at how they are put together and how they are referenced.

However, let's focus now on finding and then working with pre-existing collections on Ansible, as this is where your focus is likely to be most of the time. As we have already mentioned, the Ansible 4.3 package includes a set of collections for you to begin your automation journey with, along with the ansible.builtin collection included with the ansible-core package.

If you want to see which collections got installed when you installed Ansible...

How to port legacy playbooks to Ansible 4.3 (a primer)

No two Ansible playbooks (or roles or templates for that matter) are alike, and they vary in complexity from the simple to the intricate and complex. However, they are all important to their authors and users, and with all the major changes that were made in the transition from Ansible 2.9 through to 4.0, this book would not be complete without a primer on how to port your code to the newer Ansible versions.

Before we get too deep into this subject, let's look at an example. In the first ever edition of this book, written in 2015 about Ansible version 1.9, an example appeared that renders a Jinja2 template using a small Ansible playbook. We will still learn about an updated version of this code in Chapter 6, Unlocking the Power of Jinja2 Templates, of this book, but for now let's look at the original code. The template, called demo.j2, looks like this:

setting = {{ setting }} 
{% if feature.enabled %} 
feature ...

Summary

Since the last release of this book, there have been many changes to Ansible, but the most notable (which is expected to impact everyone reading this book) is the introduction of collections to manage modules, roles, plugins, and more, and decoupling them from the core release of Ansible. Probably the most noticeable change to Ansible code is in the introduction of FQCNs and the need to install collections if they are not part of the Ansible 4.3 package.

In this chapter, you learned about the reasons for the introduction of collections in Ansible, and how they impact everything from your playbook code to the way you install, maintain, and upgrade Ansible itself. You learned that collections are easy to build from scratch, and even how to build your own, before looking at ways to install and manage collections for your playbook. Finally, you learned the fundamentals of porting your Ansible code from earlier releases.

In the next chapter, you will learn how to secure secret...

Questions

1. Collections can contain:

   a) Roles

   b) Modules

   c) Plugins

   d) All of the above

2. Collections mean that Ansible Module versioning is independent of the version of the Ansible engine.

   a) True

   b) False

3. The Ansible 4.3 package:

   a) includes the Ansible automation engine.

   b) has a dependency on the Ansible automation engine.

   c) bears no relation to the Ansible automation engine.

4. It is possible to upgrade directly from Ansible 2.9 to Ansible 4.3.

   a) True

   b) False

5. In Ansible 4.3, module names are guaranteed to be unique between different namespaces.

   a) True

   b) False

6. To ensure that you always access the correct module you intend, you should start using which of the following now in your tasks?

   a) Fully Qualified Domain Names

   b) Short form module names

   c) Fully Qualified Collection Names

   d) None of the above

7. Which file can be used to list all the required Collections from Ansible Galaxy, ensuring they can easily be installed when needed?

   a) site.yml

   b) ansible.cfg

   c) collections...