图文详解k8s自动化持续集成之GitLab CI/CD

时间 2019-11-11

标签图文详解 k8s 自动化持续集成 gitlab 栏目测试自动化繁體版

原文原文链接

前言

持续集成的好处主要有两个:html

快速发现错误

　　每完成一点更新，就集成到主干，能够快速发现错误，定位错误也比较容易java

防止分支大幅偏离主干

　　若是不是常常集成，主干又在不断更新，会致使之后集成的难度变大，甚至难以集成。持续集成的目的，就是让产品能够快速迭代，同时还能保持高质量。它的核心措施是，代码集成到主干以前，必须经过自动化测试。只要有一个测试用例失败，就不能集成。git

1、环境准备

首先须要有一台 GitLab 服务器，而后须要有个项目；这里示例项目以 golang 项目为例，而后最好有一台专门用来 Build 的机器，实际生产中若是 Build 任务不频繁可适当用一些业务机器进行 Build；本文示例全部组件将采用 Docker 启动， GitLab HA 等不在本文阐述范围内golang

Docker Version : 1.13.1
GitLab Version : 10.1.4-ce.0
GitLab Runner Version : 10.1.0

2、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 其大体架构以下redis

Runner能够分布在不一样的主机上，同一个主机上也能够有多个Runner。docker

3、搭建 GitLab 服务器

3.一、GitLab 搭建

已经有gitlab的同窗，能够跳过。GitLab 搭建这里直接使用 docker compose 启动，compose 配置以下shell

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.

vim

3.二、增长示例项目

这里示例项目采用 Golang 的 Fingerprint 项目，并采用 go module 构建，其余语言原理同样；若是不熟悉 golang 的不必死磕此步配置，任意语言整一个能用的项目就行，并不强求特定语言、框架构建，如下只是一个样例项目，以下所示：segmentfault

最后将项目提交到 GitLab 后以下
centos

4、GitLab CI 配置

针对这一章节建立基础镜像以及项目镜像，这里仅以 Go 项目为例；其余语言原理相通，按照其余语言对应的运行环境修改便可

4.一、增长 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 Token，Runner Token 能够从 GitLab 设置中查看，以下所示

注册完成后，在 GitLab Runner 设置中就能够看到刚刚注册的 Runner，以下所示

注意，这里声明的 Volumes 会在每一个运行的容器中都生效；也就是说 build 时新开启的每一个容器都会被挂载这些目录；修改完成后重启 runner 容器便可。

4.二、建立项目镜像

针对于项目每次 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.三、建立 CI 配置文件

一切准备就绪之后，就能够编写 CI 文件了；GitLab 依靠读取项目根目录下的 .gitlab-ci.yml 文件来执行相应的 CI 操做：

#image: registry.api.weibo.com/article/golang.image:1.11
image: golang:1.12

#only:
#  - master

variables:
  IMAGE_TAG_NAME: "registry.api.weibo.com/cms-auto/fingerprint:${CI_COMMIT_SHORT_SHA}"

cache:
  untracked: true #cache all files that are untracked in your Git
  key: $CI_COMMIT_REF_NAME #-$CI_COMMIT_REF_NAME #-$CI_COMMIT_SHA
  paths:
    - .goBinTmp


after_script:
  - echo "after_script"

