五月的时候,分享过如何使用私有CI来和GitHub联动,进行项目构建。

这两天抽空,再次优化了一番,性能提高不少,目前看来还不错。

简单一步获取高性能的代码高亮服务

早些时候使用 Docker 封装了一套经典的代码高亮服务,虽说相比 carbon 性能还是高许多,但是奈何在被高频远程调用时,跑单应用的情况下撑不住高频访问,经常出现 500 状态。

所以当时不得不在代码中进行分 chunk 进行远程接口调用,而且为了照顾访问时的性能损耗,还要将代码高亮和转换工具进行耦合,比如像下面一样进行服务组织。

虽说在转换程序中通过编写出错重试,分段请求也能满足需求,但是转换效率极慢,需要好几分钟。

那么更好的方案是什么呢?

一个性能优秀的负载均衡方案,搭配支持动态扩展的应用。

在六月的时候,我介绍过之前使用过一阵的 Traefik 来做服务发现,它虽然性能比不上老牌软件 Nginx ,但是胜在易用,以及性能只是稍低一些。

参考自己的机器资源的多寡,使用 docker-compose up --scale crayon=N ,支持高并发的服务瞬间唾手可得。

默认scale出来的节点,负载模式是wrr,基本等价 nginx 设置 upstream hash。

现在进行一次代码高亮 1分钟 之内就结束战斗,配合构建缓存,十秒内结束战斗。

去掉 dind 架构的容器运行方案

最早之前,有使用 dind 模式的容器方案进行 CI 构建:

在使用 Docker 运行的 CI 软件镜像中,继续启动其他的 Docker 容器,执行是没有问题,但是路径映射方面就会存在不少问题,以及涉及到私有证书、仓库认证等一堆小问题,实际调试起来比较麻烦,也浪费了宿主的性能,毕竟保证隔离性其实只要一层容器就可以了。

去掉 dind 后,我用了三套方案:

  1. Drone:容器 ssh 联动宿主,执行宿主中可以执行的脚本,执行 dockerdocker-compose 等命令。
  2. GitLab:容器中使用 shell 模式的 runner,调用 runner 环境的 docker 命令。
  3. GitLab:容器中使用 docker 模式的 runner,结果贮存。

第一个方案风险最高,因为能够直接访问到宿主环境,而且感觉没必要使用 compose 来完成任务,尽可能把每一步拆分为无状态的单一职责任务才是容器在可维护的 CI 任务中应该做的事情。

第三个方案是常规方案,也是多数使用 GitLab Runner 的默认方案,足够多数项目使用了。

重点聊聊第二个方案,这个方案虽然不是官方最推崇的 dind 模式,但是其实却是可维护性最高,性能最高的方案,使用下面的命令可以瞬间启动一个支持私有证书,适合各种场景使用的 Runner :

使用第二个或者第三个方案,一来配置简单;二来完全不会影响到 Runner 环境中的宿主 Docker Daemon 执行模式;三来许多在 GitLab CI 描述文件中进行配置的路径问题可以使用 docker run 命令动态解决了,比如下面的例子:

可以动态挂载任何目录,而不用很难受的来回复制文件到指定目录。

在废弃了第一个过度方案之后,执行效率高了不少,原本整体构建一次即使不包含代码高亮也得好几分钟,现在一分钟以内连部署都结束了,而且整套设计安全了许多。

那么这个模式有没有缺点呢?

没有银弹。

除了执行容器的残留需要手动清理(不建议在CI过程中添加 –rm 参数,破坏现场不利于之后出现问题调试),如果是团队使用,还是建议准备多台专属 runner ,避免执行任务时资源争抢打架。

但是不论是现在来看,还是未来,虚拟机这种级别的云主机资源、内网虚拟机资源还是事么?

其他

最后,记录一下网站单容器运行 Traefik 两个多月的性能数据,心里长草的同学值得试试。

–EOF