GitLab流水线配置

2023-08-27 10:20 作者:魔天贝儿 0人读过 | 我要投稿

yuchendulang主导下的阿G信息办是值得尊敬的

破壁越做越大已经站稳了脚跟，于是信息办希望我们可以把代码库从阿里云云效迁移到学校的git，这篇文章记录了一个gitlab仓库中的CI/CD流水线（超好用的push代码自动触发更新部署）是怎么打造起来的，前前后后花了比较久的时间，所以里面会夹杂一些牢骚，不过字多的话，重点主干流程是会彩色加粗标注的，不过因为b站没办法插入站外链接，所以这里的链接只能复制并且删掉b站为剪切板默认添加的尾巴才能访问到qwq。下面进入主题

O ping通目标Gitlab网址

这个Gitlab基站是建在校园网服务器上的，由于现在技术力有限，所以这里只能搞一个校内服务器尝试（感谢chen的服务器和simba的账号，虽然我是偷偷用的）。如果看官想做的是公网Gitlab的话，直接用云服务器就行，因为只涉及到内网访问问题，操作上毫无差别的，但是一定要有这一步，避免后面奇葩bug返工。

一下载docker

本来我是用阿里云服务器的，所以记录一下Alibaba Cloud Linux这个奇葩的操作系统是怎么安装docker的。先放一个官方操作文档：https://help.aliyun.com/zh/ecs/use-cases/deploy-and-use-docker-on-alibaba-cloud-linux-2-instances。

它逆天的地方在于照着里面cv会报错..... 好在在CSDN上找到了安好的文章：https://blog.csdn.net/m0_51041464/article/details/121048535

而正常的Linux系统安装docker可以参考菜鸟教程：https://www.runoob.com/docker/centos-docker-install.html，贼简单

二下载jdk

jdk17官网：https://www.oracle.com/java/technologies/downloads/#java17

安装jdk17：https://blog.csdn.net/qq_53679247/article/details/130784450

若有报错：/lib/ld-linux-aarch64.so.1: No such file or directory，

可能是没找对tar.gz，比如x64的找了arm64，找对就好了

三下载maven

先耍个嘴皮子。maven是个神奇的东西，刚学springboot的时候了解到有maven这个东西，一直管他叫仓库，但是这次下载maven报了各种错误，产生了 "运行springboot项目只需要java -jar my.jar就可以了，maven到底啥用" 等等问题，于是顺带去研究了一下maven和nexus，感觉还是挺有意思的。

话说回来，装个maven为什么会去研究Nexus？原来是装完docker又在docker内安装gitlab-runner之后，（经历了2天bug）我就直接开始跑流水线了。（经历了无数次无法启动）后终于成功报错了！——mvn没找到。上网查mvn怎么装——噢原来是这样（一番操作，mvn -v，mvn clean都有效了，满怀欣喜重新跑），又报错了，然后才反应过来docker是个全新的环境，在服务器上装没用啊，得在那个docker环境里装（此时意识到docker原来是这样一个东西，之前还特地搜了老多视频了，脑子比较钝都没听明白docker是个啥东西，集装箱鲸鱼共享什么的一团乱麻），于是搜索“如何在docker里安装maven”，搜到这篇很猛的知乎文章，提了个新鲜词Nexus，还把maven是什么也讲清楚了：https://zhuanlan.zhihu.com/p/568437960?utm_id=0。但是光看没用啊，啃了快一个小时理论倒是晓得了，部署不来，干脆放弃了，再搜搜其他的有没有简单易懂的部署。然后看到有一篇博客里部署成功了，而且需要的前提是“宿主机部署jdk和maven”，来劲了，又搜了好一会儿，搜到了下面将要讲的方式。

以下是本机以及docker内部署maven的流程。

本机部署Maven：https://blog.csdn.net/HJW_233/article/details/131800582

Maven官网：https://maven.apache.org/download.cgi

