再次折腾构建服务

本文使用「署名 4.0 国际 (CC BY 4.0)」许可协议，欢迎转载、或重新修改使用，但需要注明来源。 署名 4.0 国际 (CC BY 4.0)

本文作者: 苏洋

创建时间: 2018年08月17日 统计字数: 2775字 阅读时间: 6分钟阅读 本文链接: https://soulteary.com/2018/08/17/optimize-build-services-again.html

---

再次折腾构建服务

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

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

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

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

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

1. version: '3.6'
2.  
3. services:
4.  
5. convert:
6. image: soulteary/hugo-post-adapter:1.0.0
7. depends_on:
8. - crayon
9.  
10. crayon:
11. image: nginx:1.13.11-alpine
12. links:
13. - php
14. php:
15. image: php:7.2.4-fpm-alpine

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

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

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

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

1. version: '3'
2.  
3. services:
4.  
5. crayon:
6. restart: always
7. image: php:7.2.8-apache
8. expose:
9. - 80
10. volumes:
11. - ./source:/var/www/html
12. networks:
13. - traefik
14. labels:
15. - "traefik.enable=true"
16. - "traefik.port=80"
17. - "traefik.frontend.rule=Host:crayon.lab.com"
18. - "traefik.frontend.entryPoints=http,https"
19.  
20. networks:
21. traefik:
22. external: true

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

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

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

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

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

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

去掉 dind 后，我用了三套方案：

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

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

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

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

1. sudo gitlab-runner register -n \
2. --url https://gitlab.lab.com/ \
3. --registration-token YOUR_CI_TOKEN \
4. --tls-ca-file=/lab.com.crt \
5. --executor shell \
6. --description "Shell Runner"

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

1. # 转换文档
2. convert:
3. image: docker:stable
4. stage: prepare-source
5. before_script:
6. - ls -m
7. script:
8. - mkdir -p $CONVERT_CACHE_DIR && ls $CONVERT_CACHE_DIR
9. - docker run
10. --volume $SOURCE_DIR/:/My-Blog-Posts/
11. --volume $CONVERT_CACHE_DIR:/app/cache
12. "docker.lab.com/hugo-post-adapter:1.0.0-convert" yarn start

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

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

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

没有银弹。

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

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

其他

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

1. Total Response Time 14 hours
2. Total Code Count 710648
3. Uptime Since 2018-06-14 12:56:09 +08:00
4. 2 months
5. Average Response Time 72 ms

--EOF