欢迎访问我的GitHub
https://github.com/zq2599/blog_demos
内容:所有原创文章分类和汇总,及配套源码,涉及Java、Docker、Kubernetes、DevOPS等;
关于GitLab CI
如下图所示,开发者将代码提交到GitLab后,可以触发CI脚本在GitLab Runner上执行,通过编写CI脚本我们可以完成很多使用的功能:编译、构建、生成docker镜像、推送到私有仓库等;
![35b04c7a7af39468ce08567eb0fac85d.png](https://i-blog.csdnimg.cn/blog_migrate/1bdd8f9d379f9fb048e7baee9edd8889.jpeg)
本次实战内容
今天咱们会一起完成以下操作:
- 部署minio,pipeline脚本中的cache功能由minio来实现;
- 配置和部署GitLab Runner;
- 编写和运行pipeline脚本;
环境和版本信息
本次实战涉及到多个服务,下面给出它们的版本信息供您参考:
- GitLab:Community Edition 13.0.6
- GilLab Runner:13.1.0
- kubernetes:1.15.3
- Harbor:1.1.3
- Minio:2020-06-18T02:23:35Z
- Helm:2.16.1
需要提前准备好的服务
以下服务需要您在实战前提前准备好:
- 部署好GitLab,参考《群晖DS218+部署GitLab》
- 部署好Harbor,参考《群晖DS218+部署Harbor(1.10.3)》
- 部署好Helm,参考《部署和体验Helm(2.16.1版本)》
准备完毕后开始实战;
部署minio
minio作为一个独立的服务部署,我将用docker部署在服务器:192.168.50.43
- 在宿主机准备两个目录,分别存储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
- 执行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
- 浏览器访问,输入access key和secret key后登录成功:
![b686390bb92bf7ea8a433e359b40c4fc.png](https://i-blog.csdnimg.cn/blog_migrate/5691b542a1c58097a7c4f2b04a1bf3fd.jpeg)
- 如下图,点击红框中的图标,创建一个bucket,名为 runner:
![85f26a01cd44629b5920fadd4d121e05.png](https://i-blog.csdnimg.cn/blog_migrate/13cd2cd73182e7b7e49a05c6b795cdd9.jpeg)
至此,minio已备好,接下来在kubernetes环境部署GitLab Runner;
GitLab Runner的类型
从使用者的维度来看,GitLab Runner的类型分为shared和specific两种:
- 如果您想创建的GitLab Runner给所有GitLab仓库使用,就要创建shared类型;
- 如果您的GitLab Runner只用于给某个固定的Gitlab仓库,就要创建specific类型;
今天的实战,我们创建的是specific类型,即先有GitLab代码仓库,然后创建该仓库专用的runner,所以请您提前准备好GitLab仓库;
准备GitLab配置信息(specific)
GitLab Runner
在部署GitLab Runner之前,要准备两个关键的配置信息,以便GitLab Runner启动后可以顺利连接上GitLab;
- 浏览器访问GitLab,打开用来做CI的代码仓库,点击Settings -> CI/CD -> Runners -> Expand:
![d0cb4d8207005a28f9bb95f49689922a.png](https://i-blog.csdnimg.cn/blog_migrate/cd98a2e00af35bcd56ae9d0864d5b3be.jpeg)
- 如下图,红框1中是gitlab url,红框2中是registration token,记好这两个参数,稍后会用到:
![6144f18c580cfc63b74727904535e6c8.png](https://i-blog.csdnimg.cn/blog_migrate/747be19c694e8c6934d21bc9eeb17cbf.jpeg)
准备GitLab配置信息(shared)
本次实战不会创建shared类型的runner,如果您要创建该类型runner,只需按照以下方法准备信息即可,创建出来的runner就是所有仓库都能使用的了:
- 以管理员身份登录GitLab;
- 按照下图红框的顺序取得gitlab url和registration token:
![d5baf8bbd4f5686ca76b3cf4e415f13f.png](https://i-blog.csdnimg.cn/blog_migrate/c5056b3d9879df285737dd3cb738e8f6.jpeg)
部署RitLab Runner
- 请确保当前可以通过kubectl命令在kubernetes进行常规操作;
- 创建名为gitlab-runner的namespace:
kubectl create namespace gitlab-runner
- 创建一个secret,把minio的access key和secret key存进去,在后面配置cache的时候会用到:
kubectl create secret generic s3access --from-literal=accesskey="access" --from-literal=secretkey="secret123456" -n gitlab-runner
- 用helm部署GitLab Runner之前,先把chart的仓库添加到helm的仓库列表中:
helm repo add gitlab https://charts.gitlab.io
- 下载GitLab Runner的chart:
helm fetch gitlab/gitlab-runner
- 当前目录会多出一个文件gitlab-runner-0.18.0.tgz,解压:
tar -zxvf gitlab-runner-0.18.0.tgz
- 解压后是名为gitlab-runner的文件夹,内容如下图所示,接下来要修改里面的三个文件:
![f467139d67d441c0ad042f61ef3776ed.png](https://i-blog.csdnimg.cn/blog_migrate/5541150d495b23b5e21c4f6a31b22299.jpeg)
- 打开values.yaml,里面有四处需要修改:
- 第一处,找到已被注释掉的gitlabUrl参数位置,添加gitlabUrl的配置,其值就是前面在GitLab网页取得的gitlab url参数,如下图红框:
![d80d22eb33510e57fdc81b5565a6473e.png](https://i-blog.csdnimg.cn/blog_migrate/60bb8bd03931fdd85e49333105c4e146.jpeg)
- 第二处,找到已被注释掉的runnerRegistrationToken参数位置,添加runnerRegistrationToken的配置,其值就是前面在GitLab网页取得的registration token参数,如下图红框:
![885fd49e15b8a0ea05d1aca484cb22c1.png](https://i-blog.csdnimg.cn/blog_migrate/55a205c8a6b825b06582b89bf2aceaf0.jpeg)
![9c89a666abb72f4c49d067b617b2472b.png](https://i-blog.csdnimg.cn/blog_migrate/fec0af8467bdb403377985126dc3904c.jpeg)
- 设置此GitLab Runner的tag为k8s,在pipeline脚本中可以通过指定tag为k8s,这样pipeline就会在这个Gitlab Runner上允许:
![81c5c5644924463cffd43abfacd88e6a.png](https://i-blog.csdnimg.cn/blog_migrate/fff3cd9311840a97a1658c850c332015.jpeg)
- 找到cache的配置,在修改之前,cache的配置如下图,可见值为空内容的大括号,其余信息全部被注释了:
![8f5e998e7bf4198df696733860e332fc.png](https://i-blog.csdnimg.cn/blog_migrate/d8ee5cc26ec3110312fa3f28dc897805.jpeg)
- 修改后的cache配置如下图,红框1中原先的大括号已去掉,红框2中的是去掉了注释符号,内容不变,红框3中填写的是minio的访问地址,红框4中的是去掉了注释符号,内容不变
![df6524c086364795d89e82e14864308e.png](https://i-blog.csdnimg.cn/blog_migrate/3eb679d5cd0fd216762d4bf25e7cea3b.jpeg)
- 上图红框4中的s3CacheInsecure参数等于false表示对minio的请求为http(如果是true就是https),但实际证明,当前版本的chart中该配置是无效的,等到运行时还是会以https协议访问,解决此问题的方法是修改templates目录下的_cache.tpl文件,打开此文件,找到下图红框中的内容:
![d98fc0f60abc44bfcd5c2e4d8ca09765.png](https://i-blog.csdnimg.cn/blog_migrate/d3846b6689f12ba0192631eb8a22edc2.jpeg)
- 将上图红框中的内容替换成下面红框中的样子,即删除原先的if判断和对应的end这两行,直接给CACHE_S3_INSECURE赋值
![7ce1ad2dcd5813c0e4a7b8cf7f34ecd1.png](https://i-blog.csdnimg.cn/blog_migrate/c2bff770942ba829fb848ccee6fe7cd1.jpeg)
- 接下来要修改的是templates/configmap.yaml文件,在这里面将宿主机的docker的sock映射给runner executor,这样job中的docker命令就会发到宿主机的docker daemon上,由宿主机来执行,打开templates/configmap.yaml,找到下图位置,我们要在红框1和红框2之间添加一段内容:
![e5453fd7a9b80e51cf088935f4e49ec1.png](https://i-blog.csdnimg.cn/blog_migrate/fabf270021a600843d2dcb92a8104d1e.jpeg)
- 要在上图红框1和红框2之间添加的内容如下:
cat >>/home/gitlab-runner/.gitlab-runner/config.toml <
- 添加上述内容后,整体效果如下,红框中就是新增内容:
![d125d02cc3d6c44ef61bce6ed9e4167d.png](https://i-blog.csdnimg.cn/blog_migrate/d3e94d859343e249cd659739ea50a392.jpeg)
- 修改完毕,回到values.yam所在目录,执行以下命令即可创建GitLab Runner:
helm install --name-template gitlab-runner -f values.yaml . --namespace gitlab-runner
- 检查pod是否正常:
![ca86a58e3c0aa277d3ffa97625110311.png](https://i-blog.csdnimg.cn/blog_migrate/efeb4f1a2d92e0df5a6d5eea838e00c4.jpeg)
- 看pod日志也并未发现异常:
![1d86c0c2020d58792fffd209faf81bb7.png](https://i-blog.csdnimg.cn/blog_migrate/b831002f9b89c967f6449d98b2b9c312.jpeg)
- 回到GitLab的runner页面,可见新增一个runner:
![a5bff062d6a9b36a6c2037889b39a003.png](https://i-blog.csdnimg.cn/blog_migrate/31187cb43889f587e11664379a662ec2.jpeg)
至此,整个GitLab CI环境已部署完毕,接下来简单的验证环境是否OK;
验证
在GitLab仓库中,增加名为.gitlab-ci.yml的文件,内容如下:
# 设置执行镜像image: busybox:latest# 整个pipeline有两个stagestages:- 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.txttest1: stage: test script: - echo "从缓存读取内容" - cat vendor/hello.txt
- 提交上述脚本到GitLab,如下图,可见pipeline会被触发,状态为pending是因为正在等待runner创建executor pod:
![d2be583d9aef1738ac0c0bbe00c1016a.png](https://i-blog.csdnimg.cn/blog_migrate/0ec73300217dc060e58ae5120b104dd1.jpeg)
- 稍后就会执行成功,点开看结果:
![47078ef8973afe050b7d794a8cf2645b.png](https://i-blog.csdnimg.cn/blog_migrate/ef2f0e157f8cd9e488dac1f6005dce37.jpeg)
- 点开build1的图标,可见此job的输出信息:
![813fe2251b31ec76939c86ad24ebc9dc.png](https://i-blog.csdnimg.cn/blog_migrate/39ee2a9d564b7cc50874b5cd539c747e.jpeg)
- 点开test1的图标,可见对应的控制台输出,上一个job写入的数据被成功读取:
![c9edeb7b56ee4eff53ab35f6db42147e.png](https://i-blog.csdnimg.cn/blog_migrate/b1314887474e2e5ec2009cac289a5f89.jpeg)
至此,GitLab Runner已经成功在kubernetes环境部署和运行,接下来的文章,我们会一起实战将SpringBoot应用构建成docker镜像并推送到Harbor;
欢迎关注我的公众号:程序员欣宸
![b7d8e5fa3fe0ec8bc75269d1a204e8bc.png](https://i-blog.csdnimg.cn/blog_migrate/633c62ba4cdf8cb2cffb7a05dd56a515.jpeg)