news 2026/10/27 9:35:18

Elastic 即代码：自动化的不只是基础设施

作者头像

张小明

前端开发工程师

1.2k 24
文章封面图
Elastic 即代码：自动化的不只是基础设施

作者：来自 Elastic kylerozanitis

Elastic 即代码：自动化不只是基础设施

Terraform 是工程师常用的工具，用来通过一种叫 Infrastructure as Code（ IaC ）的模式创建、修改和删除基础设施。它通常用于管理云资源，比如应用负载均衡器（ ALB ）、数据库和虚拟机，但它同样也可以用来管理 Elastic 集群。不过，在很多 Elastic 环境中，集群创建之后的所有事情都发生在 Kibana 里 —— 索引模板、索引生命周期管理（ ILM ）策略、检测规则等等。

这会导致没有源码控制、无法回滚变更、无法进行漂移检测，也没有关于谁在什么时候、为什么修改了什么的审计记录。

Elastic 是一个 API 驱动的平台，这意味着你在 Kibana 中几乎能做的所有事情，也都可以通过 APIs 来完成。这表示我们不仅可以把基础设施作为代码来管理，还可以把更多内容代码化，从而获得可复现的环境、可审计性，以及对整个技术栈的信心。

在今天的博客中，我将展示如何只用一条 terraform apply 命令，就能创建一个 Elastic Cloud 集群、一个 ILM 策略、一个索引模板以及一个检测规则 —— 所有内容都在 Git 中进行版本控制。

理念

当你刚开始使用 Elastic、学习某个功能如何工作，或者调试一个用于 detection rule 的 ES|QL 查询时，Kibana 非常好用。但最终的目标，应该是尽可能把所有东西都作为代码来管理。这让你可以自由实验，同时仍然能够 rollback 到一个可用的版本。它也确保从 DEV 到 PROD 的变更是经过 review 和 approval 的。就像发布一个新的应用代码版本可能是灾难性的，对 Security Operations Center ( SOC ) 中运行的 detection rule 进行修改，同样可能非常危险。

Elastic 为平台的几乎每一个部分都暴露了 API。因此，通过结合 Terraform Elastic Cloud Provider 和 Elastic Stack Provider，我们可以构建一个可复现的 Elastic-as-Code 工作流，用来部署一个 cloud cluster、ILM 策略、index template，以及 detection rule。

第 1 步：部署一个 Elastic Cloud 集群

使用 Elastic Cloud provider，在你的根 main.tf 文件中定义一个 ec_deployment resource：

resource "ec_deployment" "demo" { name = "advent-demo" region = "us-east-1" version = "9.2.2" deployment_template_id = "aws-cpu-optimized-faster-warm-arm" elasticsearch = { hot = { autoscaling = {} } } kibana = { topology = {} } }

这会创建一个完全托管的 Elastic Cloud 部署。请注意，即使没有显式指定 hot 层节点规格，仍然需要包含hot = { autoscaling = {} }。关于部署模板的更多信息，可以参考 Deployment templates 文档。

第 2 步：定义一个 ILM 策略

使用 Elasticstack provider，通过elasticstack_elasticsearch_index_lifecycle资源来定义一个 ILM 策略：

resource "elasticstack_elasticsearch_index_lifecycle" "advent_logs_ilm" { name = "advent-logs-ilm" delete { min_age = "30d" delete {} } }

为了简单起见，这个 ILM 策略会将数据保留在 hot 层 30 天，然后删除。用代码来管理 ILM 策略非常有价值，因为改动可能会对数据以及整个集群健康产生连锁影响。想象这样一个场景：一位工程师决定添加一个 cold 层，设置为 1 个 primary shard 和 1 个 replica shard，但实际上只有一个 cold 节点。你可以想象，很快就会开始看到警告。

第 3 步：绑定 ILM 的 Index Template

在这一步中，我们将使用 elasticstack_elasticsearch_index_template 资源来定义我们的 index template，并引用前一步中定义的 ILM 策略：

resource "elasticstack_elasticsearch_index_template" "advent_logs_template" { name = "advent-logs-template" index_patterns = ["advent-logs-*"] priority = 200 template { settings = jsonencode({ index = { lifecycle = { name = "advent-logs-ilm" } } }) mappings = jsonencode({ properties = { "@timestamp" = { type = "date" } "message" = { type = "text" } "user" = { type = "keyword" } } }) } }

步骤 4：检测规则

作为一个经常使用检测规则来处理从传统 SIEM 到更复杂欺诈用例的人来说，Discover 和 Kibana Detection Rules 是一个强大的组合，但一旦你确定了最终配置，最好使用 elasticstack_kibana_security_detection_rule 资源把它存储到 Git 中：

