I think it’s important to point out that AWX is an open source, fast moving UPSTREAM DEVELOPMENT product. You should always tell yourself this when deciding on a platform and whether to use it. It will have new, sometimes breaking features. Don’t expect stability and expect change, sometimes radical change.
I keep seeing people mention the word ‘production’ on this forum. Please see my previous point above!
Considering the plethora of platforms people want to use AWX on and with, now having one simple installer, surely makes more sense. The operator approach can’t really make that any simpler and can be maintained far better than a myriad of options.
For dev, yes. Not even a server - my desktop.
Our actual "prod" AWX instance runs on Azure AKS, along with the things it is managing. We use it to deploy test environments of AKS and other Azure resources.
For me, switching to Operator as the standard install method was great! 
We've been using it since November with 15.0.1, and I find it much nicer than the "ansible playbook generating manifests" method, because I can deploy it using Helm, the same as everything else we deploy, then Helm again to deploy the awx itself.
Thank you Howard
How did you get the operator working with helm?
I grabbed the deploy/awx-operator.yaml file and chopped it up into the components:
��� helm create awx-operator
��� mkdir awx-operator/crds
��� # match version below to the operator you are installing! DON'T use 'devel' unless you mean to.
��� wget https://raw.githubusercontent.com/ansible/awx-operator/0.8.0/deploy/awx-operator.yaml
��� # remove the leading comments that otherwise break the awk step
��� grep -v '^#' < awx-operator.yaml |awk '/\-\-\-/{f=NR".yaml"}; {print >f}'
The resulting numbered files are valid "templates" for a blank helm chart. The CustomResourceDefinitions go in the crds directory. The rest go in the templates directory. If you only need the default install, you can stop there. I usually add at least the '{{ .Release.Namespace }}' as a parameter, so we can put the operator in a non-default namespace, and rename the files to normal helm conventions (name.kind.yaml).
My problem with this is that the "downstream" product, apart from lagging behind on features (I actually want execution environments, and a version of ansible-galaxy that can talk to private git repos), doesn't seem to be any more supported - 1300 open issues for the ansible project, and another 1300 for the awx project. It's not like there's a "secret version" that is more reliable, has all the bugs fixed and works the way you want. It just lets you righteously blame someone, and maybe jump the issues queue.
You seem to mention AWX project as being production. AWX IS the development platform
If you want the stable downstream/commercial product compare it to Ansible Tower.
That was a comparison with Ansible Tower. It is not, as far as I can tell, a fragrant rolling pasture of working features and bug free operation.
As someone using Nomad as an orchestrator, I do relate at a certain level to the OP points. I can’t have a K8s cluster running AWX alone and everything else on Nomad. For that reason we’re still at 17.x (which already is a template glued with spit and gum) until we figure out how to Jerry-rig our way thru the latest versions.
Maybe I’ll deploy a k3 node inside my Nomad cluster and exceed all levels of abstractions? LOL
Anyways, I understand it was the right move to make and we’re just unlucky to be at the margin of the community (in terms of Nomad vs K8s).
Happy automating!
I just saw K3s from rancher. That works on a single node
I have set up k3s with traefik on a single host, and deployed AWX 19 on it.
Right now that AWX isn't usable (yet) due to some issues with requirements vs.
execution environments, but it works.
Host is only a dual core AMD turion 2 with 8gig ram - seems to be good enough
to run AWX in K3s and a few other odds and ends, but I haven't really been
able to test it because all my plays need stuff that isn't in the EE images
but loading requirememts seems to be broken right now.
If you want details, check here:
https://www.tuxonline.tech/index.php/2021/04/07/from-0-to-kubernetes-why-bother/
I haven't written about the actual AWX deploy yet, tho.
I did manage to deploy WITH import of my "live" awx database from the host
that it is on..
Cheers
MH
On that note have you thought of building your custom ee resources? There is ansible builder and you can customise your use of it. In your projects you can also being in the missing collections
Hi Howard,
Tower, which is now part of Ansible Automation Platform, AAP, is the stable downstream version of AWX. Same model as everything else Red Hat.
AAP has a private Automation Hub, which is supported and provides the private git repo requirement you talk about wanting.
Bear in mind, that those open issues on github, aren’t just bugs, they are feature requests and other things as well, for not just AAP but Ansible core as well. Given there are 000s of active contributors, it’s no surprise that a large and very successful open source project has this many open things. I see that many requests as a good thing, as it means we’re providing someone of value
Fixes work both ways, coming from upstream into the downstream projects and vice versa. There is no queue jumping, just a paid for supported option or this community option.
Regards
Phil.
I've tried - custom EE's seem to be broken in AWX 19, see https://github.com/ansible/awx/issues/9864
Cheers
Mathias
Hey there,
do you need to use ad-hoc-commands? Because, if not, you can build your own EE with the EE-Repo of AWX. Just clone the repo, change the requirement-files and just run docker build and push the new repo.
Worked like a charm for me (though I just needed xenapi for my deployment).
Cheers
I basically followed your suggestions to create the helm chart/templates, and was able to get the awx-operator pod to stay in a running state(finally). But that’s about as far as it gets. So no errors finally, but also no progression beyond the awx-operator running. I’m assuming I should be seeing more pods showing up in the namespace for db, rabbitmq etc. I know we have very little to reference from here, as I guess we are the only ones crazy enough to create a helm chart. But from your experience so far, do you have a rough idea what I may be missing here?
Did you create an awx CRD? Installing the operator is only the first stage of the installation. The actual awx install is triggered by creating the awx object in the k8s database, as per the awx installation instructions. I do this with a second (really short!) helm chart, just so it matches all our other installs.
You are only up to here: https://github.com/ansible/awx/blob/19.0.0/INSTALL.md#deploy-awx
I’m planning on moving my Docker-compose deployed AWX to use awx-operator. So far I have AWX installed using k3s. Using vagrant for this test and want to share it here in case it is help to anyone else:
https://github.com/zigford/awx-operator-k3s-vagrant
Sorry about the delayed response. A few higher priority projects took over, and I had to shelve this for a bit. So yes, I created a crd. I took a different approach and installed the crd manually before deploying the helm template. Ultimately, i want this to install before helm install of the chart completes. So probably use a pre-install hook. I did get a response back saying the crd was installed correctly. I then installed the helm chart to a specific namespace. The pod started, and stayed running. But thats about as far as it gets. Note: I did install the CRD to the same namespace as the awx-operator
Ok not sure if anyone here is still following this. I was able to figure out my issues above. Mostly all on my end, with trying to get awx to play nice with our templates. Finally got the pvc issue figured out. and all three pods are running now. So what i’m trying to figure out now is, where to apply the ingress configuration. I have a template file the takes ingress-nginx config info from values.yaml file and builds ingress from there. But with awx I’m not sure where to actually apply the ingress configuration. If that makes any sense. This awx deploy just in general is somewhat new territory for me, from what I’ve worked with before. Does it go in the values file i created for operator? Or perhaps the awx file that is created that kicks off building pods for postgres etc?