在创建docker环境时将本机文件挂载进docker环境里再相应地配置一下环境变量：https://blog.csdn.net/qq1445654576/article/details/104448915

二下载gitlab-runner

因为最开始省事直接yum install gitlab-runner，却发现找不到包....所以我的gitlab-runner是在docker环境内下载的（参考官方文档：https://docs.gitlab.com/runner/install/docker.html），不过也挺简单的，执行下面这句话就行了：未安装则自动安装，已安装则显示--help

sudo docker run  \

  -d --name gitlab-runner --restart always\

  -p 9000:9000 \

  -v /srv/gitlab-runner/config:/etc/gitlab-runner \

  -v /usr/local/java/jdk-17.0.8:/usr/local/java/jdk-17.0.8 \

  -v /home/apache-maven-3.9.4:/home/apache-maven-3.9.4 \

  -v /home/project:/home/project \

  -v /home/repository:/home/repository \

  -v /var/run/docker.sock:/var/run/docker.sock \

 gitlab/gitlab-runner:latest

以下是docker容器的相关操作

# 进入这个容器
sudo docker exec -it gitlab-runner bash
# 重启容器
sudo docker restart gitlab-runner
# 停止容器
sudo docker stop gitlab-runner
# 删除容器-1
sudo docker kill gitlab-runner
# 删除容器-2
sudo docker rm gitlab-runner
# 删除镜像
sudo docker rmi gitlab/gitlab-runner:latest

可以看见服务器里的命令行和进入docker后的命令行头显示是不一样的（因为我用的服务器不是root，有各种各种sudo和文件上传删除写入的权限；进入docker发现我是root了，我哭死）

上面给出的新建一个gitlab-runner容器的代码中出现了好多冒号，当时我也挺迷登的，这里也解释一下。

-v 里冒号的意思是，左边为本服务器的文件路径，右边为docker环境中的文件路径。这里我偷懒直接服务器怎么配置，docker里相同地配置一次就行了。其实也很好理解的，这段代码为镜像（英文image）gitlab/gitlab-runner:latest，创建了一个新的容器（英文container）gitlab-runner，这个容器可以理解为一个崭新的服务器，操作上和我们的本服务器一样的操作，只是啥都要自己配（vim都要自己装qwq（apt-get update、apt-get install vim就好了））它的执行结果就是进入容器，ls /home，就能看到一个现成的apache-maven文件夹，当然java等文件夹同理嘛，这样就引入了我们在宿主服务器上下载的maven和java，然后进入/etc/profile编辑一下，再source /etc/profile一下，就也在docker环境里装好java和maven啦

-p 里冒号的意思是，左边为服务器的端口，右边是docker容器的端口。比如我想在这个docker里部署9000端口的springboot项目，那么右边就需要填9000，然后我们毕竟是要从自己的服务器访问嘛，所以左边就是我们服务器的接口，如果是8000，那么就可以从"服务器ip:8000"访问到接口了

三注册gitlab-runner

这个注册也是个相当炸裂的存在，只需要运行一段话就行了，注册的结果会显示在/etc/gitlab-runner/config/config.toml文件里。

但是这段话现在还说不出口，不想看牢骚的看官可以直接跳到这一点的结尾

我原以为是Warning的问题。现在重新一想，似乎还是那么的有道理：failed，这种方式已经被抛弃了，怎么办？复制warning上百度查找。甚至翻出去bing国际版都没碰到几个说这种问题的，看了gitlab的整个issue稀里糊涂脑子里只有个：噢！runner15.6版本以后带参注册被抛弃了，死局。

惊喜地看到一篇文章里一摸一样地报错截图，说是没配置gitlab证书，需要去整个证书，半信半疑的偶然点开了官方文档（就是上面提到的https://docs.gitlab.com/runner/install/docker.html），突然发现里面有提到安装证书的事——这下好了，一边骂自己不看文档，瞎捷报乱查，一边开始整。

