Ara is a simple web server showing detailed information about Ansible runs. It is helpful in understanding and troubleshooting Ansible runs.
Ansible runs, especially on the command line, do only provide limited information. Details about used variables, the timing of each task or other information are only available using additional plugins, but the details provided by them are usually narrowed to a use case.
A better way to provide information about Ansible runs is to collect the data and provide them in a web framework. That is what Ansible Tower (or AWX, the upstream project to Tower) does for example: collecting detailed data and providing them in the jobs overview.
But there are situations where a fully fledged Tower is too much, or where a comparing overview of the various runs is needed. This is where ara comes in:
ARA Records Ansible playbook runs and makes the recorded data available and intuitive for users and systems.https://ara.recordsansible.org/
It makes your Ansible playbooks easier to understand and troubleshoot.
ara was originally developed by people of the OpenStack community, and still today has strong ties with it. It does not replace Ansible Tower at all, since it does not manage the execution at all. It complements the information and overview part, and in a way more competes with the logging solutions which can be connected to Ansible Tower.
How to install
The installation of ara is pretty straight forward and described in the documentation: the software is basically installed via
pip, afterwards the server can be started as a local running instance. The connection between Ansible and ara is done via action and callback plugins.
The installation of the ara package is quickly done. Note that on systems with both Python 2 and 3 you need to pick the right pip version:
$ pip3 install --user ara ... $ python3 -m ara.setup.action_plugins /home/liquidat/.local/lib/python3.7/site-packages/ara/plugins/actions $ python3 -m ara.setup.callback_plugins /home/liquidat/.local/lib/python3.7/site-packages/ara/plugins/callbacks
Notice that the binaries end up in
~/.local/bin. If that is not part of the
$PATH variable, the server executable to start ara needs to be addressed directly, like
$ ~/.local/bin/ara-manage runserver * Serving Flask app "ara" (lazy loading) * Environment: production WARNING: Do not use the development server in a production environment. Use a production WSGI server instead. * Debug mode: off 2019-05-06 02:45:49,156 INFO werkzeug: * Running on http://127.0.0.1:9191/ (Press CTRL+C to quit) 2019-05-06 02:45:55,915 INFO werkzeug: 127.0.0.1 - - [06/May/2019 02:45:55] "GET / HTTP/1.1" 302 -
The web page can be accessed by pointing a web browser towards
http://127.0.0.1:9191/. Since Ansible is not connected yet to ara no data are shown:
As mentioned, to connect ara to Ansible a callback plugin is used. There are different ways available to tell Ansible to use a callback plugin, the easiest is to set up a
ansible.cfg with the appropriate data:
$ python3 -m ara.setup.ansible | tee -a ansible.cfg [defaults] callback_plugins=/home/rwolters/.local/lib/python3.7/site-packages/ara/plugins/callbacks action_plugins=/home/rwolters/.local/lib/python3.7/site-packages/ara/plugins/actions
Note here that this creates a new section named
[defaults]. Check if your
ansible.cfg already has a section called
[defaults] and if so merge the entries manually. Now call a few playbooks and check the results:
ara provides easy access to all existing runs, making it possible to easily compare different runs with each other. At the same time detailed information are provided for individual runs, making it easy to figure out what actually happened.
ara is an interesting attempt at better displaying the information from Ansible runs. It helps analyzing what is happening in each run, where problems might be hidden and so on.
If you use Ansible Tower already the information are available to you anyway. If you like the way how it is presented in ara you can even use both at the same time.