Buildbarn on Kubernetes:根据编译负载自动伸缩 Worker 的四种方案
把 Buildbarn 自身的负载指标,转化为 Kubernetes 的行动指令。
在 Kubernetes 上运行 Buildbarn 作为远端执行(Remote Execution)/ 远程缓存后端时,一个常见诉求是:根据 CI 编译任务的规模,动态调整 Worker 的数量,从而既扛得住编译高峰,又不在低谷期浪费资源。本文梳理了四种主流方案,并给出选型建议。
把 Buildbarn 自身的负载指标,转化为 Kubernetes 的行动指令。
在 Kubernetes 上运行 Buildbarn 作为远端执行(Remote Execution)/ 远程缓存后端时,一个常见诉求是:根据 CI 编译任务的规模,动态调整 Worker 的数量,从而既扛得住编译高峰,又不在低谷期浪费资源。本文梳理了四种主流方案,并给出选型建议。
在云原生和 AI 训练场景里,对象存储几乎是基础设施的"水电煤"——从镜像分发、模型权重到训练数据集,都离不开一个兼容 S3 协议、又能扛住高吞吐的存储服务。MinIO 一直是这个领域的明星,但如果你想要一个用 Rust 重写、内存占用更低、启动更快、原生支持多盘纠删码的替代品,RustFS 是一个值得重点关注的新选择。
本文基于一份可直接落地的 docker-compose.yml,完整演示 RustFS 单节点 4 盘部署:从快速启动、访问验证,到存储持久化、配置项解读、S3 客户端对接,再到生产环境加固,一次讲清楚。
在前两篇 bazel-remote 系列文章里,我们对比了 S3 后端与一致性哈希两种横向扩展方案,也给出过"分层缓存(L1 + L2)是最佳实践"的结论。但那个结论停留在架构层面——具体怎么配?数据到底怎么流动?性能如何保障?
本文就把这个"最佳实践"落到地面:剖析 bazel-remote 原生两级存储的工作原理,并给出可直接套用的命令行与 YAML 配置。
在上一篇《bazel-remote 多实例部署:两种横向扩展方案与性能对比》中,我们梳理了共享云存储与负载均衡+一致性哈希两种横向扩展思路。但留下了一个关键问题:当 S3 后端(这里用 RustFS)与 bazel-remote 部署在同一高速网络时,两种方案的延迟差距还大吗?
本文就聚焦这个真实场景,给出量化的延迟对比与选型建议。
在开源代码托管平台的选择上,Gitea 凭借轻量、易部署的特性,一直是很多开发团队的首选。但近两年来,Forgejo 的出现和崛起,给这个领域带来了新的变量。
Gitea 和 Forgejo 到底是什么关系?它们的 CI/CD 能力有何差异?如何基于它们搭建现代化的 DevOps 流水线?又能否将 Kubernetes 作为 CI/CD 的执行环境?
这篇文章将基于我们团队的调研和实践,一次性讲清楚这些问题。
在 Jenkins 容器中使用 buildah push 推送镜像时,设置登录认证主要有三种方式。将凭证硬编码在命令里会带来严重的安全风险,因此在实际的 CI/CD 实践中,更推荐采用"登录 (Login) + 配置文件 (Authfile)“的方式。
你有没有遇到过这种情况——凌晨 3 点,用户在群里反馈服务挂了,而你这边一个告警都没有?Prometheus 的 Alertmanager 安静如鸡,因为"没有流量就没有错误"。等客户把电话打到老板那里,你才知道负载均衡器早就挂了。
Harbor默认是使用mysql数据库进行用户管理,那么我们需要修改Harbor的配置文件。
在harbor目录下,执行:
vi harbor.cfg
首先,把自己的IP地址(192.168.16.85)域名设置为: test.harbor.com:
http://gerrit.rockbox.org/r/Documentation/config-gerrit.html#addreviewer
https://blog.csdn.net/ujm7418529631/article/details/79226621
http://www.cnblogs.com/kevingrace/p/5651447.html



DevOps(Development和Operations的组合词)是一组过程、方法与系统的统称,用于促进开发(应用程序/软件工程)、技术运营和质量保障(QA)部门之间的沟通、协作与整合。