于是这个还没意识到i/o timeout的兄弟接着用阿里云服务器开始整https证书了，恰好chen有个项目需要部署前端，他的阿里云整了个域名，于是一发不可收拾

申请免费的阿里云SSL证书：https://blog.csdn.net/gla2018/article/details/127003666

域名是配置在chen的名下的，所以整个证书需要请chen帮忙做DNS解析。然后证书欢欢喜喜批下来了，却发现自己阿里云服务器上的nginx不知道装哪里去了，root find似乎只能扫描/root里的（？）上网搜默认安装的/etc/nginx居然也没有安装到默认位置，属实跌股。

终于在/usr/nginx里找到了文件，然后修改conf发现并没有起作用，上网重新各种搜nginx用法，倒腾一晚上终于决定重装一个，这一装就发现问题了——原来/usr/nginx里放的只是解压了没删的tar.gz安装包，真正configure过的文件放到了/usr/local/nginx里头——改/usr/nginx里的文件有用才怪力。为了方便想root里解压了直接配置到原文件夹力算了，省的之后找不到。于是整出了一堆鲜红ERROR，无奈只能还是配置到/usr/local/nginx里头，然后root里建一个空文件命名nginx_locates_in_usr_local，兜兜转转还是回来了

安装完nginx，睡了

第二天早上起来发现Xshell连不上服务器了，上控制台一看：CPU98%+，实例云盘读写每秒几千次，怕不是被扫了，然后重启。

为域名部署https参考：https://blog.csdn.net/weixin_44192066/article/details/117627342

注意要给开443端口；http中不支持同一个ip在多个server{}中每个代理不同的端口；https不支持location加路径；https不支持号端口访问；子域名配置https需要重新申请SSL证书

但是早上重启后忘了把网页的服务也重启了，一上午瞎整各种404 500 502 403一顿查，终于到饭点了，才发现原来代理的目标网页都还没跑起来，不想多说

吃完饭下午是七夕

回归正题，证书整好了，https整好了，对着那个官方文档一看，好家伙，我gitlab-runner放/srv文件夹下的，/etc下面没有gitlab-runner，死局！

摆了。清理桌面前偶然一看，发现不对劲，这都和我这个错的报的不是一个ERROR啊，搜了那么久的WARNING，咋没想到WARNING是还可以跑，红ERROR才是重点啊。他们有it doesn't contain any IP SANs，有connect: no route to host，就是没有i/o timeout？一查似乎是网络访问的问题，ping了一下，果然是学校内网，本机x 阿里云服务器x 破壁服务器x 挂校园网VPN本机v，好了是时候甩锅给yu老师了。

老师其实人挺不错的，是秒回，说自己今天出来了，明天再来处理然后给我讲讲这个是怎么配的。不过大概也能领会到，毕竟已经放暑假了他也没有义务帮我处理这个烂摊子，于是乎，开始摆烂

（事后诸葛亮：可以参考docker新建gitlab-runner容器的代码，那里将/srv下的/gitlab-runner挂到docker里的/etc下了，所以去docker环境里找是有的，只不过Xftp看不到的啦；此外原文档里说的是Gitlab网页用的是自签发证书的话，那么需要把这个自签发证书放在gitlab-runner里面以便容器能识别，可不是说自己的服务器的SSL证书放在里头）

破局。两天后的一个上午，突然想到chen之前分过一台服务器，居然ping通了，干活！上面这些东西都是没用的，下面这段代码才是重点，而且只需要这段代码就行了

sudo docker run --rm -it -v /srv/gitlab-runner/config:/etc/gitlab-runner gitlab/gitlab-runner register \
  --non-interactive \
  --executor "shell" \
  --docker-image alpine:latest \
  --url "Gitlab主服务器的ip" \
  --registration-token "项目的专有token" \
  --description "springboot" \
  --tag-list "java" \
  --run-untagged="true" \
  --locked="false" \
  --access-level="not_protected"

