Installing AWX on minicube vs compose

Hi guys and gals,

I was somewhat surprised to find out that operator is now the only supported installation method for awx. Most of environments I’ve installed AWX in so far have been docker-compose based.

According to the documentation, compose should be only used for non production environments, and yet minikube is mentioned as a quick way to bring up awx operator.
Is minikube really a better solution to run awx in prod environments?

Compose was a perfect solution for environments with limited resources that are unable to provision a kubernetes cluster. With minikube I’m somewhat worried about data persistance, as it is specifically intended to be a learning and testing tool, and not a production ready kubernetes instance.

What are your thoughts on this? Is minikube stable enough to run production awx instance?

Hello,

In my opinion they just want to force us, who don’t have kubernettes, to buy Tower. They save on docker-compose development and bring more revenue.
If not, we need to had another unecessary layer of complexity with minikube. Better yet, for them, with Openshift.
It is similar to the CentOS changes…
BTW, it is not RedHat anymore, it’s IBM…

In my opinion they just want to force us, who don’t have kubernettes, to buy Tower.

I just saw a talk by a Red Hat employee that the product we used to know as “Tower” will no longer exist. It’s all going to containers. Quite the watch: https://www.youtube.com/watch?v=jZEXx8FgR58&t=2391s

-JP

In my opinion they just want to force us, who don’t have kubernettes, to buy Tower. They save on docker-compose development and bring more revenue.

I don’t think that is the case. If that is the case, that logic is flawed. If a potential client is bent on using free open source technology and can afford ansible tower, they most likely have enough resources (or can invest in enough resources) to create a kubernetes cluster, or even to use okd if we wanna keep it in red hat family, and provision AWX operator there.

I don’t mind paying for Tower and for support, but there is a large number of potential clients who are not large enough to be able to afford that.
And they are now left hanging, because they won’t be able to keep updating AWX to new releases.

I started playing with provisioning AWX on minikube today, and there is a plethora of massive issues if one plans to use it for production.

And for a company that used AWX, maybe not so much for automation, as that can easily be done with just Ansible, but for access conrolled task delegation in order to refocus their core operations teams from basic everyday repetative tasks to more important problems, that is a big loss.

I don’t think that the issue is so much with them trying to force people to buy Ansible Tower, as much as it’s them trying to refocus their stengths to building new Tower features, as Tower will change massively in the nearer future.

I just saw a talk by a Red Hat employee that the product we used to know as “Tower” will no longer exist. It’s all going to containers. Quite the watch: https://www.youtube.com/watch?v=jZEXx8FgR58&t=2391s

I’ve heard about this. I like the course they’re taking with the whole automation platform.

Dana srijeda, 31. ožujka 2021. u 15:32:53 UTC+2 korisnik nuno....@gmail.com napisao je:

Hi,

I am now using k3s under centos 8.3 for awx tests. This was fairly easy. Only encountered one issue:

https://github.com/k3s-io/k3s/issues/3122

Using the operator with ingress for http(s), but I am not using it for anything serious yet - just for playing around with AWX ui/api so I am not sure how well it actually works if you get users/jobs on there :slight_smile:

Greetings

Klaas

I just use rancher and kubernetes. Install was seemless. Had to use an external database. but was straightforward