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

简介

以前代码更新之后，我们需要手动将代码拉到测试服务器上，运行验收通过之后，再在生产环境重新弄一遍，一两个服务还算轻松，如果涉及到的服务很多的话，每一个服务都需要这样来几遍，这是一个很头疼了，为了解决这个问题，我们引入了比较简单易懂的自动化部署工具，这也是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的代码部署到生产环境等等，一切看自己怎么去控制了，相关高阶应用可查看官方文档