比较重要的参数解释如下：

--exector 填shell，不要被docker环境蒙蔽了填了"docker"（背后是一天的悲伤故事）

--taglist 表示该runner的标签，.gitlab-ci.yml文件中会有指定tag的字段，用于指定某个过程由带有哪个标签的runner执行

--docker-image 指定使用哪个镜像，这里alpine是一个现成的基础镜像。上网搜索得知gitlab-runner将借助这个镜像实现相关功能，不需要额外定义它，也不要因为没见过改成别的名字

不懂事自建了alpine镜像和容器，但是一建立就被服务器关掉导致一直重启，不知道发生了啥

--url、--registration-token 取自 “项目-设置-CI/CD-runner”。如下图

注册后可以在上图所示的位置查看有没有显示出来

注：这里给出的是specific-runner的构建过程，还有group-runner和shared-runner另外两种类型，有需要可以继续研究

四配置.gitlab-ci.yml文件

这个文件的位置可选的，默认是根目录，构建上传时识别到根目录下有个.gitlab-ci.yml文件，也有可用的runner，就会调用runner里的docker镜像执行yml文件里的代码。当然还可以指定不同分支的变动触发不同的shell代码，具体的各字段表示什么意思以及“流水线是怎么流起来的”可以看这篇文章：https://blog.csdn.net/axibazZ/article/details/118387932，下面贴一份本项目的完整yml代码，学东西还得是有源码学的最快啊啊啊！（震声）

# 定义一些变量, 下面各阶段会使用
variables:
    jar_name: work1-0.0.1-SNAPSHOT.jar
    java_path: /usr/local/java/jdk-17.0.8/bin
    upload_path: /home/dch/recognize/gitlab-runner/

# 定义执行的各个阶段及顺序
stages:
    - build
    - upload
    - deploy

# 使用 maven 镜像打包项目
maven-build:
    stage: build
    script:
      - mvn -B clean package -Dmaven.test.skip=true > /home/gitlab/build1.log 2>&1
    artifacts:
      paths:
      - target/$jar_name
    tags:
      - java
    only:
      - main

# 上传生成的 jar 包到应用服务器相应目录
upload-jar:
    stage: upload
    script:
      - scp target/$jar_name /home/gitlab
    tags:
      - java
    only:
      - main

# 启动 SpringBoot jar包
deploy-test:
    stage: deploy
    script:
      - sh /home/gitlab/restart.sh
    tags:
      - java
    only:
      - main

第一段的variable定义用到的变量，可以看作是宏定义

第二段为流水线定义了3个任务，分别是build -> upload -> deploy

第三段为build阶段，only表示只有提交main分支时才被触发。script内要执行的shell语句，其含义为清理原maven仓库重新构建，并打包项目为jar，存放路径为仓库内代码的根目录/target/下面，使用tag为java的runner运行

第四段表示upload阶段，将jar包移动到相应的执行目录内，只有main分支提交时才触发。

第五段为构建方面，此处编写的shell文件。脚本通过执行脚本即可实现有责杀掉并重写无则直接运行的逻辑，使用标签为JAVA的runner

其中，第四段upload阶段其实还隐藏了一层git fetch的逻辑，从下图中可以看到上传前流水线自动将编译好的文件拉取到docker镜像中/home/gitlab-runner/builds/tEt2Wm3B/0/wallbreaker/background/back-end的奇葩路径下，比较省心的是使用相对路径就可以很简单的将项目内想要的文件复制到目标目录（注意target前面不能有斜杠）

五将yml文件更新到main分支，自动触发试试叭

如果运行流水线时报这样not found的错，多半是docker里面没装这个东西。比如这里是没装maven，已经在前面通过挂载和配置系统变量解决了，自测一下docker内mvn -v输出没问题就没问题了，java -version同理的。（如果注册时--docker-image参数用的不是alpine:latest而改成了普通的my:latest什么的话这里会报sh command not found的错）