before_script:
  - echo "before_script"
  - hostname && cat /etc/*lease && ip a && env && pwd && ls -al
  - export GOPROXY=https://goproxy.io
  - export GOPATH="$CI_PROJECT_DIR/_vgo"
  - mkdir -p .goBinTmp

# 定义 stages
stages:
  - test
  - build
  - push_image
  - deploy


# 定义 job
job_test:
  stage: test
  script:
    - echo "Testing is starting"
    - printf "mode=test\nlog_dir=/data1/ms/log/fingerprintGo/" > .env
    - go vet ./... #语法错误检查
    - ping -c1  redis  #
#    - go test $(go list ./...)
    - go test -v  ./...  # -benchmem -bench=.
  services: #docker link
    - name: redis
      alias: redis.test
  tags:
    - cms

# 定义 job
job_build:
  stage: build
  script:
    - echo "Building is starting"
    - go build -race
    - cp fingerprint .goBinTmp/
  tags:
    - cms

# 定义 deploy
push_image:
  variables:
     # When using dind service we need to instruct docker, to talk with the
     # daemon started inside of the service. The daemon is available with
     # a network connection instead of the default /var/run/docker.sock socket.
     #
     # The 'docker' hostname is the alias of the service container as described at
     # https://docs.gitlab.com/ee/ci/docker/using_docker_images.html#accessing-the-services
     #
     # Note that if you're using Kubernetes executor, the variable should be set to
     # tcp://localhost:2375 because of how Kubernetes executor connects services
     # to the job container
     DOCKER_HOST: tcp://docker:2375/
     # When using dind, it's wise to use the overlayfs driver for
     # improved performance.
     DOCKER_DRIVER: overlay2
  image: docker:stable
  services:
     - docker:dind
#  before_script:
#     - docker info
#     - echo "${DOCKER_DRIVER} ${DOCKER_HOST}"
  stage: push_image
#  when: manual #只能手动触发
  script:
    - echo "Deploy to staging server "
#    - docker pull $CI_REGISTRY_IMAGE:latest || true
    - cp .goBinTmp/fingerprint fingerprint
    - docker build -f docker/Dockerfile -t ${IMAGE_TAG_NAME} .  #--cache-from $CI_REGISTRY_IMAGE:latest
    - docker login registry.api.weibo.com --username "${REGISTRY_USER}" --password "${REGISTRY_PWD}"
    - docker push ${IMAGE_TAG_NAME}
    - docker run --name fingerprint-test -d -v /data1/ms/log:/data1/ms/log  ${IMAGE_TAG_NAME}
    - sleep 5
    - docker ps |grep -q 'fingerprint-test'
    - docker stop fingerprint-test && docker rm fingerprint-test
  environment:
      name: deploying
  only:
    - master
  tags:
    - cms

deploy:
  stage: deploy
  when: manual #只能手动触发
  variables:
    CI_DEBUG_TRACE: "true"  #debug tracing
  script:
    - docker run -it alpine/git clone 'https://${REGISTRY_USER}:${REGISTRY_PWD}@git.staff.sina.com.cn/cms/backend/FingerprintGo.git'
    - cd FingerprintGo
    - docker run -it alpine/git tag -a "${VERSION}" -m "${VERSION}"
    - docker run -it alpine/git push origin --tags
    - echo "kubectl set image deployment/fingerprint fingerprint=${IMAGE_TAG_NAME} -n fingerprint"
  tags:
    - cms
  only:
    - master
  artifacts:
    name: "$CI_JOB_NAME"
    paths:
      - .goBinTmp/* #go test will ignore

4.4 CI 配置的经常使用概念：

stages
stages 字段定义了整个 CI 一共有哪些阶段流程，以上的 CI 配置中，定义了该项目的 CI 总共分为 build、deploy 两个阶段；GitLab CI 会根据其顺序执行对应阶段下的全部任务；在正常生产环境流程能够定义不少个，好比能够有 test、publish，甚至可能有代码扫描的 sonar 阶段等；这些阶段没有任何限制，彻底是自定义的，上面的阶段定义好后在 CI 中表现以下图

task
task 隶属于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 运行后以下图所示

除此以外 task 还能指定 only 标签用于限定那些分支才能触发这个 task，若是分支名字不知足则不会触发；默认状况下，这些 task 都是自动执行的，若是感受某些任务太过危险，则能够经过增长 when: manual 改成手动执行；注意: 手动执行被 GitLab 认为是高权限的写操做，因此只有项目管理员才能手动运行一个 task，直白的说就是管理员才能点击；手动执行以下图所示。

cache
cache 这个参数用于定义全局那些文件将被 cache；在 GitLab CI 中，跨 stage 是不能保存东西的；也就是说在第一步 build 的操做生成的执行文件，到第二部打包 docker image 时就会被删除；GitLab 会保证每一个 stage 中任务在执行时都将工做目录(Docker 容器中)还原到跟 GitLab 代码仓库中如出一辙，多余文件及变动都会被删除；正常状况下，第一步 build 生成文件应当当即推送到文件服务器；可是这里测试没有搭建，因此只能放到本地；可是放到本地下一个 task 就会删除它，因此利用cache 这个参数将 build 目录 cache 住，保证其跨 stage 也能存在。

关于 .gitlab-ci.yml 具体配置更完整的请参考：

Gitlab CI yaml官方配置文件翻译

5、其余相关

5.一、GitLab 内置环境变量

上面已经基本搞定了一个项目的 CI，可是有些变量可能并未说清楚；好比在建立的 PROJECT_ENV 文件中引用了$CI_COMMIT_REF_NAME、${CI_COMMIT_SHA} 等变量；这种变量实际上是 GitLab CI 的内置隐藏变量，这些变量在每次 CI 调用 Runner 运行某个任务时都会传递到对应的 Runner 的执行环境中；也就是说这些变量在每次的任务容器 SHELL 环境中都会存在，能够直接引用，具体的完整环境变量列表能够从官方文档中获取；若是想知道环境变量具体的值，实际上能够经过在任务执行前用 env 指令打印出来，以下所示

5.二、GitLab 自定义环境变量

在某些状况下，咱们但愿 CI 能自动的发布或者修改一些东西；好比将生成文件上传到镜像库、将 docker 镜像 push 到私服；这些动做每每须要一个高权限或者说有可写入对应仓库权限的帐户来支持，可是这些帐户又不想写到项目的 CI 配置里；由于这样很不安全，谁都能看到；此时咱们能够将这些敏感变量写入到 GitLab 自定义环境变量中，GitLab 会像对待内置变量同样将其传送到 Runner 端，以供咱们使用；GitLab 中自定义的环境变量能够有两种，一种是项目级别的，只可以在当前项目使用，以下

另外一种是组级别的，能够在整个组内的全部项目中使用，以下

这两种变量添加后均可以在 CI 的脚本中直接引用。

5.三、Kubernetes 集成

对于 Kubernetes 集成实际上有两种方案，一种是对接 Kubernetes 的 api，纯代码实现；另外一种取巧的方案是调用 kubectl 工具，用 kubectl 工具来实现滚动升级；这里采用后一种取巧的方式，将 kubectl 二进制文件封装到镜像中，而后在 deploy 阶段使用这个镜像直接部署就能够：

我用的是harbor, 镜像很方便搜索、维护：

手动触发完部署后，

最后， kubectl set image在产生环境使用时，须要通过领导审批、验证确认，因此暂不会直接上线，但这句命令随时可上线，哈哈。

5.四、GitLab CI 总结

关于 GitLab CI 上面已经讲了不少，可是并不全面，也不算太细致；由于这东西提及来实际太多了，如今目测已经 1W 多字了；如下总结一下 GitLab CI 的整体思想，当思路清晰了之后，我想后面的只是查查文档本身试一试就好了

CS 架构
GitLab 做为 Server 端，控制 Runner 端执行一系列的 CI 任务；代码 clone 等无需关心，GitLab 会自动处理好一切；Runner 每次都会启动新的容器执行 CI 任务

容器即环境
在 Runner 使用 Docker build 的前提下；全部依赖切换、环境切换应当由切换不一样镜像实现，即 build 那就使用 build 的镜像，deploy 就用带有 deploy 功能的镜像；经过不一样镜像容器实现完整的环境隔离

CI即脚本
不一样的 CI 任务实际上就是在使用不一样镜像的容器中执行 SHELL 命令，自动化 CI 就是执行预先写好的一些小脚本

敏感信息走环境变量
一切重要的敏感信息，如帐户密码等，不要写到 CI 配置中，直接放到 GitLab 的环境变量中；GitLab 会保证将其推送到远端 Runner 的 SHELL 变量中

6. 思考心得

什么状况下须要注册Shared Runner？
好比，GitLab上面全部的工程都有可能须要在公司的服务器上进行编译、测试、部署等工做，这个时候注册一个Shared Runner供全部工程使用就很合适。

什么状况下须要注册Specific Runner？
好比，我可能须要在我我的的电脑或者服务器上自动构建我参与的某个工程，这个时候注册一个Specific Runner就很合适。

什么状况下须要在同一台机器上注册多个Runner？
好比，我是GitLab的普通用户，没有管理员权限，我同时参与多个项目，那我就须要为个人全部项目都注册一个Specific Runner，这个时候就须要在同一台机器上注册多个Runner。
什么状况适合用dind模式（docker in docker）
项目测试、构建须要特殊的依赖，如依赖DB/java/go/libs..，或者同一项目须要并发CI/CD，再或者项目间有端口、文件等上的干扰、冲突，这里适合用dind。
这么好的东西没有没缺点？建立、调试.gitlab-ci.yml时，可能须要到docker run/log/exec里，或者颇有耐心的跑完整个pipeline。小技巧是：开启tracing，让直接retry失败的环节，可在docker中复现全部问题。