gitlab cicd配置

gitlab cicd配置简介以前代码更新之后,我们需要手动将代码拉到测试服务器上,运行验收通过之后,再在生产环境重新弄一遍,一两个服务还算轻松,如果涉及到的服务很多的话,每一个服务都需要这样来几遍,这是一个很头疼了,为了解决这个问题,我们引入了比较简单易懂的自动化部署工具,这也是gitlab自带的CI工具gitlab-runner,该工具解决了多环境多服务手动部署繁琐问题,用自动化脚本代替人工部署,我们不需要手…

大家好,又见面了,我是你们的朋友全栈君。

 

简介

以前代码更新之后,我们需要手动将代码拉到测试服务器上,运行验收通过之后,再在生产环境重新弄一遍,一两个服务还算轻松,如果涉及到的服务很多的话,每一个服务都需要这样来几遍,这是一个很头疼了,为了解决这个问题,我们引入了比较简单易懂的自动化部署工具,这也是gitlab自带的CI工具gitlab-runner,该工具解决了多环境多服务手动部署繁琐问题,用自动化脚本代替人工部署,我们不需要手动去部署单个服务,可以机械化的执行我们的部署过程。那么一个项目如何配置gitlab CI来实现自动部署呢,主要分两步(前提条件时已经又gitlab-runner服务了):

  • 注册runner

  • 配置.gitlab-ci.yml

安装gitlab-runner

下载rpm

wget https://gitlab-runner-downloads.s3.amazonaws.com/latest/rpm/gitlab-runner_amd64.rpm

rpm安装

rpm -i gitlab-runner_amd64.rpm

修改工作目录

sudo cat /etc/init.d/gitlab-runner 
#!/bin/sh
# For RedHat and cousins:
# chkconfig: - 99 01
# description: GitLab Runner
# processname: /usr/lib/gitlab-runner/gitlab-runner
​
# Source function library.
. /etc/rc.d/init.d/functions
​
name="gitlab-runner"
desc="GitLab Runner"
user=""
cmd=/usr/lib/gitlab-runner/gitlab-runner
args=" "run" "--working-directory" "/home/**/workspace/cicd" "--config" "/etc/gitlab-runner/config.toml" "--service" "gitlab-runner" "--syslog" "--user" "my_user""
lockfile=/var/lock/subsys/$name
pidfile=/var/run/$name.pid
​
# Source networking configuration.
[ -r /etc/sysconfig/$name ] && . /etc/sysconfig/$name
​
  • 修改–working-directory –user 两个字段

注册runner

连接上运行了gitlab-runner服务的机器(我们采用的是117.50.*.12生产环境部署的runner),使用sudo gitlab-runner register来注册runner,输入命令后,会进入一个交互式命令窗口用来设置runner的配置信息,之后就会向gitlab服务(代码管理服务端)发起一个注册runner的请求,该runner就是后续我们用来执行脚本的执行者。以下是交互界面内容:

