Tell us about your AWX deployments and how you use them!

Project Discussions
1

Hey, AWX community! I’d love to hear about your own AWX deployments and how you use AWX within your projects and organizations.

On the deployment side:

  • What kind of hardware or cloud do you deploy on?
  • What type of Kubernetes install do you run on (minikube, k3s, upstream Kubernetes, OpenShift, etc.)?
  • Do you always use the latest version or do you tend to only upgrade when you need to?
  • What is your backup and restore plan like?

On the usage side:

  • How many jobs does your instance spawn daily (roughly)?
  • Do you have a lot of scheduled jobs that run automatically? Or webhook integrations that spawn jobs from GitHub/GitLab commits?
  • Do you tie AWX into other systems (either via its API or having it call into other systems for auth or credentials or so on)?
  • What kinds of interesting things do you automate with it?
  • Are any of your playbook repos or custom collections/EEs public and open source?
    • Anything you’ve developed and want to brag about or share with the community? :slight_smile:
4 Likes
2

Hi Rick,
We’ve been using AWX at Skedulo since not long after I started there (also not long after Tower went open source).

We recently created a migration from 1.0.6 (!) to 22.3.0 (and are now at 23.0.0).

We run on kubernetes, and now have a helm-based deployment (I think an ansible-based operator is the wrong solution for managing things on Kubernetes, no matter how much I like ansible).

All of our software deployments use AWX, so we’re doing at least 10+ deployments per cluster per day. Some of these deployments are triggered from CI, and others are manually triggered once the various quality gates have passed (we also have some continuous delivery that deploys automatically to production)

AWX is effectively our backend for deployments (an audit point, a source of deployment logs etc), we have an internal deployments console that provides a nice front end that abstracts a lot of the detail away.

I think the most interesting thing we do is kubernetes configuration (I talked about this at AnsibleFest 2018 and have barely had to change the ansible side of it since) - we have one single role that manages all of our applications, each application is configured with one or more manifest files, plus secrets and configmaps - the job can also do DB init and migrations.

I’m looking to open source our awx-helm repository soon, and am happy to go into further depth about how we maintain AWX using helm

4 Likes
3

Hi,

We today use AWX as a poc to show what an “ansible scheduler” can do for us when it comes to many problems and solutions. Ansible itself thru cli is powerfull and AWX has been a wonderful POC for me to gain leverage on buying the full AAP.

To be fair, AWX is solid, and runs on a single node k3s cluster. The deployment, upkeeping and patching is not straight forward and the documentation has to times been everywhere when going over to the Kubernetes Operator. That being said, i have learned alot from deploying it and have it running also.

3 Likes
4

I installed a “custom” AWX on a vm because I wanted to get receptor working before it was a feature and the k8s operator was hindering me. So I reversed engineered the docker files to get it working (works great)

use cases: scheduling and API

3 Likes
5

we are using AWX as POC also this year. it’s a single node k3s, on a virtual host, while it’s being company vetted.
we’re actively working to use this for automated playbook scheduling of our known routine tasks such as monthly patch/reboot (which includes software repository updates), account expiration reporting, configuration management and auditing.
we are also building AWX based playbooks to handle the adhoc emergency software and firmware patching that pop up, including package repository updates when needed.
it has allowed us to have a web based documented repeatable process that anyone with credentials can access and execute, without the need for in depth command line training.

3 Likes