<p>There's a new Ansible Event-Driven automation. It constantly listens to triggers from variety of sources such as - Altertmanager, Kafka clients etc.</p>
<p>Official Site -
<a href="https://www.ansible.com/use-cases/event-driven-automation" rel="nofollow noreferrer">https://www.ansible.com/use-cases/event-driven-automation</a></p>
<p>For detailed review check out this:-
<a href="https://www.linkedin.com/pulse/testing-new-event-driven-ansible-prabhushakti-haridaswa" rel="nofollow noreferrer">https://www.linkedin.com/pulse/testing-new-event-driven-ansible-prabhushakti-haridaswa</a></p>

CC BY-SA 4.0
2022-12-14T12:31:08.380Z
2022-12-14T12:31:08.380Z
Kenny
<p>I can't say that I've used SaltStack, but I have a good deal of experience with Ansible.  The two are different approaches.  Event based use is not hidden, it is just not there by itself.</p>

<p>Ansible is agent-less (no minions), and as such it relies on a management system to be able to control.  This adds flexibility on how to manage events, where they come from, how they are raised and what to do in an automated fashion.  This means that it can be used for provisioning through CI/CD, fixing faults through a monitoring system, combined with a server agent like Telegraf.</p>

<p>The questions I think that should be asked is: what would trigger the tool, where it should run and what should be performed.  The rest is just getting the right tools to link up.  Generally, it will involve a CI/CD system, but there are plenty of those.</p>

<p>Some example uses cases:</p>

<ul>
<li><p>detecting a flake in a build on a bare-metal server in a pipeline, triggering to re-provision the server.</p></li>
<li><p>a trigger coming from the PR system, to start a build to update test servers.</p></li>
<li><p>Telegraf detects a disk issue, which triggers an alert which can then start a build to resize the disk or provision a larger server and transfer services there.</p></li>
</ul>

<p>Except for the Telegraf use case, the events are likely coming from sources other than the agent running.  And then with the Telegraf case, the option of provisioning a different server would be outside the scope of SaltStack.</p>

<p>To answer your last question of even to use a event-driven model, it's a matter of necessity and choice depending on the use cases.</p>

CC BY-SA 4.0
2020-11-12T19:21:18.533Z
Coming back a long time after the original post, I've built some experience in ansible since.
Regarding your answer, i do not completely agree with you as :
"the option of provisioning a different server would be outside the scope of SaltStack", well not really, salt includes salt-cloud which allow one to provision any type of VM across a long range of cloud providers.
"the events are likely coming from sources other than the agent running", well in this case salt would just act as ansible would then, except it has embedded event reactor system which make it easier to answer event...
Pier
CC BY-SA 4.0
2020-11-28T03:54:05.560Z
Thanks.  As I said, I haven't worked with SaltStack.  I was going on what I gleaned from docs I could peruse and the general agent model used.
Arcege
CC BY-SA 4.0
2020-04-26T22:59:14.393Z
2020-04-26T22:59:14.393Z
Arcege
<p>Most likely, the event driven system you refer to is SaltStack's <a href="https://docs.saltproject.io/en/latest/topics/reactor/index.html" rel="nofollow noreferrer">Reactors</a> and <a href="https://docs.saltproject.io/en/latest/topics/beacons/index.html" rel="nofollow noreferrer">Beacons</a>. As it turns out, Ansible allows the use of <a href="https://docs.ansible.com/ansible/latest/plugins/connection.html" rel="nofollow noreferrer">Connection plugins</a> to support other transport methods, <a href="https://docs.ansible.com/ansible/latest/collections/community/general/saltstack_connection.html" rel="nofollow noreferrer">one of which is SaltStack</a>. This means that there is nothing stopping you from having your cake and eating it too - you can use Ansible to run a playbook using a saltstack minion and use you minions to run Ansible playbooks.</p>
<p>In short why not use SaltStack to drive your Ansible events? You already know it and love it, so why not use what's already familiar?</p>

CC BY-SA 4.0
2021-05-17T08:06:31.487Z
Thanks for the heads-up, I did move from the company where I encoutered this "issue" but the information is still good-to-know.
Pier
CC BY-SA 4.0
2021-05-12T02:44:44.727Z
2021-05-12T02:44:44.727Z
James Shewey
<p>I've been using SaltStack a lot in my previous job, and loved its event driven model. Now, in my new job, we are using Ansible, and definitely not in an event driven model.</p>
<p>I was wondering if there was this capacity hidden (or not hidden :)) anywhere in Ansible ?</p>
<p>Also if you think that it was a good idea to try and implement this event driven model based on Ansible (or if Ansible was not designed to be used like this and it would be an mistake).</p>
<p>Thanks</p>
<p>[EDIT]
I got what Arcege is telling me, my question was if there was an event-driven sub-system in Ansible : The answer is NO.</p>
<p>So my second question is : What event system would you plug into Ansible in order to get a truly automated infrastructure ? (<em>e.g.</em> Kafka)</p>