> sudo gitlab-runner register
​
Enter your GitLab instance URL:(填写GitLab的url)
Please enter the gitlab-ci coordinator URL (e.g. http://gitlab.com )
> 我们gitlab服务在内网(192.168.10.10),生产环境(运行了gitlab-runner)又是外网,直接访问不到,我们用生产环境的一个端口映射到内网服务器上来解决问题(`http://*.*.*.*:24380/git`映射到了`http://192.168.10.10/git`),所以如果是内网(192.168.10.10)那个gitlab项目的话,这里固定填`http://*.*.*.*:24380/git`,其他情况以自己gitlab为主。 
​
http://*.*.*.*:24380/git  
​
Enter the token you obtained to register the Runner:(填写GitLab的token信息)
Please enter the gitlab-ci token for this runner
> #在gitlab **项目** 的设置界面,找到CI/CD选项,可以找到runner选项卡,点击展开,可以看到可供选择的runner类型,找到**specificRunner**配置,可以看到配置步骤,第一项就是上一步要填的东西,我们copy第二步提示的token,填入即可。
​
3JyBpz5Sd********
​
Enter a description for the Runner, you can change this later in GitLab's UI:(runner的描述)
Please enter the gitlab-ci description for this runner
> runner描述信息填在这,后续可更改
> 描述文字
​
Enter the tags associated with the Runner, you can change this later in GitLab's UI:(runner的标签,用逗号分开)
Please enter the gitlab-ci tags for this runner (comma separated):
> runner的tag值,后续触发job的时候会根据配置文件里面的tag值,找到对应的runner来执行,所以这个至关重要,如果这个配置的与.gitlab-ci.yml文件里的不一致,会导致一直加载runner信息(轮询一个定时器去拉取runner信息,找不到就一直加载,查看job执行情况的时候,就一直在就绪状态),这个值后续也可以改,多个tag用‘,’隔开。 
​
my-tag,test 
​
Enter the Runner executor: (runner的执行者)
Please enter the executor: ssh, docker+machine, docker-ssh+machine, kubernetes, docker, parallels, virtualbox, docker-ssh, shell:
> 指定执行脚本的容器,我们这里因为部署比较简单,使用shell脚本来执行。
​
shell   

完成这些配置后,我们在设置-CI/CD-runner界面就可以看到刚刚注册的runner基本信息,正常情况,左侧的状态应该是绿色,如果是黑色,请检查runner配置是否正确,gitlab-runner服务是否正常启动,当看到其状态为绿色时,runner的注册工作就已经完成了。如图:

注意: 因为gitlab-runner与gitlab访问不通的问题(也就是上诉第一步的问题),导致runner在拉取git代码失败,我们需要手动改配置信息,找到/etc/gitlab-runner/config.toml文件中刚刚注册的runner,添加一个属性clone_url = "http://*.*.*.*:24380/git",该属性会覆盖gitlab返回给runner的项目clone地址,这样我们runner在拉取代码的时候,就会优先使用该地址。

sudo vim /etc/gitlab-runner/config.toml
concurrent = 1
check_interval = 0
​
[session_server]
session_timeout = 1800
​
[[runners]]
name = "web server"
url = "http://*.*.*.*:24380/git"
token = "533*********641a643f25eaae"
executor = "shell"
clone_url = "http://*.*.*.*:24380/git"
[runners.custom_build_dir]
[runners.cache]
  [runners.cache.s3]
  [runners.cache.gcs]
​
​
  • 增加clone_url 字段

配置.gitlab-ci.yml

当有代码改动时,gitlab就会解析这个配置文件,根据里面的配置信息,那些情况的改动,触发哪些job,指派那个runner来执行什么样的脚本,都可以通过.gitlab-ci.yml这个文件来配置,初次配置,可以先执行一条语句来检验。 初次配置项目的CI,可以在项目首页,看到添加CI/CD这个选项,添加相应的.gitlab-ci.yml,提交就能触发自动化部署。

stages:
- test
job1:
stage: test
script:
- echo "============================="
- ps aux | grep "uwsgi" | grep -v "grep"
- cd /home/***/workspace/server
- echo "============pull code========"
- git pull
- psid=`ps aux | grep "server_uwsgi" | grep -v "grep" | wc -l`
- psid=${psid:=0}
- if [ $psid -gt 2 ];then
-   echo "uwsgi service is reloading...."
-   source venv/bin/activate
-   uwsgi --reload uwsgi_pid.pid
- else
-   echo "uwsgi service is starting"
-   source venv/bin/activate
-   uwsgi --ini uwsgiconfig.ini
- fi
- ps aux | grep "uwsgi" | grep -v "grep"
- echo "uwsgi service start success"
tags:
  - hotel_web_server
only:
  - online_temp

这里的job1是自定义的名称,随便什么都可以,stage就是这个job的名称,script关键字是每一个job必须有的,后面接脚本语言,tags指定那个runner来执行job,stages指每一次触发自动部署,执行job的顺序,里面的值对应job里面的stage属性值,一个简单的自动化部配置就完成了。 进入CI/CD控制台界面,如图: 流水线: 一个流水线表示每次提交代码触发的一整个流程,一个流水线包含多个job job: 记录单个任务执行情况,后面有执行状态,红色表示执行失败,绿色表示执行成功,点击每个job的图标,可以进入该job执行的控制台界面,查看执行情况,这里我们能看到异常情况,和我们自己编写脚本的输出情况,如图:

至此,一个简单的CI流程就走完了,我们可根据自己项目需要,编写合适的.gitlab-ci.yml文件,比如前端项目的部署就是npm run build,java web的就是java -jar xxx.jar >/dev/null 2>&1 &等,也可控制其部署流程,比如develop分支的代码部署到开发环境,master的代码部署到生产环境等等,一切看自己怎么去控制了,相关高阶应用可查看官方文档

版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 举报,一经查实,本站将立刻删除。

发布者:全栈程序员-用户IM,转载请注明出处:https://javaforall.cn/132981.html原文链接:https://javaforall.cn

【正版授权,激活自己账号】: Jetbrains全家桶Ide使用,1年售后保障,每天仅需1毛

【官方授权 正版激活】: 官方授权 正版激活 支持Jetbrains家族下所有IDE 使用个人JB账号...

(0)


相关推荐

发表回复

您的电子邮箱地址不会被公开。

关注全栈程序员社区公众号