GitLab Runner部署(kubernetes环境)

欢迎访问我的GitHub

https://github.com/zq2599/blog_demos

内容：所有原创文章分类汇总及配套源码，涉及Java、Docker、Kubernetes、DevOPS等；

关于GitLab CI

如下图所示，开发者将代码提交到GitLab后，可以触发CI脚本在GitLab Runner上执行，通过编写CI脚本我们可以完成很多使用的功能：编译、构建、生成docker镜像、推送到私有仓库等：

在这里插入图片描述

本次实战内容

今天咱们会一起完成以下操作：

1. 部署minio，pipeline脚本中的cache功能由minio来实现；
2. 配置和部署GitLab Runner；
3. 编写和运行pipeline脚本；

环境和版本信息

本次实战涉及到多个服务，下面给出它们的版本信息供您参考：

1. GitLab：Community Edition 13.0.6
2. GilLab Runner：13.1.0
3. kubernetes：1.15.3
4. Harbor：1.1.3
5. Minio：2020-06-18T02:23:35Z
6. Helm：2.16.1

需要提前准备好的服务

以下服务需要您在实战前提前准备好：

1. 部署好GitLab，参考《群晖DS218+部署GitLab》
2. 部署好Harbor，参考《群晖DS218+部署Harbor(1.10.3)》
3. 部署好Helm，参考《部署和体验Helm(2.16.1版本)》

准备完毕后开始实战；

部署minio

minio作为一个独立的服务部署，我将用docker部署在服务器：<font color="blue">192.168.50.43</font>

1. 在宿主机准备两个目录，分别存储minio的配置和文件，执行以下命令：

mkdir -p /var/services/homes/zq2599/minio/gitlab_runner \
&& chmod -R 777 /var/services/homes/zq2599/minio/gitlab_runner \
&& mkdir -p /var/services/homes/zq2599/minio/config \
&& chmod -R 777 /var/services/homes/zq2599/minio/config

2. 执行docker命令创建minio服务，指定服务端口是9000，并且指定了access key(最短三位)和secret key(最短八位)：

sudo docker run -p 9000:9000 --name minio \
-d --restart=always \
-e "MINIO_ACCESS_KEY=access" \
-e "MINIO_SECRET_KEY=secret123456" \
-v /var/services/homes/zq2599/minio/gitlab_runner:/gitlab_runner \
-v /var/services/homes/zq2599/minio/config:/root/.minio \
minio/minio server /gitlab_runner

3. 浏览器访问，输入access key和secret key后登录成功：

   
   在这里插入图片描述

4. 如下图，点击红框中的图标，创建一个bucket，名为<font color="blue">runner</font>：

   
   在这里插入图片描述
5. 至此，minio已备好，接下来在kubernetes环境部署GitLab Runner；

GitLab Runner的类型

从使用者的维度来看，GitLab Runner的类型分为<font color="blue">shared</font>和<font color="blue">specific</font>两种：

1. 如果您想创建的GitLab Runner给所有GitLab仓库使用，就要创建<font color="blue">shared</font>类型；
2. 如果您的GitLab Runner只用于给某个固定的Gitlab仓库，就要创建<font color="blue">specific</font>类型；

今天的实战，我们创建的是<font color="red">specific</font>类型，即先有GitLab代码仓库，然后创建该仓库专用的runner，所以请您提前准备好GitLab仓库；

准备GitLab配置信息(specific)

在部署GitLab Runner之前，要准备两个关键的配置信息，以便GitLab Runner启动后可以顺利连接上GitLab：

1. 浏览器访问GitLab，打开用来做CI的代码仓库，点击Settings -> CI/CD -> Runners -> Expand：

   
   在这里插入图片描述

2. 如下图，红框1中是<font color="blue">gitlab url</font>，红框2中是<font color="blue">registration token</font>，记好这两个参数，稍后会用到：

   
   在这里插入图片描述

准备GitLab配置信息(shared)

本次实战不会创建shared类型的runner，如果您要创建该类型runner，只需按照以下方法准备信息即可，创建出来的runner就是所有仓库都能使用的了：

1. 以管理员身份登录GitLab；

2. 按照下图红框的顺序取得<font color="blue">gitlab url</font>和<font color="blue">registration token</font>：

   
   在这里插入图片描述

部署RitLab Runner

1. 请确保当前可以通过<font color="blue">kubectl</font>命令在kubernetes进行常规操作；
2. 创建名为<font color="blue">gitlab-runner</font>的namespace：

kubectl create namespace gitlab-runner

3. 创建一个secret，把minio的access key和secret key存进去，在后面配置cache的时候会用到：

kubectl create secret generic s3access \
--from-literal=accesskey="access" \
--from-literal=secretkey="secret123456" -n gitlab-runner

4. 用helm部署GitLab Runner之前，先把chart的仓库添加到helm的仓库列表中：

helm repo add gitlab https://charts.gitlab.io

5. 下载GitLab Runner的chart：

helm fetch gitlab/gitlab-runner

6. 当前目录会多出一个文件gitlab-runner-0.18.0.tgz，解压：

tar -zxvf gitlab-runner-0.18.0.tgz

7. 解压后是名为gitlab-runner的文件夹，内容如下图所示，接下来要修改里面的三个文件：

在这里插入图片描述

