Vespene自动扩缩容实战：按需伸缩Worker集群降低云端成本-育师

Vespene自动扩缩容实战：按需伸缩Worker集群降低云端成本

【免费下载链接】_old_vespeneDISCONTINUED: a frozen fork will exist forever at mpdehaan/vespene项目地址: https://gitcode.com/gh_mirrors/ol/_old_vespene

Vespene自动扩缩容是开源CI/CD平台Vespene最实用的进阶功能之一：当构建需求波动明显时，它可以根据队列中等待和运行中的构建数量，自动调整Worker集群规模，让云端资源"按需伸缩"，把闲置算力成本降到最低。与其长期租用固定数量的构建机，不如让Vespene在高峰期自动扩容、低谷期自动缩容。本文将结合官方文档与源码，手把手带你完成Worker Pool自动扩缩容配置、看懂扩容公式，并给出云端镜像准备与成本优化的完整实践清单。

什么是Vespene自动扩缩容？为什么能省钱

Vespene是一个水平可扩展的CI/CD平台，Worker（构建机）负责消费Worker Pool（工作池）中的构建任务。固定数量的Worker存在两大痛点：

高峰期构建排队，发布效率下降；
低谷期Worker闲置，云账单照付。

Vespene内置的自动扩缩容引擎可以动态计算每个Worker Pool"需要多少台Worker"，再调用云平台API完成伸缩。整个机制采用双插件架构，分别由规划器（Planner）和执行器（Executor）完成，二者都可以独立替换。

Vespene自动扩缩容的工作原理：Planner与Executor双插件

核心逻辑集中在 autoscaler.py 管理命令中：

Planner（规划器）：默认插件 stock.py 统计当前排队（QUEUED）与运行中（RUNNING）的构建数量，套用扩容公式计算出期望的Worker数量。
Executor（执行器）：默认插件 shell.py 将结果通过Jinja2模板注入到executor_command命令中执行，比如调用 Terraform 或云厂商CLI完成实际的扩容/缩容。

插件注册在 plugins.py 中，目前内置stock规划器与shell执行器，开箱即用。

Worker Pool自动扩缩容配置步骤

第一步：在UI中开启自动扩缩容

进入 Worker Pool 编辑页面，找到Autoscaling Tab，勾选 "enable autoscaling"，然后依次配置以下核心参数（对应 worker_pool.py 模型字段）：

planner：选择规划插件，默认stock
executor：选择执行插件，默认shell
executor_command：执行器要运行的伸缩命令（支持Jinja2模板）
reevaluate_minutes：每隔多少分钟重新评估一次规模（默认10分钟）

第二步：调校扩容权重参数

stock规划器使用的核心参数包括：

queued_weight：每个排队构建分配多少Worker（默认1）
running_weight：每个运行中构建分配多少Worker（默认1）
multiplier：计算结果乘数（默认1.0）
excess：额外多分配的数量（默认0）
minimum / maximum：伸缩上下限（默认0/10）

大多数场景保持默认即可，其中minimum建议设为1，避免完全缩到零导致构建彻底中断。

看懂Vespene扩缩容计算公式

stock规划器的扩容逻辑遵循以下公式：

b1 = 排队构建数 × queued_weight + 运行构建数 × running_weight b2 = b1 × multiplier + excess 结果 = min(max(b2, minimum), maximum)

规划器最终输出两个关键值（详见 stock.py）：

size：目标Worker总数（适用于声明式伸缩系统，如Terraform）
queued_size：新增Worker数量（适用于非声明式系统，需自行跟踪实例数）

用Shell Executor对接Terraform实现云端自动伸缩

shell执行器会把executor_command命令中的{{ size }}、{{ worker_pool.name }}等变量渲染成实际值后执行。一个典型的 Terraform 伸缩命令示例如下：

cd /opt/plans git pull terraform apply /opt/plans/{{ worker_pool.name }}.tf -var 'size={{ size }}'

如果使用的是非声明式伸缩方案，请改用{{ queued_size }}作为新增数量，并把reevaluate_minutes调大，避免实例反复创建销毁造成资源抖动。

云端Worker镜像准备清单

要让自动扩缩容真正跑起来，云端镜像必须满足以下条件，官方文档在 autoscaling.rst 中给出了10条硬性要求，这里摘录最关键的部分：

镜像内包含与Web控制台相同版本的Vespene；
包含完整的/etc/settings.d配置，尤其是secrets.py；
配置好构建根目录且该目录必须存在；
Worker Pool 配置的 sudo 用户对构建根目录有写权限；
镜像启动时自动运行 Worker 进程；
Worker 所在网络能够访问 Vespene 数据库；
配置日志聚合服务（如将日志输出到 /var/log/vespene）；
使用触发器或共享文件系统保存构建产物，防止 Worker 销毁后文件丢失；
预装所有构建工具，避免启动时大量下载依赖。

此外，强烈建议给所有实例打上vespene_worker和工作池名称的标签，便于追踪成本归属。

启动自动扩缩容引擎：一条命令

自动扩缩容需要常驻的守护进程来监控工作池并下发伸缩请求，通过以下命令启动：

python manage.py autoscaler --queue <worker-pool-name>

常用参数说明：

--queue：指定要监控的Worker Pool名称，可重复指定多个；
--sleep：每次评估循环的休眠秒数（默认20秒，防止频繁查询数据库）；
--force：忽略定时限制立即执行一次伸缩并退出，适合调试。

建议为每个Worker Pool启动独立的autoscaler进程以获得最佳并行度，并将日志重定向到/var/log/vespene/。

Worker启动命令与缩容安全

自动扩容出的Worker建议使用"构建完即退出"的模式，避免实例被缩容时正在执行的构建被强制中断：

ssh-agent python manage.py worker <worker-pool-name> --max-builds=1 --max-wait-minutes=5

如果伸缩系统不是声明式的（无法追踪已分配的实例数），务必设置--max-builds=1，否则可能短时间内创建出大量云资源，造成账单失控。

降低云端成本的三个最佳实践

合理设置上下限：maximum防止扩容失控，minimum避免完全闲置，两者共同约束成本上限。
缩容延迟保护：如果云平台支持，设置约1小时的缩容延迟，并将终止策略设为"优先终止最旧实例"，避免中断运行中的构建。
预置依赖镜像：把构建工具、依赖缓存全部打进镜像，减少构建期间的网络流量和等待时间，间接降低算力占用。

总结

Vespene自动扩缩容把"按需伸缩Worker集群"从手工运维变成了自动化能力：Planner 负责算、Executor 负责做，公式清晰、插件可换、成本可控。建议先熟练使用固定Worker跑通基础流程，再结合本文的配置步骤与镜像清单开启自动扩缩容，就能在不牺牲构建速度的前提下，把云端成本实实在在降下来。

【免费下载链接】_old_vespeneDISCONTINUED: a frozen fork will exist forever at mpdehaan/vespene项目地址: https://gitcode.com/gh_mirrors/ol/_old_vespene

创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考