五月的时候，分享过如何使用私有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 后，我用了三套方案：

  1. Drone：容器 ssh 联动宿主，执行宿主中可以执行的脚本，执行 docker、docker-compose 等命令。
  2. GitLab：容器中使用 shell 模式的 runner，调用 runner 环境的 docker 命令。
  3. 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