这个需求是我在使用自建Gitea并将其作为半公共性质的服务对外开放时产生的。

Docker 部署 Gitea Runner

自己部署act-runner有诸多好处，例如没有平台托管限时费用，没有并发数量限制（性能够想开多少就开多少），没有网络限制（某些生产环境只能在内网进行构建和部署）

我们可以参考Gitea Actions的那部分，自己部署一个act-runner连接到我们的Gitea实例。仅需几步，5分钟内就能部署好。

常规模式下的runner有以下潜在的风险

  • 宿主机docker.sock访问权限，这意味着runner可以直接控制宿主机的docker守护进程，你可以使用Docker in Docker(dind)的runner镜像来避免这个问题

  • 网络权限，正常情况下runner可以访问当前网络中的所有内容，用户可以通过网络这关来入侵当前的内部网络。且你不能完全阻止runner联网，因为它不仅要与其他task容器/Gitea实例通信，还要从互联网拉取一些actions仓库。配置网络规则将会是成本非常高的一个解决方案。在某些情况下，我们可以选择将其部署在一个单独网络中，它只有访问Gitea实例和互联网的权限，但是我这边架构比较负责，action通常也会和内网其他服务进行网络通信，所以不太适合我。

gitea官方的runner，一个runner仅支持给全局，单个主人（用户或组织），单个仓库配置，配置后相应范围下的仓库就可以使用这些runner，runner中可以执行任意代码，权限非常高。也许你会想到：只要不配置全局的runner就好了，但是这样当权限主体多了后，你要创建很多个runner容器来满足这个需求，管理起来自然就很麻烦。

在此特别感谢我们的赞助商 007IDC，贵司赞助的服务器承担了一部分公共runner的运行基石

安装liteyuki runner

轻雪工作室自己维护了一个分发：liteyuki-runner(gitea runner liteyuki-distro)，它相比原版，新增了allowed_repos配置项，顾名思义就是仅允许白名单或者仅拒绝黑名单的仓库使用runner，并在runs-on中添加额外标签来区分不同runner。这样仅需要配置一个全局runner，然后通过配置允许的仓库来禁止公共用户使用私有网络中的runner，减少不必要的风险，让外部用户用公共网络环境的runner运行工作流。

Docker部署liteyuki runner

安装方式非常简单，直接照搬Gitea官方文档即可，但是需要把镜像换成liteyuki runner的

reg.liteyuki.icu/actions/liteyuki-runner:latest
# dind模式下需要启用特权容器
reg.liteyuki.icu/actions/liteyuki-runner:latest-dind
reg.liteyuki.icu/actions/liteyuki-runner:latest-dind-rootless

配置也非常简单

# 仅需要在原有的配置文件 runner项下添加一个allowed_repos: []string的配置项目
# 配置非常简单，owner/repo格式。*表示所有repo或者owner
runner:
    allowed_repos:
        - "org1/repo1"  # 仅允许org1/repo1使用
        - "org1/repo2"  # 仅允许org1/repo2使用
        - "org2/*"  # 仅允许org2下的所有repo使用
        - "user1/*" # 仅允许user1下的所有repo使用
    blacklist_mode: false # 是否启用黑名单模式，启用后为反向选择
    reject_text: "This repository {REPO} is not allowed to use this runner {RUNNER} to run workflows." # 禁止使用actions时的提示文本yaml

二进制部署

暂时不提供普通二进制部署方案，有需求者请自行编译使用