5.8 Elasticsearch-GitOps：把集群配置、索引模板、ILM 全部纳入 Git CI/CD
GitOps 的核心是“以 Git 为唯一事实源，让任何变更都可审计、可回滚”。把这套理念搬到 Elasticsearch 身上，就是把集群级配置、索引模板、生命周期策略（ILM）、角色权限、Ingest Pipeline 等一切“应该受控”的 JSON/YAML 全部收进 Git 仓库，再通过 CI/CD 流水线自动 apply，做到“谁合并谁负责、谁回滚谁安心”。本节给出一条可直接落地的实施路径：目录规范、工具选型、流水线编排、灰度校验、灾难回滚，全部开箱即用。
1. 目录规范：让 1000 个 JSON 文件也能一眼找到
es-gitops/ ├─ clusters/ # 按环境/集群拆目录 │ ├─ prod/ │ │ ├─ cluster.settings.json │ │ ├─ snapshot.policy.json │ ├─ staging/ ├─ templates/ # 索引模板 v2（composable） │ ├─ app-logs.json │ ├─ metrics.json ├─ ilm/ # 生命周期策略 │ ├─ hot-warm-delete-30d.json ├─ ingest/ # Ingest Pipeline │ ├─ user-agent.json ├─ security/ # 角色、用户、API Key 定义 │ ├─ roles/ │ ├─ api-keys/ ├─ kibana/ # Saved Objects NDJSON │ ├─ ndjson/ ├─ .gitlab-ci.yml # 或 .github/workflows/es-gitops.yml文件命名统一使用<resource-type>.<name>.json，方便脚本批量遍历；每个文件顶部加_comment字段，GitOps 工具在 apply 前自动剔除，兼顾可读性与兼容性。
2. 工具选型：用官方 terraform-provider 还是自制脚本？
| 方案 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|
| terraform-provider-elasticstack | 声明式、漂移检测、state 锁 | 需要 Terraform 经验、资源覆盖度有限 | 团队已用 Terraform 管理云资源 |
| 自制 Python/Go CLI（基于 es-openapi） | 零依赖、可定制、资源全覆盖 | 需自己写漂移对比逻辑 | 想 100% 控制行为，或需调用未进 TF 的 API |
| Elastic Cloud GitOps Operator（ECK） | 云原生、CRD 化 | 只支持 Elastic Cloud on K8s | 已跑在 K8s 上，且愿意用 CRD |
本节以“自制 CLI”为例，逻辑只有三步：
esplan：把 Git 目录渲染成“期望状态”desired.json。esdiff：调用_cluster/state与_template等接口，拿到“实际状态”actual.json，做深度 diff。esapply：按依赖顺序（ILM → Template → Pipeline → Settings）下发 PUT/POST，全部 2xx 才退出；任何一步 4xx/5xx 立即回滚并注释 MR。
3. 流水线编排：MR → plan → approve → apply
GitLab CI 示例（GitHub Actions 同理）：
stages:[plan,apply]variables:ES_PLAN_ARTIFACT:es-plan.jsonplan:stage:planimage:ghcr.io/your-org/es-gitops:1.7script:-esplan--out=$ES_PLAN_ARTIFACTartifacts:paths:[$ES_PLAN_ARTIFACT]expire_in:1 weekonly:-merge_requestsapply:stage:applyimage:ghcr.io/your-org/es-gitops:1.7script:-esapply--plan=$ES_PLAN_ARTIFACTonly:-mainwhen:manual# 强制人工点击，防止直接推主干关键卡点
- Concurrency Gate：使用 Redis 分布式锁，确保同一集群同时只有一个 apply 在跑。
- Approval Rule：变更
security/目录必须得到 SRE 与安全团队双重 Code-Owner +1。 - Drift Checkpoint：每晚 03:00 跑
esdiff，结果写入 Prometheus metrices_gitops_drift{cluster="prod"}，值 >0 就告警。
4. 灰度校验：让“模板错误”只打垮 5% 的索引
- 在
templates/里引入canary=true标签，流水线先把模板写到logs-canary-*别名。 - 通过索引模板
priority把流量切 5% 到新模板。 - 跑 30 min 后检查：
- 集群 reject 日志是否增长；
- Ingest Pipeline 失败率；
- 数据节点 CPU 倾斜。
- 全部绿灯后 MR 合并，再全量 rollout；任意指标异常，自动
esapply --rollback=<commit-sha>回滚模板并封锁 MR。
5. 灾难回滚：把“删库”从 30 min 缩短到 3 min
- 快照策略即代码：
snapshot.policy.json同样放在 Git，每天 02:00 触发 SLM，保留 7 天。 - Rollback CLI：
先比较快照与当前段文件差异，再并行 restore，重放 translog，最后把别名指回。esrollback--cluster=prod--target=ilm-hot-warm-delete-30d\--restore-snapshot=s-20260103-020013\--index-pattern="app-logs-*"\--dry-run - ChatOps：在 Slack 输入
/es rollback prod app-logs 30d，Bot 调用上面 CLI 并在频道贴出 diff 链接，回滚过程全员可见。
6. 小结与 checklist
- 一切 JSON/YAML 进 Git，不接受人肉在 Kibana/ES 里点“Save”。
- 任何变更走 MR，至少两人 Code-Owner + 自动 plan 报告。
- 流水线自带并发锁、灰度、回滚三件套； reject/5xx 即回退。
- 每晚漂移检测，结果当指标，>0 就告警。
- 季度演练一次“删索引”+“回滚快照”，确保 RTO < 5 min。
把以上五条固化成团队 RFC，Elasticsearch GitOps 就可以像交付业务代码一样交付基础设施配置：版本可追踪、发布可灰度、故障可回滚——让 Elastic 集群真正变成“ cattle”，而不再是你半夜 SSH 上去救火的“pet”。```
推荐阅读：
PyCharm 2018–2024使用指南
更多技术文章见公众号: 大城市小农民
)
