轻量级CI/CD工具Arbess：用YAML定义工作流，替代笨重Jenkins

1. 先聊聊 Jenkins 为什么让人觉得“重”“Jenkins 太重了”——这句话几乎每隔一段时间就会在团队里出现一次。作为一个用了多年 Jenkins 的人我太懂这种感受了。刚开始用的时候它的插件生态确实香几乎什么都能干但用着用着你就会发现它在慢慢拖垮你的运维体验。首先是资源占用。我自己遇到过最夸张的一次一个只有三个节点的 Jenkins 集群光是 Master 和 Agent 的常驻内存就吃掉了将近 8G。对于小型团队或者个人开发者来说为跑一个构建任务专门养一台高配服务器真的很不划算。其次是配置复杂度。Jenkins 的插件之间经常互相冲突升级一个插件可能连带崩掉三四个其他插件每次排查依赖问题都要花掉大半天时间。再有就是那套 Groovy 脚本和系统配置逻辑学习曲线陡得让不少新手直接放弃。当然Jenkins 本身没有错它是一款非常强大的工具只是在“轻量、快速、够用”这三个词面前确实显得有些笨重了。于是我开始寻找替代方案市面上轻量级的 CI/CD 工具其实不少但要么是商业产品有使用限制要么是配置方式不够直观用起来总像隔着一层东西。直到我接触到 Arbess体感才真正舒服起来。它是一个开源项目主打超轻量级 CI/CD部署方式非常简单一条 Docker 命令就能跑起来资源占用低得惊人配置方式走的是 YAML 定义加 Web 可视化的路线。用了一阵子后我把手里几个个人项目和一个小团队的自动构建任务全部从 Jenkins 迁了过来整个过程只花了不到半天。这篇文章就把我实际使用 Arbess 的完整过程、踩过的坑和配置心得整理出来给那些觉得 Jenkins 过于笨重、想找一个轻量替代方案的读者做一个参考。2. Arbess 的核心思路把 CI/CD 回归到“定义即执行”2.1 一套极简的模型用过 Jenkins 的人都知道它的核心概念包括 Master、Slave、Node、Job、Build、Pipeline、View、Folder每个概念背后还有一堆配置项。刚接触时很容易迷失在概念里。Arbess 把这套模型大幅精简了。它的核心概念主要有三个项目、工作流、任务。项目对应一个具体的代码仓库或一个独立的产品模块可以绑定 Git 仓库地址、分支、Webhook 等。工作流相当于一次完整的 CI/CD 流程定义用 YAML 文件描述。工作流里编排了具体要执行哪些步骤。任务工作流里的单个执行步骤比如拉取代码、执行测试、构建镜像、部署到服务器。这三个概念基本覆盖了日常大部分场景。没有 Master/Slave 的复杂关系没有插件安装和插件配置没有视图和文件夹管理。你只需要关心“我要在哪个项目下做什么事情”其他的一切都简化为 YAML 编排。对很多团队来说CI/CD 的核心需求其实就几件事代码提交后自动拉取、自动测试、自动构建、自动发布通知。Arbess 恰好把这几件事做到了极致简洁。2.2 为什么“定义即执行”比界面配置更高效Jenkins 的经典操作方式是在网页表单里填参数、选插件、配触发器。刚开始觉得可视化很友好但用得越多越觉得难受。一次稍微复杂一点的流程配置界面里要来回切换十几个页面参数散落在各个地方出了问题很难快速定位。Arbess 采用的是代码化定义。整个工作流直接写在一个 YAML 文件里描述清晰、可追踪、可版本管理。这意味着你可以把 CI/CD 配置当作项目代码的一部分走 Git 版本控制换机器、换环境时直接一键同步配置不用再一台台重新搭建 Jenkins 环境。有人会觉得写 YAML 是不是有学习成本。其实完全不用担心Arbess 的 YAML 语法设计得很收敛字段不多嵌套层级也浅基本看一眼示例就能上手。而且它还支持在界面里直接编辑和保存工作流不用专门去记命令。2.3 轻量化的技术底层Arbess 之所以能做到这么轻一个重要原因是它不需要像 Jenkins 那样维护一个庞大的插件系统。Jenkins 的插件架构很成熟但也很重每个插件都会引入额外的依赖和运行时开销。Arbess 把常用的 CI/CD 能力内置在引擎里比如 Git 拉取、Shell 执行、Docker 构建、HTTP 请求等按需调用。它的架构本身也更干净。整个服务可以作为一个单独的容器运行数据存在本地数据卷里没有额外依赖外部数据库。相对 Jenkins 的 Master/Agent 架构它的部署和维护成本都低了一个量级。3. 从零部署 Arbess实际安装与基本配置3.1 环境准备我先说一下我部署时用的环境方便大家参考一台 Linux 服务器2C2G 配置系统为 Ubuntu 22.04已安装 Docker 和 Docker Compose已安装 Git版本 2.34 以上这里要特别说明2G 内存对于 Jenkins 来说非常勉强但对于 Arbess 来说非常宽裕。我实测下来Arbess 服务整个运行占用内存大约在 200-300MB 之间波动这个体量在同类工具里确实算轻的。如果用 Docker 部署建议先确保 Docker 版本不要太老我使用时的 Docker 版本为 24.x兼容性没问题。3.2 部署步骤Arbess 的部署流程简短到让人有点意外核心就两步创建数据目录然后启动容器。# 1. 创建数据目录用于持久化配置与任务记录 mkdir -p /opt/arbess/data # 2. 启动容器 docker run -d \ --name arbess \ -p 8080:8080 \ -v /opt/arbess/data:/data \ -e ARBESS_WORKSPACE/data/workspace \ -e ARBESS_REPO/data/repos \ --restartalways \ arbess/arbess-server:latest启动成功后在浏览器里访问http://服务器IP:8080就能看到初始化页面。首次登录需要创建一个管理员账号创建完成后就进入系统主界面了。这里有个小提示容器内的默认端口是 8080如果你本机的 8080 端口已经被其他服务占用可以映射到别的端口比如-p 18080:8080。我第一次部署时就没注意结果跟已有的服务冲突了排查了一会儿才反应过来。3.3 配置 Git 仓库与首个项目进入主界面后第一步是创建一个项目。项目类型建议先选择“Git 仓库”然后填写仓库地址、分支、访问凭据。访问凭据支持两种方式用户名加密码适合内部 Git 服务比如 GitLab、Gitea。SSH 密钥适合需要通过 SSH 协议访问的仓库。如果你用 SSH 密钥方式需要在 Arbess 里填写私钥内容建议生成一个专门的部署密钥不要用个人账号的私钥。我一开始嫌麻烦直接用了个人私钥结果后续轮换密钥时非常痛苦所有项目都要一起改。创建好项目后在项目详情页里能看到一个 Webhook 地址。把这个地址填到你的 Git 仓库对应项目的 Webhook 配置里这样代码推送时就能自动触发工作流。3.4 核心目录与持久化说明Arbess 的数据存储在挂载的数据卷里这里面有几个关键子目录repos存放代码仓库的克隆数据workspace每个工作流执行时生成的工作目录与日志这两个目录很重要。如果你打算经常清服务器空间千万不要直接删repos目录否则所有项目的仓库缓存都会失效下次触发会重新执行完整克隆速度慢很多。我当时不小心清过一次结果所有项目第一次构建都特别慢还以为是网络问题。4. 实操核心环节编写工作流并完成一次自动构建4.1 理解工作流的基本语法先来看一个最基础的工作流 YAML 示例name: build-and-deploy on: push: branches: - main jobs: build: runs-on: ubuntu steps: - name: 拉取代码 uses: git-checkout with: repo: https://github.com/example/demo.git branch: main - name: 安装依赖 run: npm install - name: 执行测试 run: npm run test - name: 构建镜像 uses: docker-build with: context: . dockerfile: Dockerfile image: myregistry.example.com/demo:${GIT_COMMIT_SHORT} push: true这段配置描述了一个常见流程当main分支收到 push 事件时依次执行拉取代码、安装依赖、测试、构建镜像并推送。4.2 理解触发器与变量Arbess 的触发器支持几种常见类型push 触发代码推送时触发定时触发按照 cron 表达式定时执行手动触发通过界面上点击按钮执行我用得最多的是 push 触发和手动触发。定时触发适合做每日构建或者定时跑一些巡检脚本也很方便。变量方面Arbess 内置了几个很有用的环境变量GIT_COMMIT完整的提交哈希GIT_COMMIT_SHORT短哈希适合用来做镜像标签GIT_BRANCH当前分支名ARBESS_PROJECT_NAME当前项目名ARBESS_WORKSPACE当前工作区路径用这些变量可以拼接出很多有用的信息比如构建产物的版本号、发布消息的文案等。4.3 完整实操一个 Node.js 项目的自动构建与部署下面我用一个真实场景完整走一遍。假设我有一个 Node.js 项目代码托管在内部 Git 服务器上每次 push 到main分支时需要自动执行安装依赖、跑测试、构建 Docker 镜像然后部署到内网服务器。首先我在 Arbess 里创建了一个项目名为node-demo关联仓库地址和 SSH 凭据。接着我编写了如下工作流 YAMLname: auto-deploy on: push: branches: - main jobs: build-and-deploy: runs-on: ubuntu steps: - name: 拉取代码 uses: git-checkout with: repo: gitgit.internal.example.com:dev/node-demo.git branch: main - name: 安装依赖 run: npm ci - name: 执行单元测试 run: npm run test - name: 构建产物 run: npm run build - name: 构建并推送镜像 uses: docker-build with: context: . dockerfile: Dockerfile image: registry.internal.example.com/node-demo:${GIT_COMMIT_SHORT} push: true - name: 部署到测试环境 uses: ssh-command with: host: 10.0.0.5 user: deployer port: 22 private_key: | -----BEGIN OPENSSH PRIVATE KEY----- ... -----END OPENSSH PRIVATE KEY----- command: | docker pull registry.internal.example.com/node-demo:${GIT_COMMIT_SHORT} docker stop node-demo || true docker rm node-demo || true docker run -d --name node-demo -p 3000:3000 \ registry.internal.example.com/node-demo:${GIT_COMMIT_SHORT}这段配置里有几个地方值得展开讲一讲。npm ci vs npm install在 CI 环境里我强烈建议用npm ci它严格按照package-lock.json安装依赖速度快且结果可复现。用npm install在某些情况下会更新锁文件导致每次构建结果不一致。镜像标签使用短哈希用${GIT_COMMIT_SHORT}做镜像标签可以保证每个提交对应唯一的镜像方便回滚。在部署命令里引用同一个变量确保部署的镜像和构建的镜像一致。一开始我图省事用latest标签结果有次构建失败后部署进程拉到了上一个旧镜像界面展示的还是成功排查了很久才意识到是标签问题。部署方式选择这里我通过ssh-command这个内置任务在目标服务器上执行部署命令。这是最通用也最直观的方式适合没有用 K8s 的团队。如果你的环境已经上了 K8s可以换成kubectl-apply任务逻辑也类似。4.4 执行记录与日志排查工作流触发后Arbess 界面里可以实时看到每个步骤的状态。绿色表示成功红色表示失败黄色表示执行中。点击每个步骤可以展开查看对应的完整控制台日志。这一点我特别想夸一下Arbess 的日志查看体验比 Jenkins 清爽很多。Jenkins 的日志页面有时候会因为插件输出格式问题变得难以阅读而 Arbess 直接把日志按步骤分隔开每个步骤单独一个输出流干净利落排查问题非常方便。如果某个步骤失败了可以直接在日志里看到退出码和错误信息不像 Jenkins 还得手动去翻控制台输出。5. 常见问题与排查技巧实录5.1 常见问题速查表我把自己使用 Arbess 过程中遇到的几个典型问题和解决办法整理成了下面的速查表问题现象可能原因解决办法Webhook 触发不生效Git 仓库地址配置错误或网络不通检查 Webhook 地址是否能从 Git 服务器访问用 curl 测试拉取代码非常慢缺少 repo 缓存或仓库体积过大检查 repos 目录是否被清除尝试浅克隆优化Docker 构建失败镜像仓库需要登录在项目中配置 registry 凭据或使用 docker-login 任务工作流 YAML 语法错误缩进错误或字段拼写错误先到界面里的 YAML 校验器检查再保存运行SSH 部署失败目标服务器密钥不匹配或端口不通本地手动测试 ssh 命令确认密钥和端口正常定时任务没执行cron 表达式格式错误确认服务器时区避免本地时间与 UTC 混淆执行时间不符合预期分支过滤器配置错误检查 on.push.branches 是否覆盖了提交分支5.2 第一次踩坑Webhook 不触发的排查过程我迁移项目时遇到的第一个坑就是 Webhook 不触发。项目建好了工作流写好了手动执行没问题但 push 代码后就是不自动跑。排查思路是这样的先确认 Webhook 地址是否正确。在 Git 仓库的 Webhook 配置页面里对比填写的地址和 Arbess 项目详情页里的地址发现地址没问题。然后确认网络连通性。在 Git 服务器上直接 curl Webhook 地址返回 200。接着确认事件类型。发现我在 Git 仓库的 Webhook 里只勾选了 push 事件但 Arbess 这边还需要设置对应的过滤条件否则就算收到了事件请求也不会触发。最终问题定位在分支过滤上。我提交的分支名字是master而不是我预期中的main。因为很多代码仓库新建时的默认分支还是master而 YAML 里写的是main事件收到了但被过滤掉了。这种“看起来一切正常却不工作”的情况最迷惑人。建议在排查时优先检查分支名称和过滤器配置这是最容易忽略的地方。5.3 关于密钥管理的经验教训还有一个教训想分享给大家就是密钥管理。Arbess 支持在项目配置里存储 Git 仓库访问凭据、镜像仓库登录信息、SSH 私钥等敏感信息。这些信息不建议直接写在工作流 YAML 的明文里最好用内置的密钥变量功能。实际操作中我把 SSH 私钥存在项目的“凭据”区域在 YAML 里通过${SECRET_SSH_KEY}引用这样整个工作流文件里不会出现任何密钥明文即使不小心把 YAML 文件提交到公共仓库也不会泄露敏感信息。5.4 资源占用优化心得虽然 Arbess 很轻但长时间运行后工作区会产生大量历史构建文件。建议定期清理不需要的历史执行记录并且可以设置一个定时任务来清理工作目录。我自己的习惯是每两周清理一次workspace下的旧目录只保留最近十次执行记录。这样既保留了可追溯的日志又不会让磁盘空间持续膨胀。6. 实践后的选型思考哪些场景适合把 Jenkins 换成 Arbess6.1 最适合 Arbess 的场景从我实际使用的体感来看以下几类场景非常适合 Arbess个人开发者或小团队手上维护几个小型项目不想为了 CI/CD 养一套复杂基础设施。内部工具类项目没有太多外部用户压力自动构建和部署流程简单直接。初创团队没有专职 DevOps 岗位开发人员顺手就能维护出可用流程。已有 Jenkins 但维护成本过高项目数量不多却要花大量时间维护 Master/Agent、插件升级用 Arbess 可以大幅减轻负担。在这些场景里Arbess 够用、简单、直接并且不需要专门的学习成本。6.2 仍建议保留 Jenkins 的场景当然并不是说所有的 Jenkins 都应该被替换掉。以下几种情况Jenkins 仍然有其不可替代的优势大规模复杂流水线需要非常复杂的条件分支、多 stage 并行、动态参数化构建或者重度依赖某些专有插件。已有庞大的插件生态依赖某些老旧项目依赖 Jenkins 独有插件完成特殊需求短期内迁移成本非常高。企业级权限管理和审计需求Jenkins 在权限模型和审计方面的成熟度经过多年打磨比 Arbess 现阶段更完善。如果你的团队属于这些情况那继续使用 Jenkins 是合理的选择没有必要为了轻量而牺牲必要的功能。6.3 我的实际迁移策略我自己采用的方式是“先摸底再迁移后并行”。先梳理现有 Jenkins 上的任务类型区分哪些是核心、哪些是边缘。然后将边缘项目或者个人项目陆续迁到 Arbess 上跑一段时间确认稳定后再逐步扩大范围。在这个过程中Jenkins 和 Arbess 并行运行互不冲突。这种做法最大的好处是风险可控。万一 Arbess 某个功能不满足需求随时可以回退到 Jenkins对业务没有任何影响。迁移完成之后再关停闲置的 Jenkins 实例物理资源立刻释放。7. 最后分享几个实用小技巧7.1 用 Shallow Clone 加速大仓库拉取如果项目仓库比较大提交历史又很长每次拉全量代码会特别耗时。可以在 git-checkout 任务里加一个参数- name: 拉取代码 uses: git-checkout with: repo: gitgit.internal.example.com:dev/node-demo.git branch: main depth: 1depth: 1表示只拉取最近的一次提交对于不需要历史信息的 CI 场景来说特点是速度快、占用磁盘少。需要注意的是如果工作流里后续有操作依赖完整 Git 历史比如自动生成变更日志那么就不能用浅克隆。7.2 利用环境变量注入版本信息我习惯在构建步骤里把版本信息写入一个文件用来在应用启动时打印版本号。- name: 写入版本信息 run: | echo version${GIT_COMMIT_SHORT} build-info.txt echo branch${GIT_BRANCH} build-info.txt echo build_time$(date %Y-%m-%d %H:%M:%S) build-info.txt这样在后续排查问题时可以直接通过应用日志看到当前部署的是哪个 commit、什么时间构建的非常实用。我在服务端排查问题时靠这个办法省下了不少时间。7.3 分组管理多个项目如果一个项目下有多个子项目建议在 Arbess 里用“分组”功能来做一级归类。比如前端组、后端组、工具组这样在界面上管理起来更清晰。虽然 Arbess 的界面本身就很简洁但项目数量超过二十个后分组还是能显著提升查找效率。7.4 监控构建状态Arbess 没有自带非常强的监控告警体系但可以通过内置的通知任务把构建结果发送到企业微信、钉钉或 Slack。我早期的做法是每次构建失败时发一条站内信然后手动去查后来直接配置了 Webhook 通知失败时自动发消息到团队群里响应速度快了不少。在 YAML 里加一个通知步骤即可实现- name: 发送通知 uses: webhook-request with: url: https://hook.example.com/wechat method: POST body: | { project: ${ARBESS_PROJECT_NAME}, status: ${last_job_status}, commit: ${GIT_COMMIT_SHORT}, branch: ${GIT_BRANCH} }这样团队里所有人都能第一时间知道构建是否通过无需登录 Arbess 查看。用 Arbess 替换掉重度 Jenkins 之后我的个人体验非常明显维护时间少了构建速度并没有因为工具变轻而变慢反而因为链路简单整体反应更快。如果你也在为 Jenkins 的资源占用和维护成本犯愁不妨在非核心项目上用 Arbess 试试看部署一次只需要几分钟感受一下再决定要不要全量切换。