<ansible><automation><salt>
Ansible event driven capacity
Pier
# Ansible event driven capacity

(Asked by: username_0 on 2020-04-24)

I've been using SaltStack a lot in my previous job, and loved its event driven model. Now, in my new job, we are using Ansible, and definitely not in an event driven model.

I was wondering if there was this capacity hidden (or not hidden :)) anywhere in Ansible ?

Also if you think that it was a good idea to try and implement this event driven model based on Ansible (or if Ansible was not designed to be used like this and it would be an mistake).

Thanks

[EDIT]
I got what username_2 is telling me, my question was if there was an event-driven sub-system in Ansible : The answer is NO.

So my second question is : What event system would you plug into Ansible in order to get a truly automated infrastructure ? (*e.g.* Kafka)

**Tags:** ansible, automation, salt


---

## 3 answers

### Answer by username_1 on 2022-12-14. Score: 2

There's a new Ansible Event-Driven automation. It constantly listens to triggers from variety of sources such as - Altertmanager, Kafka clients etc.

Official Site -
<https://www.ansible.com/use-cases/event-driven-automation>

For detailed review check out this:-
<https://www.linkedin.com/pulse/testing-new-event-driven-ansible-prabhushakti-haridaswa>


---

### Answer by username_2 on 2020-04-26. Score: 2

I can't say that I've used SaltStack, but I have a good deal of experience with Ansible. The two are different approaches. Event based use is not hidden, it is just not there by itself.

Ansible is agent-less (no minions), and as such it relies on a management system to be able to control. This adds flexibility on how to manage events, where they come from, how they are raised and what to do in an automated fashion. This means that it can be used for provisioning through CI/CD, fixing faults through a monitoring system, combined with a server agent like Telegraf.

The questions I think that should be asked is: what would trigger the tool, where it should run and what should be performed. The rest is just getting the right tools to link up. Generally, it will involve a CI/CD system, but there are plenty of those.

Some example uses cases:

* detecting a flake in a build on a bare-metal server in a pipeline, triggering to re-provision the server.
* a trigger coming from the PR system, to start a build to update test servers.
* Telegraf detects a disk issue, which triggers an alert which can then start a build to resize the disk or provision a larger server and transfer services there.

Except for the Telegraf use case, the events are likely coming from sources other than the agent running. And then with the Telegraf case, the option of provisioning a different server would be outside the scope of SaltStack.

To answer your last question of even to use a event-driven model, it's a matter of necessity and choice depending on the use cases.

> **Comments:**
> **username_0**: Coming back a long time after the original post, I've built some experience in ansible since. Regarding your answer, i do not completely agree with you as : "the option of provisioning a different server would be outside the scope of SaltStack", well not really, salt includes salt-cloud which allow one to provision any type of VM across a long range of cloud providers. "the events are likely coming from sources other than the agent running", well in this case salt would just act as ansible would then, except it has embedded event reactor system which make it easier to answer event...  
> **username_2**: Thanks.  As I said, I haven't worked with SaltStack.  I was going on what I gleaned from docs I could peruse and the general agent model used.  

---

### Answer by username_3 on 2021-05-12. Score: 0

Most likely, the event driven system you refer to is SaltStack's [Reactors](https://docs.saltproject.io/en/latest/topics/reactor/index.html) and [Beacons](https://docs.saltproject.io/en/latest/topics/beacons/index.html). As it turns out, Ansible allows the use of [Connection plugins](https://docs.ansible.com/ansible/latest/plugins/connection.html) to support other transport methods, [one of which is SaltStack](https://docs.ansible.com/ansible/latest/collections/community/general/saltstack_connection.html). This means that there is nothing stopping you from having your cake and eating it too - you can use Ansible to run a playbook using a saltstack minion and use you minions to run Ansible playbooks.

In short why not use SaltStack to drive your Ansible events? You already know it and love it, so why not use what's already familiar?

> **Comments:**
> **username_0**: Thanks for the heads-up, I did move from the company where I encoutered this "issue" but the information is still good-to-know.  

---