resource "elasticstack_kibana_security_detection_rule" "failed_login_rule" { name = "Multiple Failed Logins (Elastic as Code demo)" description = "Detects multiple failed login events in advent-logs indices for the Elastic-as-Code demo." rule_id = "advent-multiple-failed-logins" # Detection logic type = "query" query = "event.action:\"failed-login\"" language = "kuery" index = ["advent-logs-*"] # Scheduling from = "now-5m" to = "now" interval = "5m" # Risk/severity severity = "medium" risk_score = 50 # Misc metadata enabled = true tags = ["terraform", "advent-demo", "elastic-as-code"] author = ["Kyle Rozanitis"] # Human context field license = "Elastic License v2" false_positives = ["Legitimate user mistyping their password during normal usage"] references = ["https://elastic.github.io/detection-rules-explorer/"] note = "Investigate source IP, username, and host. Check for brute force behavior." setup = "Ensure authentication events are indexed into 'advent-logs-*'." }

第 5 步：让一切真正运行起来

你的代码仓库现在看起来应该像这样：

├── main.tf ├── ilm.tf ├── template.tf ├── rule.tf

现在只需运行：

terraform apply

Terraform 会创建：

  • 一个新的 Elastic Cloud 集群
  • 一个 ILM 策略
  • 一个与该 ILM 策略关联的索引模板
  • 一个检测规则

这就是 Elastic 平台应有的使用方式。

结语

如果你看到这里，感谢阅读！所有内容都可以在名为 elastic-as-code 的 GitHub 仓库中找到。只需克隆仓库，创建一个 Elastic Cloud API key 并获取你的 Organization ID，将它们添加到 .env 文件中，安装 Terraform，然后运行 terraform apply。

今天的目标是展示如何用 Terraform 管理远不止云基础设施。在我的个人环境中，我甚至会进一步创建 JSON 文件来管理尚未有 Terraform 资源的功能，比如异常检测任务。由于 Elastic 在 Kibana 和 API 之间提供了功能一致性，你可以轻松自动化创建其余资源。

能够回滚错误更改、在更新前进行同行评审、通过分支从 DEV → STAGING → PROD、检测平台漂移，以及用单条命令重建整个栈，这些都是非常强大的能力。

自动化愉快，节日快乐！

原文：https://discuss.elastic.co/t/dec-7th-2025-en-elastic-as-code-automating-more-than-just-infrastructure/383587

版权声明: 本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若内容造成侵权/违法违规/事实不符，请联系邮箱：809451989@qq.com进行投诉反馈，一经查实，立即删除！
网站建设 2026/10/26 18:16:12

解锁 LLM 中 AI Agent 的效率密码，掌握实用优化技巧【线上直播】

在 AI Agent 飞速发展的当下，如何提升提示词效率、让模型响应更精准高效，成为许多开发者关注的核心问题。无论是刚接触 LLM 与 AI Agent 的新手，还是正在实操中遭遇效率瓶颈的从业者，都可能被这些问题困扰：MCP Service…

作者头像 李华
网站建设 2026/10/25 3:37:04

【AI×实时Linux：极速实战宝典】显存池 - 编写自定义 Allocator 预分配全量显存，杜绝运行时的 cudaMalloc 开销

简介在高性能计算和人工智能应用中，显存管理是影响程序性能的关键因素之一。传统的显存分配方式（如使用 cudaMalloc 动态分配显存）可能会导致运行时的随机延迟，尤其是在频繁分配和释放显存的场景下。为了优化显存管理，…

作者头像 李华
网站建设 2026/10/26 4:45:16

Vue2 中 Options API：组织组件逻辑的主要方式

Vue2 Options API 是组织组件逻辑的主要方式，通过 data、methods、computed、watch 等选项定义组件。其优势在于结构清晰、学习成本低，适合中小型组件。但随着复杂度增加，会出现逻辑分散、复用困难等问题。Vue3 的 Composition API 通过逻辑组…

作者头像 李华
网站建设 2026/10/25 1:55:27

LLM实时调校心电图设备，精度翻倍

📝 博客主页：Jax的CSDN主页 AI赋能中医心身医学：破解精神障碍诊疗的“证型-方药”匹配困局目录AI赋能中医心身医学：破解精神障碍诊疗的“证型-方药”匹配困局 引言：被遗忘的诊疗断层 一、技术破局：LLM如何重…

作者头像 李华
网站建设 2026/10/25 5:46:05

为什么“容器化“技术很重要？——从虚拟机到 Docker

📦 为什么"容器化"技术很重要？——从虚拟机到 Docker 🚀大家好，我是无限大，欢迎收看十万个为什么系列文章 希望今天的内容能对大家有所帮助今天咱们来聊聊容器化这个"软件界的集装箱革命"&#xf…

作者头像 李华