Current and future vision of Ansible

Ansible is in the top 10 of the largest and most popular open-source projects on Github¹. To understand the vision that makes Ansible so successful, we take a look into the end-user mental model as well as the people and companies involved through a stakeholders analysis. Next to that, we unravel Ansible’s following plans with the future roadmap.

Project goals

Before Ansible, system administrators were likely to use a number of ad-hoc scripts to accomplish simple tasks. They were probably run directly on the target machine, with different administrators achieving the same task in different ways. The system administrators can create high quality scripts that can be run repeatedly on machines with varying initial states. As a consequence, mistakes are easily made and a lot of time is wasted.

Enter Ansible.

Ansible aims to provide an easy to use automation tool that can perform any number of common tasks without compromising the security of the machine it runs on. Instead of writing complicated scripts, the user simply specifies the desired state of the target machine, and Ansible takes care of the rest.

Better yet, because of the community behind Ansible, many tasks a system administrator might need to perform on their machines have probably already been specified by others and shared on Ansible Galaxy.

End user mental model

Ansible’s end users are primarily system administrators. They expect that Ansible can be used to easily perform a wide variety of tasks on (remote) servers. They can use it to deploy a new version of some software package on a number of servers, update some firewall settings or gather various log files. An example use case of Ansible could be to start a webserver. The server host is retrieved from the inventory, followed by some tasks. For example for an Apache webserver, the tasks could be²:

tasks:
- name: ensure apache is at the latest version
  yum:
    name: httpd
    state: latest
- name: write the apache config file
  template:
    src: /srv/httpd.j2
    dest: /etc/httpd.conf
  notify:
  - restart apache
- name: ensure apache is running
  service:
    name: httpd
    state: started

The system administrators need the system to just work on servers configured in any number of ways. Some of which might not contain any services or tooling, could be hidden behind (layers off) firewalls or may not be online at any given time.

When run, Ansible is expected to connect to a (set of) machine(s), upload the tasks it needs to accomplish, run the tasks, clean up after itself, and leave the system in the desired state. Regardless of the initial state of the machine or how often the task is run, the end result should always be that the desired state is achieved.

Simple. Powerful. Agentless.

Ansible aims to be a simple but powerful tool. Every member of an IT team should be able to use it because of the human-readable language used in writing automation tasks. Despite its simplicity, Ansible is a powerful tool as mostly any automation task that is needed for a software system can be run within an Ansible playbook.

Ansible has an agentless architecture, which means that instead of having to install software on all the remote machines, Ansible can directly access the machines and execute tasks using the built-in services of those machines. For example, for Linux and Unix machines SSH is used to connect to the machine, while for Windows hosts Windows Remote Management is used³.

Ansible provides the following capabilities⁴:

• Provisioning; setting up the environment and resources
• Configuration management; managing configuration files
• Application deployment; deploying the application with human-readable playbooks
• Continuous delivery; creating a CI/CD pipeline
• Security automation; using modules, roles and playbooks to automate security in the system
• Orchestration; combining all different configurations and automation tasks into one (orchestrated) whole

Stakeholders Analysis

To know which actors will influence the decision-making process, a stakeholders analysis is required. A stakeholder in software architecture can be a person, group, or entity that has interest in or concerns about the realization of the architecture⁵. The categorization proposed by Rozanski and Woods is used to elaborate on the different stakeholders for Ansible. Note that we added testers to the developer section since every new piece of code needs to be tested and documented and must be backwards compatible. After we have identified the main stakeholders we prioritize them through a Power/Interest Grid.

Stakeholder classes

Acquirers
Rozanski and Woods describe “acquirers” as the group that oversees the procurement of the system⁵. Typically, they include sponsors and senior management. Ansible was founded by Ziouani and DeHaan. In 2015 they sold the company (including its 50 employees) to Red Hat Inc⁶. Therefore, we conclude that their senior management is the same as that of Red Hat Inc.

Assessors
Ansible has a Contributor License Agreement where it states that with any sort of contribution (documentation or code) the contributor grants a full, complete, irrevocable copyright license to all users and developers of the project, present and future, pursuant to the license of the project⁷. Every PR still needs to be assessed. Ansible gives assessors a lot of power and responsibility. In most of the times, the assessors are the module leaders and maintainers.

Communicators
Communicators explain the system to other stakeholders⁵. There are several mailing lists, Internet Relay Chat (IRC) channels and working groups⁸. Each working group has one or more leaders that developers need to contact first. Moreover, Ansible has release managers who need to coordinate between developers, contributors, the community, Ansible documentation team and Ansible Tower team⁹.

