Hi everyone,
I am currently implementing AWX for a customer. Right now, they manage application change management through Harvest and a custom Python watcher that triggers Ansible automations to apply changes.
My idea is to replace this custom watcher with Ansible Rulebook and Event-Driven Ansible (EDA), to have a more native and scalable solution.
I’ve already used EDA on Automation Platform (subscription), but I’m not sure if it can be implemented on AWX.
My questions are:
Is it possible to run Ansible Rulebook/EDA directly on AWX?
If yes, what is the best way to manage it (integration, deployment, or specific configurations)?
Are there any best practices or known limitations I should be aware of?
I am using AWX 24.5.0 with kubernetes setup.
Thanks in advance to anyone who can provide guidance or share similar experiences.
To my knowledge, EDA is still an external system that you deploy and connect to your AWX instance. We had to run it this way until it was included in AAP (the Azure managed app usually lags on new features). Ours was deployed on an AKS cluster and once it was working, it was stable but upgrades were always a bit of a coin toss. I would recommend having a proper dev/prod setup to test new versions and keep a backup of the database along with the database encryption key. Also, if you’re going to use the container/K8s deployment method, keep track of the SHA256 hashes of the container versions. Outside of being a general best practice, you’ll want these if you need to rollback.
Once EDA was available in our AAP instance, we decommissioned the freestanding setup so the setup/operations may be easier now but passing on some of the trials and tribulations we encountered. If you don’t need the web frontend, you could just run ansible-rulebook from the CLI, in a container (1 per container, podman systemD services) or as pods on your K8s cluster. The frontend is nice for feedback and management but not necessary to have EDA trigger on an event (similar to ansible-playbook vs AWX/AAP)
For integration, you use OAuth tokens from AWX/AAP that are setup in EDA to connect the instances. The AWX/AAP user will need access to the orgs where the job/workflow templates are stored.
For triggers, we used outbound triggers whenever possible as opposed to inbound webhooks (Azure Service Bus, AWS SQS, Kafka). In the earlier K8s-based deployments, the service names of webhook triggers would change every time the rulebook restarted which would break the ingress routes. We actually had a custom job running on our K8s cluster that would look for webhook trigger services and dynamically update the ingress config. This was fixed in the last version of EDA in that the service names are pinned when you activate a rulebook but still have some scars
I think EDA is a great addition to the ecosystem but just be prepared that you may have to get familiar with its innerworkings to self-manage it.
