链接：https://github.com/elastic/elasticsearch/tree/main/build-conventions

elasticsearch自动化更新

本专栏使用updatecli实现自动化版本更新与依赖管理。

其配置通过编排文件（updatecli-compose.yaml）实现，该文件罗列了称为Policies的自动化任务，每个任务通过配置文件（Values Files）获取项目特定细节，实际执行逻辑则来自容器镜像（Policy Sources），确保自动化过程可复现。

概览

在这里插入图片描述

章节导航

Updatecli编排配置
值文件
策略
策略源（容器镜像）

第一章：Updatecli编排配置

欢迎来到使用Updatecli实现Elasticsearch项目版本更新自动化的首章教程~

维护Elasticsearch这类大型软件项目的依赖更新（包括基础容器镜像、库文件乃至内部工具）是项艰巨任务。

设想我们作为项目管理者，每天需要跟踪数十项待检查更新的内容！此时我们需要一个主清单来确保所有事项被覆盖且无遗漏。

这正是updatecli-compose.yaml文件的价值所在。

它如同Updatecli在项目中的主检查清单，虽不包含具体更新细节，但通过罗列所有待执行任务（即检查项），告知Updatecli需要更新哪些内容。

何为`updatecli-compose.yaml`？

该文件本质上是协调多个Updatecli任务的编排配置文件，是执行系列自动化更新的起点。它向updatecli compose命令传达：“这是本项目需运行的所有更新任务清单，每个任务的具体指令如下。”

参考简化版文件结构：

# `updatecli compose ...`的配置文件
policies:# 清单首项- name: 处理ironbank更新policy: ghcr.io/elastic/oblt-updatecli-policies/ironbank/templates:0.3.0@sha256:... # (策略细节简化)values:- .github/updatecli/values.d/scm.yml- .github/updatecli/values.d/ironbank.yml# 清单次项- name: 更新Updatecli策略policy: ghcr.io/updatecli/policies/autodiscovery/updatecli:0.8.0@sha256:... # (策略细节简化)values:- .github/updatecli/values.d/scm.yml- .github/updatecli/values.d/updatecli-compose.yml

该YAML文件核心是policies:列表（通过-标识），每项代表一个Updatecli需执行的更新任务。

每任务项包含：

name：人类可读的任务名称（如"处理ironbank更新"），便于理解任务目标
policy：指向具体执行指令或模板，即该任务的"操作手册"（详见策略章）
values：提供策略运行所需细节的文件列表，如同填写操作手册中的空白项（详见下一章值文件）

这种任务项的划分有点类似于Manus…

运行机制

执行updatecli compose时，系统将：

读取updatecli-compose.yaml
遍历policies列表
获取每个策略的指令（通过policy引用）
加载values文件中的具体配置
执行策略

流程示意图：

在这里插入图片描述
IronBank是一个DeFi借贷协议，采用信用授权机制，允许用户无需抵押直接借款，主要服务于机构和高信用用户。

简言之，updatecli-compose.yaml作为中央调度器，统一管理项目所需的所有版本更新任务，确保通过单入口即可触发全量自动化更新。

总结

updatecli-compose.yaml是协调运行多个Updatecli任务的主入口，其作为检查清单具备两大功能：

罗列项目所需的全部更新任务（策略）
指引每个任务获取具体配置（值文件）

理解该文件的中心地位后，让我们深入探究策略配置的核心——值文件。

下一章：值文件

第二章：值文件

在上一章《Updatecli编排配置》中，我们了解到updatecli-compose.yaml文件是项目中Updatecli的主检查清单。它列出了所有需要运行的更新任务（策略），并指引Updatecli获取每个任务所需的具体配置。

这些"具体配置"就存储在值文件中。

值文件解决何种问题？

设想我们有一个操作手册（策略），描述如何更新容器镜像版本。

这个手册是通用性的——它阐述着标准步骤：“查找最新版本”、“定位项目文件中镜像引用位置”、“用新版本替换旧版本”。

当项目中使用数十个不同镜像且分散在不同文件时，若为每个镜像编写独立手册将极其低效！

这正是值文件的用武之地。它们为通用操作手册提供特定场景下的专属配置，回答以下核心问题：

跟踪哪个具体镜像？
在哪个文件路径检索？
需匹配的具体行或模式？

通过将这类项目专属信息存入独立文件，我们的操作手册（策略）得以保持通用性和复用性。

(可复用性的方案）

何为值文件？

值文件通常是采用key: value格式的YAML配置文件，类似为特定策略任务填写的定制表单。以下通过上章的示例片段展开说明：

# `updatecli compose ...`的配置文件
policies:- name: 处理ironbank更新policy: ghcr.io/elastic/oblt-updatecli-policies/ironbank/templates:0.3.0@sha256:...values:- .github/updatecli/values.d/scm.yml- .github/updatecli/values.d/ironbank.yml # <-- 此处即为值文件！

假设.github/updatecli/values.d/ironbank.yml内容如下（简化版）：

# .github/updatecli/values.d/ironbank.yml - 简化示例
imageName: elasticsearch/elasticsearch # 需更新的镜像名称？
imageTag: 8.12.2 # 当前跟踪版本（或匹配模式）
dockerfilePath: x-pack/docker/elasticsearch/Dockerfile # 镜像引用所在文件路径

该值文件提供三项关键配置：

imageName：目标容器镜像名称
imageTag：当前版本标识（或版本模式）
dockerfilePath：镜像引用文件路径

策略如何消费值数据？

当Updatecli执行策略时，会加载值文件数据并将其实例化到策略中。通用策略通过占位符（如{{ .imageName }}）动态获取专属配置，实现具体操作：

检索elasticsearch/elasticsearch的最新版本
扫描x-pack/docker/elasticsearch/Dockerfile文件
查找引用elasticsearch/elasticsearch的行（可能包含旧版本8.12.2）
用新版本替换旧标识

底层运行机制

在这里插入图片描述

流程分解：

updatecli compose读取主清单文件
定位策略项（如处理ironbank更新）
解析策略模板引用地址
加载关联值文件（scm.yml、ironbank.yml）
合并值数据并注入策略模板
策略实例化后执行具体更新操作

该过程对清单中每个策略循环执行，不同策略可复用同一模板配合不同值文件。

(多态）

采用独立值文件的优势

优势	描述	示例
可复用性	单一策略可服务多个更新任务	用相同"镜像更新"策略配合`valuesA.yml`更新`imageA`，`valuesB.yml`更新`imageB`
关注点分离	策略逻辑（如何更新）与项目数据（更新对象及位置）解耦	"镜像更新"策略无需感知具体操作的是`elasticsearch/elasticsearch`镜像
可读性	值文件直观展示任务目标	查看`ironbank.yml`即可明确该任务针对特定Ironbank镜像
易维护性	修改配置无需调整策略代码	更新新镜像只需新建值文件或修改现有文件，策略模板保持不变