首页
学习
活动
专区
圈层
工具
发布
社区首页 >问答首页 >不可测事件驱动容量

不可测事件驱动容量
EN

DevOps用户
提问于 2020-04-24 14:43:23
回答 3查看 524关注 0票数 2

我在以前的工作中经常使用SaltStack,并且喜欢它的事件驱动模型。现在,在我的新工作中,我们使用的是Ansible,而不是事件驱动的模型。

我想知道在Ansible的任何地方是否存在隐藏的容量(或者没有隐藏:)?

另外,如果您认为尝试并实现基于Ansible的事件驱动模型是个好主意(或者Ansible不是设计成这样使用的,这将是一个错误)。

谢谢

编辑,我明白了Arcege告诉我的,我的问题是,在Ansible中是否有一个事件驱动的子系统:答案是否定的。

因此,我的第二个问题是:为了获得真正的自动化基础设施,您将插入什么事件系统?(例如卡夫卡)

EN

回答 3

DevOps用户

发布于 2020-04-26 22:59:14

我不能说我使用过SaltStack,但我在Ansible方面有丰富的经验。这两种方法是不同的。基于事件的使用并不是隐藏的,只是它本身并不存在。

Ansible是无代理的(没有仆从),因此它依赖于管理系统才能控制。这在如何管理事件、事件的来源、如何引发事件以及如何以自动化的方式进行操作等方面增加了灵活性。这意味着它可以通过CI/CD进行配置,通过监视系统修复故障,并与像Telegraf这样的服务器代理相结合。

我认为应该问的问题是:什么会触发这个工具,它应该在哪里运行,应该执行什么。剩下的只是得到正确的工具来连接。一般来说,它将涉及一个CI/CD系统,但有很多。

一些例子使用案例:

  • 在管道中的裸金属服务器上检测到一个碎片,触发服务器的重新供应。
  • 一个来自PR系统的触发器,用于启动一个用于更新测试服务器的构建。
  • Telegraf检测到磁盘问题,该问题触发警报,然后该警报可以启动构建来调整磁盘大小,或者提供更大的服务器并在那里传输服务。

除了Telegraf用例外,事件可能来自运行代理以外的其他来源。然后,在Telegraf的情况下,提供不同服务器的选项将超出SaltStack的范围。

要回答您的最后一个问题,即使使用事件驱动的模型,这是一个必要的问题和选择取决于用例。

票数 2
EN

DevOps用户

发布于 2022-12-14 12:31:08

有一种新的事件驱动的自动化。它不断地监听各种来源的触发器,如- Altertmanager、Kafka客户等。

官方网站- https://www.ansible.com/use-cases/event-driven-automation

要获得详细的审查,请查看以下内容:- https://www.linkedin.com/pulse/testing-new-event-driven-ansible-prabhushakti-haridaswa

票数 2
EN

DevOps用户

发布于 2021-05-12 02:44:44

最有可能的是,您所指的事件驱动系统是SaltStack的反应堆信标。事实证明,Ansible允许使用连接插件来支持其他传输方法,其中之一是盐库。这意味着没有什么能阻止你吃蛋糕和吃蛋糕-你可以使用Ansible来运行一个游戏手册,使用一个盐类堆叠的仆役,并使用您的仆从运行Ansible剧本。

简而言之,为什么不使用SaltStack来驱动不可见的事件?你已经知道并热爱它,那么为什么不使用已经熟悉的东西呢?

票数 0
EN
页面原文内容由DevOps提供。腾讯云小微IT领域专用引擎提供翻译支持
原文链接:

https://devops.stackexchange.com/questions/11435

复制
相关文章

相似问题

领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档