基于Jenkins & Docker 的 CI/CD 优化 - 哈喽比特

918次阅读 | 发布于4年以前

此次优化的原因在于作为一家服务 Global 用户的公司，在多个 region 部署了服务，而目前阿里云容器服务针对有海外部署需要的公司，有几个待改进之处：

构建速度，海外构建需要在海外构建后将镜像推回国内
香港可用区没有提供镜像仓库

针对上述问题，我们优化从两个方面下手：

搭建镜像仓库
自主搭建构建集群
构建集群的缓存优化

一、镜像仓库

镜像仓库这里，为了兼容旧项目，我们搭建两个仓库，一个是阿里云镜像仓库杭州区的Mirror，另一个是内部访问的私有仓库，不对外编排文件：

registry-push:
    restart: always
    image: "registry:2.6"
    ports:
        - 5050:5000
    environment:
        - REGISTRY_STORAGE=oss
        - REGISTRY_STORAGE_OSS_ACCESSKEYID={ak}
        - REGISTRY_STORAGE_OSS_ACCESSKEYSECRET={sk}
        - REGISTRY_STORAGE_OSS_REGION=oss-cn-hongkong
        - REGISTRY_STORAGE_OSS_BUCKET={hk_bucket}
        - REGISTRY_STORAGE_OSS_INTERNAL=true
        - REGISTRY_STORAGE_OSS_SECURE=false

registry:
  restart: always
  image: "registry:2.6"
  environment:
    - REGISTRY_STORAGE=oss
    - REGISTRY_STORAGE_OSS_ACCESSKEYID={ak}
    - REGISTRY_STORAGE_OSS_ACCESSKEYSECRET={sk}
    - REGISTRY_STORAGE_OSS_REGION=oss-cn-hongkong
    - REGISTRY_STORAGE_OSS_BUCKET={hk_bucket}
    - REGISTRY_STORAGE_OSS_INTERNAL=true
    - REGISTRY_STORAGE_OSS_SECURE=false
    - REGISTRY_PROXY_REMOTEURL=https://registry.cn-hangzhou.aliyuncs.com
    - REGISTRY_PROXY_USERNAME={username}
    - REGISTRY_PROXY_PASSWORD={password}

nginx:
  image: "nginx:1.9"
  ports:
    - 443:443
  links:
    - registry:registry
  volumes:
    - ./auth:/etc/nginx/conf.d
    - ./auth/nginx.conf:/etc/nginx/nginx.conf:ro

目录结构：

.
├── auth
│   ├── insta360.com.chained.crt
│   ├── insta360.com.key
│   ├── nginx.conf
│   └── nginx.htpasswd
└── docker-compose.yml

1 directory, 5 files

这样一个镜像仓库的Mirror就搭建好了，oss的bucket里有的镜像，从本地拉取，没有的，则从杭州区拉取，并存储到香港，加速二次使用的速度，对于集群部署，这样已经可以加速上线的过程了。而Push的那个仓库呢，主要是给我们自己用的，务必记得iptables设置规则，仅允许本机访问，他是我们用来推本地构建的镜像用的这样呢，这个仓库，既能访问到杭州的镜像，又能访问到我们自己的镜像。

二、Jenkins 以及缓存加速

这里我们直接用阿里云提供的编码模板稍作修改：

version: '2'
services:
    slave-java:
        image: registry.aliyuncs.com/acs-sample/jenkins-slave-dind-java
        volumes:
            - /var/run/docker.sock:/var/run/docker.sock
            - ./data/slave_java/.m2:/home/jenkins/.m2/
            - ./conf/insta360_maven_settings.xml:/usr/share/maven/conf/settings.xml:ro
        restart: always

    slave-nodejs:
        image: registry.aliyuncs.com/acs-sample/jenkins-slave-dind-nodejs
        volumes:
            - /var/run/docker.sock:/var/run/docker.sock
            - ./data/slave_nodejs/.npm:/home/jenkins/.npm/
        restart: always

    app:
        image: jenkins:2.46.2-alpine
        volumes:
          - ./data/jenkins_home:/var/jenkins_home
        ports:
            - 8080:8080
            # - 50000:50000
        privileged: true
        restart: always
        depends_on:
            - slave-nodejs
            - slave-java

目录结构如下：

.
├── conf
│   └── insta360_maven_settings.xml
├── data
│   ├── jenkins_home
│   ├── slave
│   └── slave_nodejs
└── docker-compose.yml

5 directories, 2 files

注意配置里的几个变化：

slave-java，挂载了一个私有的mavan的配置文件，有需要的记得加在这里，同时呢，我们把/home/jenkins/.m2/挂载了，这样重启应用不会删除已经下载的pkg
slave-nodejs，同样挂载了/home/jenkins/.npm/目录，效果一样，是为了缓存node的包
slave没有暴露端口，仅内部访问

三、Jenkins 使用

这里的配置访问我们就不废话了，可以参考这里：

使用阿里云容器服务 Jenkins 2.0 实现持续集成之 the tag you want 篇

看看以前的构建时间：

再看看现在的时间，包过了构建时间+部署时间

这里注意一下，阿里云的 Jenkins 插件在提交部署后，有一个一分钟的等待时间（轮训去查看是否更新完毕），实际上呢，几次测试，整个时间是在20s左右，基本在一分钟完成，容器服务更新应用是滚动更新，不会一次更新所有的应用实例，从而保证不停机，自然的，也就带来了一定的延时。

下次出了bug，一分钟就可以搞定线上的修复，想想也是很开心吧！

来源：https://zhuanlan.zhihu.com/p/27147870