本文使用「署名 4.0 国际 (CC BY 4.0)」许可协议，欢迎转载、或重新修改使用，但需要注明来源。 [署名 4.0 国际 (CC BY 4.0)](https://creativecommons.org/licenses/by/4.0/deed.zh)

本文作者: 苏洋

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

-----


# 再次折腾构建服务

五月的时候，分享过如何[使用私有CI来和GitHub联动](https://soulteary.com/2018/05/25/professional-thinking.html)，进行项目构建。

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

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

早些时候使用 Docker 封装了一套经典的[代码高亮服务](https://github.com/soulteary/crayon-syntax-highlight)，虽说相比 `carbon` 性能还是高许多，但是奈何在被高频远程调用时，跑单应用的情况下撑不住高频访问，经常出现 `500` 状态。

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

```yml
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` 来做[服务发现](https://soulteary.com/2018/06/11/use-server-side-discovery-improve-development.html)，它虽然性能比不上老牌软件 `Nginx` ，但是胜在易用，以及性能只是稍低一些。

```yaml
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 ：

```bash
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` 命令动态解决了，比如下面的例子：

```yaml
# 转换文档
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` 两个多月的性能数据，心里长草的同学值得试试。

```bash
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