五月的时候,分享过如何使用私有CI来和GitHub联动,进行项目构建。
这两天抽空,再次优化了一番,性能提高不少,目前看来还不错。
简单一步获取高性能的代码高亮服务
早些时候使用 Docker 封装了一套经典的代码高亮服务,虽说相比 carbon
性能还是高许多,但是奈何在被高频远程调用时,跑单应用的情况下撑不住高频访问,经常出现 500
状态。
所以当时不得不在代码中进行分 chunk
进行远程接口调用,而且为了照顾访问时的性能损耗,还要将代码高亮和转换工具进行耦合,比如像下面一样进行服务组织。
version: '3.6'
services:
convert:
image: soulteary/hugo-post-adapter:1.0.0
depends_on:
- crayon
crayon:
image: nginx:1.13.11-alpine
links:
- php
php:
image: php:7.2.4-fpm-alpine
虽说在转换程序中通过编写出错重试,分段请求也能满足需求,但是转换效率极慢,需要好几分钟。
那么更好的方案是什么呢?
一个性能优秀的负载均衡方案,搭配支持动态扩展的应用。
在六月的时候,我介绍过之前使用过一阵的 Traefik
来做服务发现,它虽然性能比不上老牌软件 Nginx
,但是胜在易用,以及性能只是稍低一些。
version: '3'
services:
crayon:
restart: always
image: php:7.2.8-apache
expose:
- 80
volumes:
- ./source:/var/www/html
networks:
- traefik
labels:
- "traefik.enable=true"
- "traefik.port=80"
- "traefik.frontend.rule=Host:crayon.lab.com"
- "traefik.frontend.entryPoints=http,https"
networks:
traefik:
external: true
参考自己的机器资源的多寡,使用 docker-compose up --scale crayon=N
,支持高并发的服务瞬间唾手可得。
默认scale出来的节点,负载模式是wrr,基本等价 nginx 设置 upstream hash。
现在进行一次代码高亮 1分钟
之内就结束战斗,配合构建缓存,十秒内结束战斗。
去掉 dind 架构的容器运行方案
最早之前,有使用 dind
模式的容器方案进行 CI 构建:
在使用 Docker 运行的 CI 软件镜像中,继续启动其他的 Docker 容器,执行是没有问题,但是路径映射方面就会存在不少问题,以及涉及到私有证书、仓库认证等一堆小问题,实际调试起来比较麻烦,也浪费了宿主的性能,毕竟保证隔离性其实只要一层容器就可以了。
去掉 dind
后,我用了三套方案:
- Drone:容器
ssh
联动宿主,执行宿主中可以执行的脚本,执行docker
、docker-compose
等命令。 - GitLab:容器中使用
shell
模式的runner
,调用runner
环境的docker
命令。 - GitLab:容器中使用
docker
模式的runner
,结果贮存。
第一个方案风险最高,因为能够直接访问到宿主环境,而且感觉没必要使用 compose 来完成任务,尽可能把每一步拆分为无状态的单一职责任务才是容器在可维护的 CI 任务中应该做的事情。
第三个方案是常规方案,也是多数使用 GitLab Runner 的默认方案,足够多数项目使用了。
重点聊聊第二个方案,这个方案虽然不是官方最推崇的 dind 模式,但是其实却是可维护性最高,性能最高的方案,使用下面的命令可以瞬间启动一个支持私有证书,适合各种场景使用的 Runner :
sudo gitlab-runner register -n \
--url https://gitlab.lab.com/ \
--registration-token YOUR_CI_TOKEN \
--tls-ca-file=/lab.com.crt \
--executor shell \
--description "Shell Runner"
使用第二个或者第三个方案,一来配置简单;二来完全不会影响到 Runner 环境中的宿主 Docker Daemon
执行模式;三来许多在 GitLab CI 描述文件中进行配置的路径问题可以使用 docker run
命令动态解决了,比如下面的例子:
# 转换文档
convert:
image: docker:stable
stage: prepare-source
before_script:
- ls -m
script:
- mkdir -p $CONVERT_CACHE_DIR && ls $CONVERT_CACHE_DIR
- docker run
--volume $SOURCE_DIR/:/My-Blog-Posts/
--volume $CONVERT_CACHE_DIR:/app/cache
"docker.lab.com/hugo-post-adapter:1.0.0-convert" yarn start
可以动态挂载任何目录,而不用很难受的来回复制文件到指定目录。
在废弃了第一个过度方案之后,执行效率高了不少,原本整体构建一次即使不包含代码高亮也得好几分钟,现在一分钟以内连部署都结束了,而且整套设计安全了许多。
那么这个模式有没有缺点呢?
没有银弹。
除了执行容器的残留需要手动清理(不建议在CI过程中添加 –rm 参数,破坏现场不利于之后出现问题调试),如果是团队使用,还是建议准备多台专属 runner ,避免执行任务时资源争抢打架。
但是不论是现在来看,还是未来,虚拟机这种级别的云主机资源、内网虚拟机资源还是事么?
其他
最后,记录一下网站单容器运行 Traefik
两个多月的性能数据,心里长草的同学值得试试。
Total Response Time 14 hours
Total Code Count 710648
Uptime Since 2018-06-14 12:56:09 +08:00
2 months
Average Response Time 72 ms
–EOF