Personally, the places where I would assist in infrastructure work were typically either small businesses that didn’t have the budget for AAP, so they needed something free or inexpensive to run jobs (many wind up using GitHub Actions or GitLab CI), or larger businesses that have AAP in some areas, but wanted to have their own managed action-runner system for internal purposes, not tied to an AAP subscription.
For those places, it’s still nice to have a supported standalone automation system with user accounts and some features like job scheduling, logs, etc. — and deploying something from a devel branch or in an undocumented / unsupported manner isn’t that enticing.
At least having ‘versions’ of AWX you could target (e.g. “I’m running 1.2.3, and next month I’ll update to 1.3.0”) would be useful, not to mention having an official installation method.
Right now, just looking at how to install/run AWX, I see:
A warning on ansible/awx about releases being paused, so that’s already a bit off-putting towards running it in a production environment.
The page I end up on still requires me to find the install instructions in the sidebar
The AWX Operator install guide talks a lot about operator versions, and much Kubernetes-isms, and recommends Minikube for local development (fine, but we’re getting pretty far into the weeds now).
And with phrasing focusing on developers and development like:
The next phase of the modernization effort will focus on providing developer resources. Specifically we want to make it really simple and straightforward for developers to spin up environments and start working with the new plugin architecture.
It makes it sound like AWX will not be maintained as a project meant to be run standalone, but only for development of Ansible Tower (as part of AAP)? Maybe I’m just seeing this in a negative light, but it really seems like AWX’s new modern flavor is not meant to be run standalone for someone like me, who might want something beyond Jenkins’ capabilities, more suited towards Ansible automation, but also doesn’t have the budget to subscribe to AAP… (but would someday, if a project’s lifecycle grew to that point, and it was easy to migrate from AWX into a Tower instance in AAP).
Its currently not a good tool - to try it out you go down the route described above.. get to the point of needing to deploy k8s for this one thing and decide to go somewhere else.. which is a shame - it will also restrict the open source input from people who might improve things to a much smaller set…
I REALLY want to get to the point where I can deploy a dev instance, a production not crazy complicated instance (via running random scripts/projects on k8s) and if it expands to a point where it is sensible to go farther then either on k8s or pay redhat.
I’m still trying to work out if I should be spending my time on using another tool to run my ansible but really really don’t want to…
On the plus side - I’m hoping it is less likely to just die in the weeds as there has been SOME discussion within the last 2 years now…
Thanks a lot for writing out your extensive view! It immediately reminds me of my first experience with Ansible AWX when i set it up last year, which wasn’t pleasant. I managed to get it working by using/following the GitHub page of Kurokobo, awx-on-k3s.
The installation of Ansible AWX could be something that needs work first before working out other aspects of the new Ansible AWX environment. To have an official way of installing Ansible AWX that doesn’t require a lot of knowledge, components or 3rd party written guides. Though I can understand this might/probably sound(s) a lot easier than done.
I have looked at a AAP-license, but the costs are far from what I can justify. It’d be nice to keep on using Ansible AWX to build a mature platform, which can justify the costs of moving to AAP over time.
Note that this is just the “official” installation variant. My AWX install (latest release) hums fine along in a simple docker-compose with two containers (awx itself & redis, postgres is external).
Last time I checked it wouldn’t reliably record the output of a playbook executing the setup module and outputting the response. And while I’d pay for the commercial version to get useful features - not having access to the source means I cannot hotfix anything there
Last time I checked it wouldn’t reliably record the output of a playbook executing the setup module and outputting the response
This bug was fixed a long time ago, as far as I remember. This was a problem with long logs, it was fixed by optimizing the writing to the database (x10).
To my knowledge AWX was originally a commercial, cloesd source product developed by Ansible Inc because it got acquired by Red Hat, which was then cleaned up and open-sourced by Red Hat. So it’s not really a “community project” in the sense that it was created by the community and taken over by some company.
(There are a lot of things that can and should be criticized about AWX, but I don’t see how the above claim applies.)
Yeah, in this case it was Tower, then it was migrated to AWX in 2017, and for a while it was maintained in such a way people could easily (well, semi-easily, Tower was never made to be as simple as Ansible!) self-host it.
As the use case of Tower expanded further and further into enterprisey realms, I think it just got a bit too much to maintain an easily deployable stack. So the AAP (Ansible Automation Platform) kinda ran away from the AWX roots, and it is synced back here and there, but it feels like it’s a little left out, in comparison to other RH projects.
Even CentOS Stream is still a usable thing. AWX has been hard to host for years, and I usually recommend people run something simpler if they just have a small team or individual need. (Says the guy who’s built far too many Kubernetes clusters, lol)
I do not think that is exactly fair. AWX was easy to host up until (and including) it’s latest releases. Yes, RHEL pushed a k8s setup, but nothing stopped you from running it in a single docker container (as we have been doing from 2016 to the latest releases). Sure it means some work for you instead of taking something fully polished but that would have been very easy for the community to maintain. It certainly is less work than getting k8s running and fighting the tower operator
It wasn’t easy to activate if you did not trust ‘pip intall’ to correctly install secured or securable versions of the massive and never RHEL published tree of python interdependent modules. mrmeee tried to RPM bundle hem but seems to have given up. I’m afraid the casual use of bleeding edge modules and their inherently unstable dependency trees makes casually bundling and deploying AWX risky, especially without tagged releases in several years. Since Red Hat is not “eating its own dog food” by RPM bundling even those python dependencies, not even in Fedora, it makes me very leery of having to hand-bundle and security scan all the pypi.org published dependency chains.
Others may be more trusting of ‘pip install’, but some very painful experience with JPackage and CPAN and even old BSD based ‘make install’ operations leaves me far less confidence of such dynamic compilation and deployment tools.