Developers
With almost 5000 contributors, Ansible is one of the largest open source projects¹⁰. In order to manage such a large project smoothly, they created many different roles and groups. However, on their website they have a list of 39 individuals who have generally been contributing in significant ways to the Ansible community for some time¹¹. The top 10 contributors in terms of commits can be found here. Most of these contributors are also the leaders of a module.

Maintainers
Maintainers manage the evolution of the system once it is operational⁵. For Ansible it holds that the person that contributes a new module to the ansible/ansible repository is the maintainer of that for that module once it is merged¹². Maintainers have the authority to accept, reject, or revise pull requests on their module. A full list of maintainers can be found in BOTMETA.yml¹³.

Suppliers
According to Rozanski and Woods, suppliers build and/or supply the hardware, software, or infrastructure on which the system will run, or possibly they provide specialized staff for system development or operation. Ansible is almost 100% written in Python. Only a very small percentage of code is written in C# and JavaScript. Although Python is free software, one could see Python Software Foundation as an important supplier.

Support Staff
Ansible offers support through communication channels (Github and Freenode). Since the project is very large, most of the support team are specialized in their own field. Next to the fact that Ansible has a lot of documentation they also offer developers and clients to get in touch with them via Support Cases, Live Chats, Call or Email¹⁴. Finally, they offer support through social media via Twitter, YouTube or Facebook.

System Administrators
Rozanski and Woods describe system administrators as the people who run the system once it has been deployed⁵. Note that this group of people can be omitted since Ansible is an open source product and therefore has no system administrators.

Users
Ansible has a lot of users. They include Jupyter Networks, Apple, NASA, and many more. Most of the users are companies who have a complex IT set up and need Ansible for their configuration management and application deployment.

Competitors
One important stakeholder class we added to this section is Competitors. Ansible’s competitors include Octopus Deploy, Chef, Rudder, SaltStack, and many more small players.

Power/Interest Grid

Context

After the stakeholder analysis, we can create an overview of the context of Ansible that describes “the relationships, dependencies, and interactions between the system and its environment” ⁵. The best way to give this overview is to visualize it.

In the context view we can see a couple of boxes, which represent the groups of entities that Ansible interacts with. As mentioned in Stakeholders Analysis, Ansible is used by many companies. A few of them can be seen in the Users box¹⁵. Ansible also has integrations for a lot of systems, such as docker, aws, and vmware¹⁶. In the top left corner, we see the sponsor RedHat and its related products that can be seen as an extension of Ansible, licensed under GPLv3. Both Ansible Tower and AWX are user interfaces for Ansible, the latter being web-based. Ansible Galaxy provides an online collection of content created by the Ansible community. Worth to mention are the main services WinRM and SSH used by Ansible to access machines. The competitors are also already mentioned in Stakeholders Analysis, as well as Ansible being written in python. Communication between developers is done mainly via Github, IRC channels through freenode and meetings such as AnsibleFest.

Roadmap

The Ansible team develops a roadmap for each major and minor Ansible release. The latest roadmap shows current work; older roadmaps provide a history of the project. Roadmaps are not published for subminor versions. Team and community feedback is incorporated in each roadmap. Each roadmap is a best guess, based on the Ansible team’s experience, requests from the community, and feedback from the community. The roadmap is published both to give an idea as to what is coming and for seeking feedback from the community, making it an iterative process.

The official documentation yields the following roadmap:

With the official documentation yielding a lack of information, more informal methods of communication can be consulted. To this end the Ansible channels on webchat.freenode.net can be consulted.

The meaning of ‘feature freeze’ can be found on github.com/ansible-collections. Here a timeline has been documented with 3 bullet points:

• 2nd March 2020, we will freeze the devel branch using protected branches, and we will create the temp-2.10-develbranch from devel. This date marks the end of merging non-base plugin/module PRs into ansible/ansible.

• 9th March 2020, we will perform the initial migration against temp-2.10-devel, and we will do our initial testing of the components.

• 23rd March 2020, we intend to unfreeze devel and merge temp-2.10-devel back into devel. From that point on, devel for ansible/ansible will be for the ansible-base project only.

• TBC, community.general accepts new Pull Requests (PRs).

• TBC, the ansible package has been updated to include the Community Collections.

• TBC, alpha, beta, RC, Release dates for Ansible 2.10