Ansiblefest 2021 Brings Important Updates

A major announcement at Ansiblefest 2021 was the introduction of the Ansible Automation Platform 2. Exchanging a centralized, monolithic architecture to a more scalable and collaborative architecture allows organizations to better maintain their Ansible environments. We had the chance to preview the new platform and have collected some highlights of the changes users will want to know. 

Say goodbye to Ansible Tower

Ansible Tower has been the orchestration platform for the Ansible ecosystem. It allows for GUI-based execution of templates, surveys, workflow orchestration, and API access. The functionality of Tower is now present in the Ansible Automation Controller, which leverages Ansible Execution Environments for playbook runs. This change effectively decouples the control plane from the execution plane.

The journey to this change began with the introduction of collections in Ansible 2.8. This was an effort by Red Hat to separate the Ansible Core code from the different modules that are used by developers and engineers to write their playbooks. What this involved was the automation engineer or operations engineer to install the correct collections on whatever host machine was running the Ansible automation. In addition to other dependencies such as system packages or python libraries, this approach impeded scalability of automation operations. 

With the use of Execution Environments, all those dependencies are packaged into a container. This container can be shipped to other systems, or ideally, shared via Private Automation Hub (another component of AAP2). From there multiple instances of the Automation Controller or Ansible Host can utilize the same packaged Execution Environment, ensuring playbooks can be executed safely and reliably on disparate systems. This also eliminates the need to manage Python virtual environments on the execution hosts.

These changes to how playbooks are executed do not affect how playbooks are written. Existing playbooks that an organization uses today do not need to be refactored to work in this updated version of Ansible.

How do I build these execution environments?

Luckily there is a tool to enable engineers to easily build these execution environments; the aptly named Ansible Builder. Ansible Builder takes dependencies and packages them into a container that can be used by Ansible. This tool uses Podman to build the container. Ansible builder can be installed via pip or downloaded and installed from source code. 

A definition file, named execution-environment.yml, contains all the information to build the container. This definition file can reference other files automation engineers may be used to such as: 

• bindep.txt for system requirements
• ansible.cfg for Ansible customization
• requirements.yml for collections and roles
• requirements.txt for any python packages to be installed.

version: 1

ansible_config: 'ansible.cfg'

dependencies:
  galaxy: requirements.yml
  python: requirements.txt

To build an image issue the command ansible-builder build. Once Ansible-Builder completes the build, it is available locally on the build machine, or can be pushed via podman to the Private Automation Hub to share with other systems and engineers.

How do I use these execution environments?

In the new Ansible Automation Controller, when you create your template, there is an entry to choose your Execution Environment. The Automation Controller can be setup to communicate with the Private Automation Hub to pull images.

Tower is not the only tool getting an overhaul. We've always used the ansible-playbook command to run our playbooks in the past. With the introduction of Ansible Navigator, we can utilize execution environments from the command line as well as have a visual navigation to interact with our playbooks. Ansible Navigator can also be downloaded via pip. 

Create a definition file named ansible-navigator.yml at the base of our project. This file tells ansible navigator any extra parameters it needs to know including which execution environment to instantiate for our playbook run.

---
ansible-navigator:
  ansible:
    inventories:
    - inventory.yml

  execution-environment:
    enabled: true
    container-engine: podman
    image: example-ee:latest
    pull-policy: missing

When we run our playbook using ansible-navigator run example-playbook.ymlwe get a different output than we might be used to.

We can explore the results of our automation playbook by navigating the menus of ansible navigator. Eventually drilling down into the results of each task.

Look for updated labs on our digital platform that will take advantage of Ansible Automation Platform 2.0. Keep in mind that these changes are an evolution of the platform and that the automation you've already developed does not need a drastic refactoring. The Ansible Tower you are used to logging into will become Ansible Automation Controller. The dependencies and packages that you were used to installing on the execution hosts, can now be bundled into portable execution environments.

Be sure to check out our session from Ansiblefest 2021 on Comprehensive Network Testing with Molecule and CML.