极狐Runner修复
首先需要注意使用docker方式安装runner而不是服务器方式安装runner,这样不仅安装简单,还有利于后续对runner的配置。
获取权限
要注册一个group runner,首先要获取这个runner的Onwer权限,这里就是需要获得CS4ALL这个group的Owner权限,获取权限后,可以对这个组的runner进行配置,如下图所示:
安装与注册Runner
可以在runner界面点击“Register a group runner”按钮,再点击红框所示按钮获取安装方法。Docker方式安装的指导链接是https://docs.gitlab.com/runner/install/docker.html。
这里我采取了阿里云文档中介绍的安装方法https://developer.aliyun.com/article/719968,比较通俗易懂。
拉取Runner镜像并启动
1 | 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 |
进入Runner容器内
1 | docker exec -it gitlab-runner bash |
注册Runner
1 | gitlab-runner register |
输入Gitlab实例的地址
1 | > Please enter the gitlab-ci coordinator URL (e.g. https://gitlab.com ) |
这里注意不要直接默认,因为默认直接默认的是Gitlab地址https://gitlab.com,这里需要输入极狐地址https://jihulab.com/,否则下一步输入极狐的token就会一直出错……
输入token
1 | > Please enter the gitlab-ci token for this runner |
复制上图中的“Registration token”输入
输入Runner的描述
1 | > Please enter the gitlab-ci description for this runner |
相当于执行CI/CD时显示的runner名称,比如“shuishan test environment runner”
输入与Runner关联的标签
1 | > Please enter the gitlab-ci tags for this runner (comma separated): |
输入相关标签,==.gitlab-ci.yml==文件会根据标签为选择相应的runner来执行各个Job,比如“shuishan”
输入Runner的执行器
1 | > Please enter the executor: ssh, docker+machine, docker-ssh+machine, kubernetes, docker, parallels, virtualbox, docker-ssh, shell: |
由于是Docker方式安装,这里输入“docker”
设置执行器的版本
1 | > Please enter the Docker image (eg. ruby:2.1): |
这里选择之前runner的Docker镜像ccchieh/centos-common
,如果选择了别的镜像也没关系,后续可以再进行配置
退出容器
1 | exit |
执行以上步骤后,就完成了runner的安装与注册,也就可以在runner管理界面看到新的runner了。
配置Runner
接下来修改Runner配置文件对runner进行配置,runner配置文件在服务器上的存储位置是/srv/gitlab-runner/config/config.toml
,如果有连接终端有可视化文件系统的话就可以直接打开文件对配置进行修改,否则可以使用vim对其进行修改:
1 | vim /srv/gitlab-runner/config/config.toml |
找到volumes
配置,修改为:
1 | volumes = ["/cache","/var/run/docker.sock:/var/run/docker.sock","/data/.m2:/root/.m2","/usr/bin/docker:/usr/bin/docker","/root/.ssh:/root/.ssh","/root/.docker:/root/.docker"] |
volumes
配置及其作用见下表:
配置 | 作用 |
---|---|
/var/run/docker.sock:/var/run/docker.sock | docker daemon监听的套接字socket(ip+port),容器中的进程可以通过它与docker daemon通信 |
/data/.m2:/root/.m2 | 减少拉取Jar包的时间,左边为宿主机目录,右边为容器内的Jar包存储路径. |
/usr/bin/docker:/usr/bin/docker | 使runner在执行作业时可以执行docker命令,否则在执行流水线时会出现以下错误:![]() |
/root/.ssh:/root/.ssh | 使runner在执行作业时可以执行ssh命令 |
/root/.docker:/root/.docker | 使runner在执行作业时可以根据宿主机的docker login信息拉取私有仓库的镜像 |
接着在在volumes
配置下方增加一行配置,防止Runner重复拉取镜像:
1 | pull_policy = "if-not-present" |
最后重启Runner即可:
1 | docker restart gitlab-runner |
其余细节(如runners.cache、runners.custom_build_dir)可见以下完整的config.toml
文件:
1 | concurrent = 1 |
gitlab runner容器实现CI/CD流水线的原理
这里执行流水线的操作并不是由
gitlab-runner
这个容器执行的,每执行一条流水线,gitlab-runner
这个容器就会根据config.toml
里面配置去重启一个容器,这个容器才是真正的runner,用来执行这条流水线。如果运行一条流水线,在服务器上手速快点就可以看到这样的现象,新建了一个容器,等这个流水线跑完,容器就会删除。
config.toml
里面的volumes
挂载,实际上也是从服务器挂载到这个新建的容器里面去的,所以在gitlab-runner
这个容器里看不到==/usr/bin/docker==、==/root/.ssh==、==/root/.docker==这些文件夹才是对的。要注意这种挂载和容器启动时的docker run -v
挂载
服务器的配置
在服务器上也需要完成一定的配置,使runner在执行一些指令时具有相应的访问权限。
docker拉取私有镜像权限
服务器的docker需要登录阿里云私有镜像仓库的账号,使用docker login
命令完成登录:
1 | docker login --username=shuishan@1224904496484627 registry.cn-shanghai.aliyuncs.com |
登录完成后会在服务器的/root/.docker/config.json
里面保存凭证,在上面的配置中我们已经配置好了这个文件夹的挂载,所以runner就可以在正常执行一些拉取远端私有镜像的操作,否则runner在执行流水线时可能会出现以下报错:
ssh连接测试服务器权限
在测试环境流水线中需要ssh连接测试服务器完成一些镜像删除、容器部署的操作,所以需要使gitlab-runner容器所在的服务器具有远程ssh连接测试服务器的权限,可以按照如下操作完成配置:
生成公钥文件
在runner所在服务器上执行以下命令:
1 | ssh-keygen -t rsa |
程序会问你存放目录,如果不需要修改,直接回车几次即可在~/.ssh
目录下生成该主机的公钥文件id_rsa.pub
,复制该文件内容。
导入公钥文件内容
进入测试服务器的~/.ssh
目录,找到authorized_keys
文件,往该文件写入上一步复制的公钥文件内容。
测试ssh连接
在runner所在服务器上执行以下命令:
1 | ssh TEST_SERVER_ADDR |
TEST_SERVER_ADDR为测试服务器地址,首次连接可能会出现以下信息:
1 | The authenticity of host '[host]:12222 ([xxx.xxx.xx.xxx]:12222)' can't be established. |
这是为了确认是否是我们需要真正连接的服务器 而不是中间人的服务器,直接输入yes
即可,这样就会把连接服务器的相关信息写入~/.ssh/known_hosts
文件中,之后再连接同一服务器时就不会再出现这个确认信息了。
在上面的配置中我们已经配置好了~/.ssh
这个文件夹的挂载,所以runner就可以在正常执行一些ssh连接测试服务器,否则runner在执行流水线时可能会出现以下报错:
其他
当完成以上操作后,此时流水线已经可以正常执行了,此时可以将所有服务(包括前端和后端,除了超级管理员前后端,那个运行流水线需要相关权限,比较麻烦)中之前失败的或最新一次的流水线重新运行一下,在新的服务器运行第一次流水线,包括构建和部署等操作。因为第一次操作需要下载大量的Maven Jar包,所以构建时间较长,先执行一次流水线不仅可以测试runner是否已经正常,还可以减少后面流水线的运行时间。