GitLab Runner托管：离岸CI执行器VPS部署指南

在Ubuntu 22.04 VPS上安装GitLab Runner通过官方APT源：curl -L "https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.deb.sh" | bash，然后apt install gitlab-runner。安装过程自动创建gitlab-runner系统用户和服务。注册Runner连接到GitLab实例：gitlab-runner register，按提示输入GitLab实例URL（如https://gitlab.com或自建GitLab地址）、registration token（在项目或group的Settings加CI/CD加Runners获取）、Runner描述、tags（用于在管道中精确选择Runner）、executor类型。Executor类型决定任务如何执行：shell（直接在Runner主机运行，最简单但隔离弱）、docker（每个任务在独立容器运行，推荐生产使用）、docker-machine（动态扩缩容Docker主机）、kubernetes（在K8s集群创建Pod作为任务环境，最适合大规模部署）、ssh（在远程主机运行，适合特殊场景）。Anubiz Host的VPS默认支持Docker，推荐选择docker executor。配置文件位于/etc/gitlab-runner/config.toml，可以精细调整concurrent限制、cache配置、registry认证等参数。

Docker executor是Runner最常用的配置，提供环境隔离和复现性。每个CI job在指定的Docker镜像中运行，例如node:20、python:3.11、golang:1.21。镜像选择对构建速度影响很大：基于Alpine的精简镜像启动快，但某些原生扩展可能缺少依赖，建议使用Debian-slim变体。privileged模式让Runner可以运行Docker-in-Docker（DinD）构建Docker镜像，但安全风险较高，生产环境推荐使用Kaniko或BuildKit替代。Cache配置大幅提升构建速度：node_modules、Maven .m2、Gradle .gradle等依赖目录在job间复用避免重复下载。本地cache存储在Runner主机磁盘，跨Runner共享则需要S3兼容对象存储（MinIO自建或Anubiz Host的离岸对象存储）。distributed cache让多个Runner共享缓存，特别适合并行构建场景。docker image cleanup策略定期清理过时镜像避免磁盘耗尽：在config.toml设置cleanup_policy让Runner自动pull相同镜像时验证版本。Anubiz Host的高性能NVMe SSD让Docker layer的pull和构建明显更快，大幅缩短CI管道总时间。

单Runner的concurrent参数限制同时执行的job数，根据VPS规格调整：4核VPS建议2-4 concurrent，8核8 concurrent，16核16 concurrent。对于更大规模需求，部署多个Runner实例分担负载。Auto-scaling通过docker-machine executor实现按需创建临时虚拟机作为agent，但配置较复杂。Kubernetes executor是云原生时代的最佳实践：Runner作为K8s Pod部署，每个CI job创建独立Pod，资源按需分配，job完成Pod自动销毁。在Anubiz Host可以构建跨区域的GitLab Runner集群：冰岛节点运行主Runner和缓存，罗马尼亚和荷兰节点运行专用Runner（通过tags精确分配特定地区或特定项目的job）。隐私层面，自建Runner意味着所有源代码、构建artifact、环境变量都保留在您控制的VPS上，不会被GitLab.com共享Runner或第三方CI服务采集。Anubiz Host所有VPS默认拒绝日志保留请求和数据访问请求，冰岛节点位于受冰岛宪法保护的言论自由司法区，没有强制数据保留法律。罗马尼亚和荷兰节点对开源软件和企业IT友好。如果您的代码涉及加密货币、隐私工具、安全研究等敏感领域，离岸Runner可以避免主流CI平台的代码扫描和封号风险。加密货币支付确保账户身份匿名，是DevOps自由派的理想选择。