Ara: ansible run analysis
This is a short blogpost meant as both an introduction for those who don’t know Ara and a guide on how to install Ara.
Ara means ‘Ansible Runtime Analysis’, and is a tool for storing metadata that Ansible uses during execution. It is very valuable, because it takes a lot of guesswork and entering debug statements in your playbook away.
This is a guide on how to install Ara on Oracle Linux 7. I assume ansible is already installed. If want to start fresh, add EPEL and yum install ansible and git. That’s all you need to begin!
First, become root and install ara using a playbook:
mkdir ansible cd $_ mkdir roles git clone https://git.openstack.org/openstack/ansible-role-ara roles/ara echo "- hosts: localhost roles: - ara" > install_ara.yml ansible-playbook install_ara.yml useradd ansible systemctl stop ara
Ara and a systemd unit (service) is created and started by the playbook. I create an ‘ansible’ user and stop the service. The ansible ara role creates a service running as root, I don’t like running daemons as root if it’s not necessary.
The next part is executed as the user that is supposed to run ansible, which I created above:
echo "[defaults] local_tmp = /home/ansible/.ansible/tmp callback_plugins = /usr/lib/python2.7/site-packages/ara/plugins/callbacks [ara] dir = /home/ansible/.ara " > ~/.ansible.cfg
What this does, is define the callback for ara so executions are recorded. The default way of recording is entering the details in a sqlite3 database. This database (which is a file) is stored in /home/ansible/.ara, which is defined in the [ara] section using ‘dir’.
The next part is executed as root again:
pip install --upgrade ara echo "[Unit] Description=ARA After=network.target [Service] Type=simple User=ansible Group=ansible TimeoutStartSec=0 Restart=on-failure RestartSec=10 RemainAfterExit=yes ExecStart=/bin/ara-manage runserver -h 0.0.0.0 -p 9191 [Install] WantedBy=multi-user.target" > /etc/systemd/system/ara.service systemctl daemon-reload systemctl start ara
This first executes pip (which is installed by the playbook above) and does an upgrade of ara and it’s depended packages. If this is not done, the website run by ara-manage will throw a 500 internal error (!!). Then the echo overwrites the current ara webserver config run as root by a modified version that runs it as ansible. Next we inform systemd it needs to reload the config, and then we start the ara service again.
Now run an ansible playbook as the ansible user, and go to port 9191 with your browser. It will detail the entire run, and list all the plays and tasks, with all information! For the CLI die-hards, there is a CLI tool ‘ara’ which provides the same information as the website, but entirely text based. It can generate static html files for sending through though.
If you don’t want to record everything, remove or comment the callback_plugins setting in ~/.ansible.cfg. Uncomment or add back if you want to record again. You can quite simply purge the history by stopping the ara service and remove the ~/.ara/ansible.sqlite file. Ara has an option to use mysql or postgresql instead of sqlite.
Addendum:
The CLI provides easy access to the results once you figured out how to use it. This is an example:
First list all the playbook run (I ran one playbook):
$ ara playbook list +--------------------------------------+--------------------------------+---------------------+----------+----------+-----------------+ | ID | Path | Time Start | Duration | Complete | Ansible Version | +--------------------------------------+--------------------------------+---------------------+----------+----------+-----------------+ | a152d1e5-fdab-4f50-b84a-de2d0b336124 | /home/ansible/ansible/test.yml | 2017-05-11 16:57:25 | 0:00:00 | True | 2.3.0.0 | +--------------------------------------+--------------------------------+---------------------+----------+----------+-----------------+
Then show the tasks in this playbook:
$ ara task list -b a152d1e5-fdab-4f50-b84a-de2d0b336124 +--------------------------------------+-----------------+------+------+---------+---------------------+----------+ | ID | Name | Path | Line | Action | Time Start | Duration | +--------------------------------------+-----------------+------+------+---------+---------------------+----------+ | bf0bbc33-b0a4-4ac3-8242-58f5c8f1c4e5 | Gathering Facts | None | None | setup | 2017-05-11 16:57:25 | 0:00:00 | | 2b952b48-611f-424d-ba06-b94e22e87b1c | command | None | 3 | command | 2017-05-11 16:57:26 | 0:00:00 | +--------------------------------------+-----------------+------+------+---------+---------------------+----------+
Once you got the task IDs, you can list the task results:
$ ara result list --task 2b952b48-611f-424d-ba06-b94e22e87b1c +--------------------------------------+-----------+---------+---------+---------------+---------------------+----------+ | ID | Host | Action | Status | Ignore Errors | Time Start | Duration | +--------------------------------------+-----------+---------+---------+---------------+---------------------+----------+ | d9278719-209e-41f8-8ecc-4ad2681dcdf6 | localhost | command | changed | False | 2017-05-11 16:57:26 | 0:00:00 | +--------------------------------------+-----------+---------+---------+---------------+---------------------+----------+
And then show the result in long format:
$ ara result show d9278719-209e-41f8-8ecc-4ad2681dcdf6 --long
+---------------+---------------------------------------------+
| Field | Value |
+---------------+---------------------------------------------+
| ID | d9278719-209e-41f8-8ecc-4ad2681dcdf6 |
| Playbook ID | a152d1e5-fdab-4f50-b84a-de2d0b336124 |
| Playbook Path | /home/ansible/ansible/test.yml |
| Play ID | 683dbe2b-84cc-4e17-b2ec-9b013e7d7612 |
| Play Name | localhost |
| Task ID | 2b952b48-611f-424d-ba06-b94e22e87b1c |
| Task Name | command |
| Host | localhost |
| Action | command |
| Status | changed |
| Ignore Errors | False |
| Time Start | 2017-05-11 16:57:26 |
| Time End | 2017-05-11 16:57:26 |
| Duration | 0:00:00 |
| Result | { |
| | "changed": true, |
| | "cmd": "echo \"test\"", |
| | "delta": "0:00:00.002718", |
| | "end": "2017-05-11 16:57:26.616876", |
| | "rc": 0, |
| | "start": "2017-05-11 16:57:26.614158", |
| | "stderr": "", |
| | "stderr_lines": [], |
| | "stdout": "test", |
| | "stdout_lines": [ |
| | "test" |
| | ] |
| | } |
+---------------+---------------------------------------------+
This is how to install ara on OSX:
sudo pip install ara --user
Not sure if I need to use sudo when installing with ‘–user’, I ended up with directories in my local user Library directory for use with python that were not readable to my user ‘frits.hoogland’. In order to correct that, I ran:
cd sudo chown -R frits.hoogland Library
Now fetch the ara directory in the python site-packages directory:
python -c "import os,ara; print(os.path.dirname(ara.__file__))" /Users/frits.hoogland/Library/Python/2.7/lib/python/site-packages/ara
Now create a ansible config file to be able to active the ara callback for running ansible-playbook and point the ara server to the sqlite database:
echo "[defaults] local_tmp = /Users/frits.hoogland/.ansible/tmp callback_plugins = /Users/frits.hoogland/Library/Python/2.7/lib/python/site-packages/ara/plugins/callbacks [ara] dir = /Users/frits.hoogland/.ara" > .ansible.cfg
At this moment the ara callback is activated. If you don’t want the overhead of ara writing all information to the sqlite database, comment ‘callback_plugins’.
If you want to use the ara webserver, active it using:
nohup ara-manage runserver -h localhost -p 9191 &
If you want to deactivate the ara webserver, stop it using:
pkill -f ara-manage
Frits Hoogland Weblog 