混合云环境下的自托管CI，核心诉求是用私有环境守住敏感代码与内网依赖，同时借公有云扛住构建峰值。Buildkite的设计将调度控制留在云端SaaS，执行端Agent完全自托管，这种分离结构正好适配混合云：本地数据中心常驻一批Agent处理日常提交，云服务器按负载临时扩容Agent应对大版本集成。
一、Buildkite Agent工作机制简述
Buildkite由控制平面与执行平面组成。控制平面负责流水线定义、任务排队与日志聚合，托管在官方云服务；执行平面即Agent，是一个常驻进程，主动从队列拉取任务并在本地执行。因为Agent只出网不暴露端口，企业防火墙无需开放入站规则，这让它既能放在内网，也能放在任意云主机。
在自托管场景里，团队通常维护多个Agent队列，例如default对应本地机群，cloud对应云服务器分组。流水线脚本通过queue字段指定目标，未指定时由默认队列消费。这种软隔离让同一套pipeline可跨环境调度，无需为云上构建重写脚本。
二、混合云部署的拓扑设计
典型拓扑是：本地VM或物理机运行基础Agent，处理每小时稳定提交；云账号开通按量实例组，通过启动脚本自动装Agent并打上cloud标签。两端Agent都连同一个Buildkite组织，共享流水线视图。网络层面，若构建需拉取内网制品，云Agent可通过IPSec或零信任隧道访问，避免把仓库镜像全量推公网。
实际落地时建议用基础设施即代码管理云侧扩容。例如用Terraform起一批2核4G实例，user_data里写安装命令，启动后自动注册。下线时销毁实例即可，Agent离线不会丢失任务，会重新排队给存活节点。
2.1 队列与标签规划
合理的标签能精细控制分发。除queue外，可加os=linux、gpu=true等元标签。云上Windows构建机打win标签，本地Mac机打mac标签，pipeline按需要筛选。这样混合云不仅是地点混合，也是异构资源池混合。
下表给出常见队列划分方式：
| 队列名 | 位置 | 用途 | 伸缩方式 |
|---|---|---|---|
| default | 本地机房 | 日常提交构建 | 固定数量 |
| cloud-burst | 公有云 | 发版周峰值 | 自动扩缩 |
| secure | 本地隔离网 | 含密钥的集成测试 | 手动启停 |
三、实战：云服务器扩容Agent步骤
以通用Linux云主机为例，先生成Buildkite Token，写入启动配置。Agent二进制提供官方apt源，安装后编辑buildkite-agent.cfg，设定token、name与tags。关键行是tags="queue=cloud-burst,os=linux"，重启服务即上线。
为免手工操作，可把上述写进云镜像或启动模板。配合监控队列等待数，当等待超阈值就用云API加实例。某团队在每日三次集成高峰前定时扩十台，跑完缩容，月度云费增加不到原CISaaS套餐四分之一，而平均排队时间从九分钟降到四十秒。
3.1 安全与合规注意点
云Agent可能临时接触源码，务必用临时凭证且构建完清盘。建议云盘启用加密，实例角色最小化授权。若行业要求代码不出境，则云资源须选同地域节点，并通过私有链接连Buildkite，而非走公网API。
另外，Agent日志默认回传Buildkite云端，若含敏感输出，应在cfg关闭或重定向到内网存储。自托管优势正在于此：哪些数据出网完全由配置决定。
四、成本与稳定性权衡
混合云不是简单堆云机器。本地Agent利用率低时，说明常备过多；云Agent频繁冷启，说明阈值不合理。可用周报看空闲率，逐步调基准。稳定性上，云厂商偶发故障会让cloud队列消失，流水线应设重试与回退本地，防止单点中断。
经验上，把百分之三十构建量放在云弹性层，其余留本地，是较稳起点。后续按业务节奏微调，自托管CI的混合云便既省钱又抗峰。
混合云自托管CI的价值，不在技术炫酷，而在把合适任务放合适地方。
云服务器 Buildkite_Agent 混合云部署修改时间：2026-08-10 23:54:32