Gitlab Kubernetes CD自动标记更改

使用--set部署头盔时，您可以传递docker image标签值。因此，对于管道中的不同分支（主分支和非主分支），您可以有不同的阶段，其中一个阶段您将传递--set dockerImageTag=latest，而对于MR分支，它将是--set dockerImageTag=<branch-name>。

mr-build-deploy:
  only:
    - merge_requests
  script:
    - docker build ...
    - docker tag <docker-tag-name>
    - helm install --set dockerImageTag=<docker-tag-name> ...
 ...

master-build-deploy:
  only:
    - master
  script:
    - docker build ...
    - docker tag latest
    - helm install --set dockerImageTag=latest ...
 ...

或者在values.yaml中为lem图，您可以将默认值dockerImageTag设置为最新值，因此对于主步骤，您无需指定它。

说到最佳实践，建议不要使用最新标签，而要使用版本号（例如，以SemVer的形式），这样可以确保docker image中的哪些更改（如果发生）破坏了应用程序。

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

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

1. 执行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

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

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

1. 至此，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：

1. 如下图，红框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

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

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

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

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

1. 下载GitLab Runner的chart：

helm fetch gitlab/gitlab-runner

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

tar -zxvf gitlab-runner-0.18.0.tgz

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

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

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

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

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

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

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

1. 上图红框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>文件，打开此文件，找到下图红框中的内容：

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

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

1. 要在上图红框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

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

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

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

1. 检查pod是否正常：

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

1. 回到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

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

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

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

1. 点开<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

关于如何使用Kubernetes运行程序在Gitlab中为Maven添加持久卷和gitlab kubernetes的介绍已经告一段落，感谢您的耐心阅读，如果想了解更多关于GitLab CI运行程序无法连接到Kubernetes中的unix：///var/run/docker.sock、Gitlab Kubernetes CD自动标记更改、GitLab Runner 部署 (kubernetes 环境)、GitLab Runner部署(kubernetes环境)的相关信息，请在本站寻找。