8. 打开values.yaml，里面有四处需要修改：
9. 第一处，找到已被注释掉的<font color="blue">gitlabUrl</font>参数位置，添加gitlabUrl的配置，其值就是前面在GitLab网页取得的<font color="red">gitlab url</font>参数，如下图红框：

在这里插入图片描述

10. 第二处，找到已被注释掉的<font color="blue">runnerRegistrationToken</font>参数位置，添加<font color="red">runnerRegistrationToken</font>的配置，其值就是前面在GitLab网页取得的<font color="blue">registration token</font>参数，如下图红框：

在这里插入图片描述

11. 找到<font color="blue">rbac</font>的配置，将<font color="blue">create</font>和<font color="blue">clusterWideAccess</font>的值都改成<font color="red">true</font>(创建RBAC、创建容器gitlab-bastion用于管理job的容器)：

在这里插入图片描述

12. 设置此GitLab Runner的<font color="blue">tag</font>为<font color="red">k8s</font>，在pipeline脚本中可以通过指定tag为<font color="red">k8s</font>，这样pipeline就会在这个Gitlab Runner上允许：

在这里插入图片描述

13. 找到<font color="blue">cache</font>的配置，在修改之前，cache的配置如下图，可见值为空内容的大括号，其余信息全部被注释了：

在这里插入图片描述

14. 修改后的<font color="blue">cache</font>配置如下图，红框1中原先的大括号已去掉，红框2中的是去掉了注释符号，内容不变，红框3中填写的是<font color="blue">minio</font>的访问地址，红框4中的是去掉了注释符号，内容不变：

在这里插入图片描述

15. 上图红框4中的<font color="blue">s3CacheInsecure</font>参数等于<font color="blue">false</font>表示对minio的请求为http(如果是true就是https)，但实际证明，<font color="red">当前版本的chart中该配置是无效的</font>，等到运行时还是会以https协议访问，解决此问题的方法是修改templates目录下的<font color="blue">_cache.tpl</font>文件，打开此文件，找到下图红框中的内容：

在这里插入图片描述

16. 将上图红框中的内容替换成下面红框中的样子，即删除原先的<font color="blue">if判断和对应的end</font>这两行，直接给<font color="red">CACHE_S3_INSECURE</font>赋值：

    
    在这里插入图片描述
17. 接下来要修改的是<font color="blue">templates/configmap.yaml</font>文件，在这里面将宿主机的docker的sock映射给runner executor，这样job中的docker命令就会发到宿主机的docker daemon上，由宿主机来执行，打开<font color="blue">templates/configmap.yaml</font>，找到下图位置，我们要在红框1和红框2之间添加一段内容：

在这里插入图片描述

18. 要在上图红框1和红框2之间添加的内容如下：

cat >>/home/gitlab-runner/.gitlab-runner/config.toml <<EOF
            [[runners.kubernetes.volumes.host_path]]
              name = "docker"
              mount_path = "/var/run/docker.sock"
              read_only = true
              host_path = "/var/run/docker.sock"
    EOF

19. 添加上述内容后，整体效果如下，红框中就是新增内容：

在这里插入图片描述

20. 修改完毕，回到<font color="blue">values.yam</font>所在目录，执行以下命令即可创建GitLab Runner：

helm install \
--name-template gitlab-runner \
-f values.yaml . \
--namespace gitlab-runner

21. 检查pod是否正常：

在这里插入图片描述

22. 看pod日志也并未发现异常：

在这里插入图片描述

23. 回到GitLab的runner页面，可见新增一个runner：

在这里插入图片描述

至此，整个GitLab CI环境已部署完毕，接下来简单的验证环境是否OK；

验证

1. 在GitLab仓库中，增加名为<font color="blue">.gitlab-ci.yml</font>的文件，内容如下：

# 设置执行镜像
image: busybox:latest

# 整个pipeline有两个stage
stages:
- build
- test

# 定义全局缓存，缓存的key来自分支信息，缓存位置是vendor文件夹
cache:
  key: ${CI_COMMIT_REF_SLUG}
  paths:
  - vendor/

before_script:
  - echo "Before script section"

after_script:
  - echo "After script section"

build1:
  stage: build
    tags:
  - k8s
  script:
    - echo "将内容写入缓存"
    - echo "build" > vendor/hello.txt

test1:
  stage: test
  script:
    - echo "从缓存读取内容"
    - cat vendor/hello.txt

2. 提交上述脚本到GitLab，如下图，可见pipeline会被触发，状态为pending是因为正在等待runner创建executor pod：

在这里插入图片描述

3. 稍后就会执行成功，点开看结果：

在这里插入图片描述

4. 点开<font color="blue">build1</font>的图标，可见此job的输出信息：

在这里插入图片描述

5. 点开<font color="blue">test1</font>的图标，可见对应的控制台输出，上一个job写入的数据被成功读取：

在这里插入图片描述

至此，GitLab Runner已经成功在kubernetes环境部署和运行，接下来的文章，我们会一起实战将SpringBoot应用构建成docker镜像并推送到Harbor；

你不孤单，欣宸原创一路相伴

1. Java系列
2. Spring系列
3. Docker系列
4. kubernetes系列
5. 数据库+中间件系列
6. DevOps系列

欢迎关注公众号：程序员欣宸

微信搜索「程序员欣宸」，我是欣宸，期待与您一同畅游Java世界...
https://github.com/zq2599/blog_demos