问题描述
在一个高负载和高安全性的生产集群中，有多个独立的繁重工作，这些工作可以是独立的、用Ansible或Python脚本实现的，或者完全是手动工作，例如：
– 迁移虚拟机（具有特定条件，例如，触发警报、调用CLI获取虚拟化主机状态、向Prometheus发送请求获取停机时间）。
– 创建工单（例如，定期收集数据，然后如果满足条件，运行一个创建Jira或Clickup工单的作业）。
– 定期或在触发警报时清理悬空的ACL和端口。
– 当调用特定的Webhook时运行特定的playbook或操作（例如，在硬件管理工具（如Netbox）中进行硬件修复后，将服务器状态或标签恢复为正常）。
– 定期在频道上发送集群摘要状态的自动化（例如，在另一个团队的频道上发送Ceph集群的健康状态）。
一般来说，我们可以将这些工作分为两组：
– 事件 => Webhook => 动作：当调用Webhook时触发的工作，这可以是集群内的Alertmanager到我们的自动化Webhook，也可以是来自Jira到入站自动化Webhook的外部请求。详细的工作流程如下：事件（Alertmanager触发）=> Webhook调用（带有特定变量）=> 控制器（Tower服务器捕获请求）=> 链接（Tower服务器将工作链接到某个频道或工单，以便可以追踪）=> 工作（在控制器上执行）=> 结果（作为Prometheus的指标）。
– 定期：从数据和条件中挖掘出的工作。
必要条件：
– 自动化：在一切正常工作时，不需要手动操作。
– 安全性：必须以安全的方式维护机密信息，例如，历史命令中不可见密码。
– 透明性：工作状态和输出必须随时可见。
– 监控：我们必须能够通过Tower监控我们的工作，例如，失败的作业数量、作业列表、作业总时间。
一个理想的假设示例：
┌────────────────────────────────────┐
│ │
│ ┌───────┐ ┌──────┐ │
│ │ TOWER │ ┌──────┐ │ Host │ │
│ └───────┘ │ Host │ └──────┘ │
│ └──────┘ │
│ ┌──────┐ │
│ ┌──────┐ │ Host │ │
│ │ Host │ └──────┘ │
│ └──────┘ │
│ ┌──────────────┐ │
│ │ AlertManager │ │
│ └──────────────┘ │
│ │
│ ┌──────┐ │
└──────────┤ EDGE ├──────────────────┘
└──────┘
我们将使用类似Ansible的自动化工具部署所谓的Tower，将作业的配置推送到git存储库，并使用任何自动化工具更新Tower进行CI/CD，例如：
# 示例配置文件
Jobs:
event-acls-are-high-job:
on: webhook call /alerts/
condition: ALERT_NAME == r"ACLS REACHED.*"
script: bash remove-extra-acls.sh
periodic-server-maintenance-job:
every: 1 days
script: bash check-maintenance.sh
现在，我们将配置集群内的Alertmanager，将警报发布到内部Tower Webhook端点。
作为管理员，我拥有一个完全集中化的工具，无需独立部署作业，独立为它们创建监控，只需定义一个工作和相关脚本。
我甚至可以在备份场景中使用它，而不必担心工作流的稳健性，因为我们信任Tower本身。
选项：
– Gitlab/Github CI/CD：这些实际上非常适合处理工作和状态的透明性，但Runner不设计为从事件（除了存储库事件）中调用，而且它们不容易调度，尽管有一些解决方案可以通过API调度流水线。
– Ansible AWX：这是运行定期任务作为ansible-playbooks的完美选择，非常有限且非常适合我们的愿景。
– adnanh/webhook：这是完全匹配所有这些的Webhook部分的完美选择，没有监控，没有工作透明性，只是完全盲目地运行脚本，需要大量工作来处理这些问题。
– 将Gitlab CI与Webhook集成（非常值得怀疑）：从Alertmanager引发的事件 => 调用内部Webhook => 调用Gitlab API以某种方式生成特定的流水线 => 集群上的Runner接收任务并应用工作 => Runner的监控和Gitlab工作的透明性。
所以在我讲述了所有这些故事之后，实现这个目标的最佳选择是什么，如何消除繁重工作？我们可以使用哪些最佳工具或与之集成的工具？