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),仅供参考
