GitLab自动部署(CI)

目前GitLab已经有了CI功能,即持续集成的功能。可以实现代码提交后自动测试、编译、发布、部署等自动化工作。关于这一块的内容,网上文章都是语焉不详。最近正需要GitLab自动部署,踩了不少坑,现把配置步骤记录下来,以供大家参考。

目标:代码提交到GitLab上,由GitLab的CI功能自动完成部署。

原理:GitLab在接收到代码提交事件时,通过.gitlab-ci.yml的配置信息与对应节点上的runner进行交互。

实现:如下

1. 安装Runner

Runner服务器可以GitLab所在服务器,也可以是程序需要部署的服务器,也可以是其它服务器。

# 在root下执行
# 下载gitlab-runner
wget https://mirrors.tuna.tsinghua.edu.cn/gitlab-runner/yum/el7/gitlab-runner-10.5.0-1.x86_64.rpm
# 安装
rpm -ivh gitlab-runner-10.5.0-1.x86_64.rpm 

2. 配置Runner(可选)

默认情况,Runner是通过gitlab-runner的这个用户来执行一系列操作,其工作目录也是在gitlab-runner的用户目录下面。如果使用默认gitlab-runner用户操作一些文件时经常会遇到权限问题,就需要给gitlab-runner赋权。我们通过以下方式修改。

# 在root下执行
# 删除服务
gitlab-runner uninstall
# 添加服务
gitlab-runner install --working-directory /home/jack --user jack
# 重启服务
gitlab-runner restart
# 查看状态
gitlab-runner status
输出:gitlab-runner: Service is running!
# 查看是否生效
ps -ef | grep gitlab-runner
输出:root     17454     1  0 Mar23 ?        01:18:03 /usr/bin/gitlab-runner run --working-directory /home/jack --config /etc/gitlab-runner/config.toml --service gitlab-runner --syslog --user jack

3. 注册Runner

把该Runner信息注册给GitLab的CI服务,告诉CI ”我是谁,我能做什么“。

先打开GitLab上需要自动部署的项目界面,找到该项目的Settings –> CI/CD –> Runners settings 。不同版本的GitLab界面可能有些差别。
这里写图片描述

在红色的区域可以看到URL和Token,这两个加起来就是该项目的唯一信息了。然后我们Runner服务的root用户下执行以下命令

# 在root下执行
# gitlab-runner register
WARNING: Running in user-mode.                     
WARNING: The user-mode requires you to manually start builds processing: 
WARNING: $ gitlab-runner run                       
WARNING: Use sudo for system-mode:                 
WARNING: $ sudo gitlab-runner...                   

Please enter the gitlab-ci coordinator URL (e.g. https://gitlab.com/):
http://192.168.1.200/   # 填写刚才看到的URL
Please enter the gitlab-ci token for this runner:
eHMqXjw9ELDy2StsRWXT    # 填写刚才看到的Token
Please enter the gitlab-ci description for this runner:
[dev_srv]:web_dev       # 描述一下该runner,和下面的tags相同即可 
Please enter the gitlab-ci tags for this runner (comma separated):
web_dev                 # 该runner起个名字
Whether to run untagged builds [true/false]:
[false]:                # 直接回车
Whether to lock the Runner to current project [true/false]:
[true]:                 # 直接回车
Registering runner... succeeded                     runner=eHMqXjw9
Please enter the executor: shell, ssh, docker+machine, docker, docker-ssh, parallels, virtualbox, docker-ssh+machine, kubernetes:
shell                  # 填写runner执行时需要使用什么执行器,一般都填shell或者docker。
Runner registered successfully. Feel free to start it, but if it's running already the config should be automatically reloaded! 

这样就完成了Runner与CI之间的信息互注册。Runner知道了自己需要操作哪个项目,CI也知道了该runner的存在。接着刷新一下Runners settings界面,就会看到新注册的Runner了。
这里写图片描述

前面有一个绿色的圆就代表注册成功。

扫描二维码关注公众号,回复: 36892 查看本文章

4. 配置yml文件

在项目根目录下添加一个.gitlab-ci.yml 文件。内容如下:

stages: 
    - deploy
deploy:
    stage: deploy
    script:
      - cp -r * /opt/web
    only:
      - dev
    tags:
      - web_dev

stages下的deploy说明在代码提交后CI需要执行deploy节点的内容。
deploy的script就是一个个shell命令,这里需要注意每个命令都以杠+空格开头。
only:只有向dev分支提交代码时才生效。
tags:只有拥有该tags的Runner才需要执行。

5. 测试

向dev提交一次代码后,打开项目的CI/CD –> Pipelines界面,就可以看到CI的执行记录
这里写图片描述

如果状态为failed或者stucked等,可以点击该状态按钮进入详细界面看到错误信息。

这里写图片描述

6. 分析

为什么在yml中添加cp -r * /opt/web就可以完成部署了?

在安装Runner时,我们说到工作目录,在工作目录下有一个builds目录,Runner的一切工作都在这个目录下面进行。每次提交代码Runner就会自己fetch下代码,所以Runner默认就在本地代码仓库所在路径下。所以直接执行cp -r * /opt/web就可以把程序都复制过去了。当然,大家可以加上编译的命令,然后再部署。任你发挥。

猜你喜欢

转载自blog.csdn.net/WMSOK/article/details/80017467