前言
持续集成的好处主要有两个:
· 快速发现错误
每完成一点更新，就集成到主干，可以快速发现错误，定位错误也比较容易
· 防止分支大幅偏离主干
如果不是经常集成，主干又在不断更新，会导致以后集成的难度变大，甚至难以集成。持续集成的目的，就是让产品可以快速迭代，同时还能保持高质量。它的核心措施是，代码集成到主干之前，必须通过自动化测试。只要有一个测试用例失败，就不能集成。
一、环境准备
首先需要有一台 GitLab 服务器，然后需要有个项目；这里示例项目以 golang 项目为例，然后最好有一台专门用来 Build 的机器，实际生产中如果 Build 任务不频繁可适当用一些业务机器进行 Build；本文示例所有组件将采用 Docker 启动， GitLab HA 等不在本文阐述范围内
· Docker Version : 1.13.1
· GitLab Version : 10.1.4-ce.0
· GitLab Runner Version : 10.1.0
二、GitLab CI 简介
GitLab CI 是 GitLab 默认集成的 CI 功能，GitLab CI 通过在项目内 .gitlab-ci.yaml 配置文件读取 CI 任务并进行相应处理；GitLab CI 通过其称为 GitLab Runner 的 Agent 端进行 build 操作；Runner 本身可以使用多种方式安装，比如使用 Docker 镜像启动等；Runner 在进行 build 操作时也可以选择多种 build 环境提供者；比如直接在 Runner 所在宿主机 build、通过新创建虚拟机(vmware、virtualbox)进行 build等；同时 Runner 支持 Docker 作为 build 提供者，即每次 build 新启动容器进行 build；GitLab CI 其大致架构如下
Runner可以分布在不同的主机上，同一个主机上也可以有多个Runner。
三、搭建 GitLab 服务器
3.1、GitLab 搭建
已经有gitlab的同学，可以跳过。GitLab 搭建这里直接使用 docker compose 启动，compose 配置如下
version: '2'
services:
gitlab:
image: 'gitlab/gitlab-ce:10.1.4-ce.0'
restart: always
container_name: gitlab
hostname: 'gitlab.test'
environment:
GITLAB_OMNIBUS_CONFIG: |
external_url 'http:/gitlab.test'
# Add any other gitlab.rb configuration here, each on its own line
ports:
- '80:80'
- '443:443'
- '8022:22'
volumes:
- './data/gitlab/config:/etc/gitlab'
- './data/gitlab/logs:/var/log/gitlab'
- './data/gitlab/data:/var/opt/gitlab'
直接启动后，首次登默认用户为 root
登陆成功后创建一个用户(该用户最好给予 Admin 权限，以后操作以该用户为例)，并且创建一个测试 Group 和 Project.
3.2、增加示例项目
这里示例项目采用 Golang 的 Fingerprint 项目，并采用 go module 构建，其他语言原理一样；如果不熟悉 golang 的没必要死磕此步配置，任意语言整一个能用的项目就行，并不强求特定语言、框架构建，以下只是一个样例项目，如下所示：
最后将项目提交到 GitLab 后如下
四、GitLab CI 配置
针对这一章节创建基础镜像以及项目镜像，这里仅以 Go 项目为例；其他语言原理相同，按照其他语言对应的运行环境修改即可
4.1、增加 Runner
GitLab CI 在进行构建时会将任务下发给 Runner，让 Runner 去执行；所以先要添加一个 Runner，Runner 这里采用 Docker in docker 启动，build 方式也使用 Docker 方式 Build；命令如下：
#!/usr/bin/env bash
#清空挂载目录
rm -rf /srv/gitlab-runner/config/
#启动gitlab-runner
docker run -d --name gitlab-runner --restart always \
-v /srv/gitlab-runner/config:/etc/gitlab-runner \
-v /var/run/docker.sock:/var/run/docker.sock \
gitlab/gitlab-runner:latest
# 向gitlab server注册
docker run --rm -t -i -v /srv/gitlab-runner/config:/etc/gitlab-runner gitlab/gitlab-runner register \
--non-interactive \
--executor "docker" \
--docker-image alpine:stable \
--url "https://git.xxx.com.cn/" \ #请修改成实际地址
--registration-token "xxx" \ #请修改成实际token， 从gitlab设置里copy
--description "cms-runner" \
--tag-list "docker,cms,runner" \ #指定标签，类似k8s的label,后续selector会用得到
--run-untagged="true" \
--locked="false" \
--docker-privileged #开启特权模式
在执行上一条激活命令后，会按照提示让你输入一些信息；首先输入 GitLab 地址，然后是 Runner ，Runner Token 可以从 GitLab 设置中查看，如下所示
注册完成后，在 GitLab Runner 设置中就可以看到刚刚注册的 Runner，如下所示
注意，这里声明的 Volumes 会在每个运行的容器中都生效；也就是说 build 时新开启的每个容器都会被挂载这些目录；修改完成后重启 runner 容器即可。
4.2、创建项目镜像
针对于项目每次 build 都应该生成一个包含发布物的 docker 镜像，所以对于项目来说还需要一个项目本身的 Dockerfile；项目的 Dockerfile 有两种使用方式；一种是动态生成 Dockerfile，然后每次使用新生成的 Dockerfile 去 build；还有一种是写一个通用的 Dockerfile，build 时利用 ARG、onbuild、CMD 参数传入变量；这里采用第二种方式，以下为一个可以反复使用的 Dockerfile：
FROM registry.api.weibo.com/cms-auto/debian:stable
LABEL maintainer="sunsky303<sunsky303@qq.com>"
ARG TZ="Asia/Shanghai"
ENV TZ ${TZ}
VOLUME /data1/ms/log
#RUN yum -y update && yum clean all
ADD docker/debian_apt_source.list /etc/apt/sources.list
#RUN ["apt-get", "update"]
#RUN ["apt-get", "install", "-y", "vim"] #for debug
ENV WORKSPACE /data1/ms/FingerprintGo
#RUN ["mkdir","-p", "/data1/ms/FingerprintGo"]
WORKDIR /$WORKSPACE
#RUN rm -rf $WORKSPACE/* #clean
COPY ./fingerprint $WORKSPACE/fingerprint
COPY ./dict $WORKSPACE/dict
COPY ./config $WORKSPACE/config
RUN mkdir -p $WORKSPACE/_vgo
COPY example.env $WORKSPACE/.env
ENV GOPATH /data1/ms/FingerprintGo/_vgo #使用go module，它已经事先被push到git了
#RUN rm -rf $WORKSPACE/_vgo/* $WORKSPACE/benchmark
#RUN printf "mode=prod\nlog_dir=$WORKSPACE/" > .env
RUN sed -i 's/mode=test/mode=prod/' .env
EXPOSE 3334
CMD ["./fingerprint"]
4.3、创建 CI 配置文件
一切准备就绪以后，就可以编写 CI 文件了；GitLab 依靠读取项目根目录下的 .gitlab-ci.yml 文件来执行相应的 CI 操作
4.4 CI 配置的常用概念：
stagesstages 字段定义了整个 CI 一共有哪些阶段流程，以上的 CI 配置中，定义了该项目的 CI 总共分为 build、deploy 两个阶段；GitLab CI 会根据其顺序执行对应阶段下的所有任务；在正常生产环境流程可以定义很多个，比如可以有 test、publish，甚至可能有代码扫描的 sonar 阶段等；这些阶段没有任何限制，完全是自定义的，上面的阶段定义好后在 CI 中表现如下图
tasktask 隶属于stages 之下；也就是说一个阶段可以有多个任务，任务执行顺序默认不指定会并发执行；对于上面的 CI 配置来说 auto-build 和 deploy 都是 task，他们通过 stage: xxxx 这个标签来指定他们隶属于哪个 stage；当 Runner 使用 Docker 作为 build 提供者时，我们可以在 task 的 image 标签下声明该 task 要使用哪个镜像运行，不指定则默认为 Runner 注册时的镜像(这里是 debian)；同时 task 还有一个 tags 的标签，该标签指明了这个任务将可以在哪些 Runner 上运行；这个标签可以从 Runner 页面看到，实际上就是 Runner 注册时输入的那个 tag；对于某些特殊的项目，比如 IOS 项目，则必须在特定机器上执行，所以此时指定 tags 标签很有用。
除此之外 task 还能指定 only 标签用于限定那些分支才能触发这个 task，如果分支名字不满足则不会触发；默认情况下，这些 task 都是自动执行的，如果感觉某些任务太过危险，则可以通过增加 when: manual 改为手动执行；注意: 手动执行被 GitLab 认为是高权限的写操作，所以只有项目管理员才能手动运行一个 task，直白的说就是管理员才能点击。
cachecache 这个参数用于定义全局那些文件将被 cache；在 GitLab CI 中，跨 stage 是不能保存东西的；也就是说在第一步 build 的操作生成的执行文件，到第二部打包 docker image 时就会被删除；GitLab 会保证每个 stage 中任务在执行时都将工作目录(Docker 容器 中)还原到跟 GitLab 代码仓库中一模一样，多余文件及变更都会被删除；正常情况下，第一步 build 生成文件应当立即推送到文件服务器；但是这里测试没有搭建，所以只能放到本地；但是放到本地下一个 task 就会删除它，所以利用cache 这个参数将 build 目录 cache 住，保证其跨 stage 也能存在。
关于 .gitlab-ci.yml 具体配置更完整的请参考：
五、其他相关
5.2、GitLab 自定义环境变量
在某些情况下，我们希望 CI 能自动的发布或者修改一些东西；比如将生成文件上传到镜像库、将 docker 镜像 push 到私服；这些动作往往需要一个高权限或者说有可写入对应仓库权限的账户来支持，但是这些账户又不想写到项目的 CI 配置里；因为这样很不安全，谁都能看到；此时我们可以将这些敏感变量写入到 GitLab 自定义环境变量中，GitLab 会像对待内置变量一样将其传送到 Runner 端，以供我们使用；GitLab 中自定义的环境变量可以有两种，一种是项目级别的，只能够在当前项目使用，如下
另一种是组级别的，可以在整个组内的所有项目中使用，如下
这两种变量添加后都可以在 CI 的脚本中直接引用。
5.3、Kubernetes 集成
对于 Kubernetes 集成实际上有两种方案，一种是对接 Kubernetes 的 api，纯代码实现；另一种取巧的方案是调用 kubectl 工具，用 kubectl 工具来实现滚动升级；这里采用后一种取巧的方式，将 kubectl 二进制文件封装到镜像中，然后在 deploy 阶段使用这个镜像直接部署就可以：
我用的是harbor, 镜像很方便搜索、维护：
手动触发完部署后，
最后， kubectl set image在产生环境使用时，需要经过领导审批、验证确认，所以暂不会直接上线，但这句命令随时可上线。