Open dmsimard opened 4 years ago
Hi!
I'm using ARA 1.x, for the advanced logging, tracing and debugging capabilities (even when compared to Jenkins, AWX/Tower or Rundeck) - especially when working with multiple playbooks and systems. Simply put: ansible logs are so much more readable thanks to Ara!
Wish list? Perhaps better integration with AWX/Tower or Jenkins, though you can already to that. Maybe improved authentication and authorization for enterprise space? That's something Tower excels at, so perhaps a tower integration would solve that. Also, documenting how to use ARA with molecule - using raw_env_vars ANSIBLE_CALLBACK_PLUGINS.
There are a few magical tools (ara, molecule, ansbile-lint) that make life so much easier. I think the biggest item on my wish list would be awareness. Perhaps even inclusion in the documentation and official Red Hat material, such as DO447 - Ansible Best Practices :-).
Thanks for developing Ara, and Happy New Year!
+1 we are already an AWX shop. Having defined and documented way of running ARA alongside AWX would be a big help and get those people who might dread having to support them as totally different/side-by-side.
I use ARA a lot at customers sites, when they don't want the complexity of Tower or AWX, but must be able to have some playbook insights.
But with the newer versions of ARA (nodejs
, Python3 and so) installation on CentOS7 is tedious.
You need a couple of hoops to jump through. That's why I'll do a presentation at CfgMgmtCamp next February about this setup. It's called ARA on RHEL7 – Welcome to hell :-)
I'm using ARA 0.x with zuul to record job execution and access the result with the middleware.
The use-case is to investigate job behavior, in particular, look at the task complete result and see the playbook/role/task content.
I'd like to use ARA 1.x with zuul to centralize job execution logs and be able to query what job used what playbook or roles. Ideally, using a cli (or browser extension), i'd like to query the ARA 1.x api to get builds associated with a yaml file (e.g. a playbook or role tasks).
I use ARA a lot at customers sites, when they don't want the complexity of Tower or AWX, but must be able to have some playbook insights.
But with the newer versions of ARA (
nodejs
, Python3 and so) installation on CentOS7 is tedious. You need a couple of hoops to jump through. That's why I'll do a presentation at CfgMgmtCamp next February about this setup. It's called ARA on RHEL7 – Welcome to hell :-)
@tonk oh, I am quite interested in this but it would definitely be easier on run on EL8 or perhaps in containers. I unfortunately won't be at CfgMgmtCamp but would love to watch your presentation if it's recorded !
I am trying to use ARA 1.x to talk to multiple Ansible server. Installation doesn't seems to be straight forward i.e., (Install ARA on Ansible server and access the url outside the server needs lot of configuration) Documentation regarding this could be improved better.
ARA 0.x
Using it to show detailed results of tasks in bigger plays mostly during development of modules, plugins, playbooks, etc... Its really nice to use the web UI rather than scrolling through a terminal mess especially on larger plays with many hosts.
I'd switch to 1.x, but there isn't the detail task results. There was a WIP change on opendev I believe, but I can't find it now.
I'd help code it, but just don't have enough time to learn react/patternfly
@tonk, @berendt, @nahun: Appreciate the feedback about ara-web ! It helps emphasize that the frontend needs more attention.
You might be interested in a recent blog post where I wrote about the situation of ara-web and the re-introduction of a built-in javascript-less interface in 1.2: https://ara.recordsansible.org/blog/2019/12/31/2019-in-retrospective-for-ara-records-ansible
There is also an open issue to disambiguate and clarify what is the purpose and status of the built-in UI vs ara-web: https://github.com/ansible-community/ara/issues/88
Edit: You can see a live demo of the built-in interface here: https://api.demo.recordsansible.org/
Hi David,
being relatively new to ansible, I just ran into ARA few days ago and this is really a very very nice tool. I'm currently doing an evaluation as we plan to use it in several customer automation projects where ansible playbooks will be kicked from ansible tower using the tower API to launch the jobs from a high level workflow...and the whole platform runs on OpenShift4.x. The web UI would be used by admins and developers performing playbook debugging, and using the ARA API, results might also be embedded in the mgt ui of our application for day 2 staff. We would also use it in our devops tool chain as part of integration test.
So here is my wish list (some may already be available from u or others as I've not yet completely finalised my eval. and if not we'll come-up with our own implementation of the missing parts)
I'm actually listing here the features I think I can already get, just in case I've been too optimistic or wrong in my eval:
Finally, I'm not sure yet if we can get the following points out of the box (but there are not absolutely mandatory for us to decide/start) using ARA but would be nice to have:
[ ] Possibility to filter playbook executions from various "sources" either playbooks ran on different platforms all pointing to the same ARA server or playbooks ran in different organisations in ansible tower or both
[ ] Possibility to scale and make ARA more resilient with several API servers and a load balancer in the front and a DB cluster in the back-end.
[ ] Possibility to have RBAC on the results to provide access to only a subset of playbooks execution results depending on which groups the user belongs to or role he may have.
Thx again for writing such great tools and sorry for the length of this post.
@fckbo Thanks for the excellent feedback and for telling us about your use case !
Please see answers in-line:
[packaging]Package ARA server/API in docker image
The project doesn't build and publish officially supported containers (yet?) but ara is packaged on both PyPi and Fedora which should hopefully make this relatively simple to do and maintain in the future. I have tested an approach with buildah and podman that works well: https://review.opendev.org/#/c/687905/
I've created an issue to track this: https://github.com/ansible-community/ara/issues/105
[deployment]Have an Helm chart or/and an operator to deploy it with postgresql on Openshift
This could be a good contribution to the project ! Maybe we could use the Ansible operator and use our existing roles and playbooks ?
I've also created an issue for this: https://github.com/ansible-community/ara/issues/106
[packaging]Package the ARA http client in a separate package (I actually just quickly did an alpha version of the http client to run it on python 2.7 with my very limited python skills.) but need it for python 3.x.
Why would you need the HTTP client in a separate package ?
There are two "packages" right now:
ara
: Installs Ansible plugins as well as the API clients (although with this, only the http client is usable since the offline client requires the API server dependencies)ara[server]
: Installs the above in addition of the API server dependenciesThe ara
package is designed to be lightweight:
ara==1.3.2
certifi==2019.11.28
chardet==3.0.4
idna==2.8
pbr==5.4.4
requests==2.22.0
urllib3==1.25.7
You mention python 2.7 but also needing it for python 3. Could you expand on this ? There is an issue about getting the callback and API clients to work with 2.7 here: https://github.com/ansible-community/ara/issues/72
ARA Can work with playbooks launched using ansible-playbook command line & Ansible Tower
ansible-playbook commands are recorded out of the box but there is an issue opened about documenting how to get it to work with AWX/Tower: https://github.com/ansible-community/ara/issues/24
ARA can be setup to use a postgresql or mysql DBs
Yes, this is supported and integration tested.
ARA API can be used to retrieve playbook results and display status information down to the task level in our own application for use case where the provided web client would not be used or/and when using it in our automatic integration tests.
Yes, this is supported. Note that there is currently a disparity in the level of information provided by ara-web and the interface built-in to the API server.
See my comment above for more info.
ARA API could rely on external LDAP for authentication as it relies on Django which itself can be setup to use an external LDAP.
In theory this is possible but it is not currently tested or documented. It would be a nice addition to the docs if you are able to get it working.
Possibility to filter playbook executions from various "sources" either playbooks ran on different platforms all pointing to the same ARA server or playbooks ran in different organisations in ansible tower or both
If you plan on aggregating data from multiple locations into a single instance of ARA, I think it would be a good idea to use labels to tag your playbooks in a way that makes it easier to search for them and filter results.
Possibility to scale and make ARA more resilient with several API servers and a load balancer in the front and a DB cluster in the back-end.
In theory this is possible since the API server state is kept in the database. I have not tested this myself and would love to hear back from users if they have.
Possibility to have RBAC on the results to provide access to only a subset of playbooks execution results depending on which groups the user belongs to or role he may have.
A full blown granular RBAC is currently out of scope. AWX/Tower does a great job at this and maybe we can leverage that in the future somehow.
ARA currently supports authentication and requiring authentication for reads or for writes across the entire instance. This gives you the ability to have read-only users and read-write users but doesn't have the concept of granularity to allow certain users (or groups of users) to access only certain playbooks based on different criteria.
Thx again for writing such great tools and sorry for the length of this post.
Nothing to be sorry about, thanks again :+1:
David, thx for you comprehensive answer, I've been quite overwhelmed these days and will put back focus on this in the coming weeks.
@dmsimard I'm not sure if it will be recorded, I'm in the Ansible room, which is not one of the main rooms. But my sheets will be online, next week (after CfgMgmtCamp) at https;//speakerdeck.com/tonk
NTW: On RHEL8/CentOS8 it works out of the box. Checked this last week.
We are using 0.x in production and just switched over to 1.x in nonprod.
Our main use is to surface detailed results of failed playbook runs by linking to the ARA UI from our automated failure notifications. Secondarily it's useful any time we want to look at historical playbook results or timing, e.g. to see the detailed return from a particular module without rerunning the playbook with more verbosity.
I can't think of any features that we're missing; it slots nicely into our tooling and (apart from needing to pin django and tzlocal to older versions) 1.x was fairly painless to install on Amazon Linux 2.
Using 1.4 now in dev and production stages. Only using the API server and its built-in user interface since the 'ara-web' had fallen behind in feature parity when I was using 1.3.
The ansible runs as part of our initialization of ec2 workloads, including AMI builds. The use-case is to have easier/faster debugging of failed tasks as part of that startup sequence.
Feature Wishlist
ARA 1.4.3.dev27
I use it to analyse my ansible run results. I debug output from my ansible playbook and use ARA API http://<>/api/v1/playbooks/
Issue in 1.5.x Once i upgraded to 1.5.x my automation failed as the API output json has been changed. I would appreciate if the changes to API are trivial
I have setup ara 1.x here because ansible is starting to gain traction and being used by other teams. Communication being a complex thing, it allows us to access logs from every run to catch recurring errors that operators encounter but don't tell us about as well as provide support when they do speak with us.
It also allows our team to see whether operators adopt new features, what's used, what isn't.
Having logs from scheduled runs is the cherry on top.
One thing that would be nice is RBAC so we could open access to other teams which would allow them to communicate about ansible runs inside their own team.
Hi !
In an effort to better understand what users are doing with ARA, I would be very grateful if you could answer the following questions:
The answers will be useful in determining the direction for future development.
Thank you !