GitLab-CI 这个是一套配合GitLab使用的持续集成系统,是GitLab自带的,也就是你装GitLab的那台服务器上就带有的。无需多考虑。.gitlab-ci.yml的脚本解析就由它来负责。java
GitLab-Runner 这个是脚本执行的承载者,.gitlab-ci.yml的script部分的运行就是由runner来负责的。GitLab-CI浏览过项目里的.gitlab-ci.yml文件以后,根据里面的规则,分配到各个Runner来运行相应的脚本script。这些脚本有的是测试项目用的,有的是部署用的。git
GitLab-CI与GitLab-Runner关系示意图web
安装GitLab-Runner 在centOS上安装gitlab-ci-multi-runnershell
这样就装好了gitlab-ci-multi-runner,然而咱们只是装好了gitlab-runner,固然咱们要接着向gitlab-CI注册这个runner,否则gitlab-CI在push事件到来的时候怎么知道要调用谁呢?这里也能够发现和webhook方式的区别,webhook方式是咱们主动配置了一个链接给gitlab;gitlab-runner只要注册一下就行了。apache
那么咱们就注册一下tomcat
而后就注册好了,在gitlab中相应的位置就能够看到你注册好的runner信息。ruby
$ curl -L https://packages.gitlab.com/install/repositories/runner/gitlab-ci-multi-runner/script.rpm.sh | sudo bash
bash
$ yum install gitlab-ci-multi-runner
服务器
$ gitlab-ci-multi-runner register
app
#引导会让你输入gitlab的url,输入本身的url,例如http://gitlab.example.com/
#引导会让你输入token,去相应的项目下找到token,例如ase12c235qazd32
#引导会让你输入tag,一个项目可能有多个runner,是根据tag来区别runner的,输入若干个就行了,好比web,hook,deploy
#引导会让你输入executor,这个是要用什么方式来执行脚本,图方便输入shell就行了。
编写.gitlab-ci.yml
在项目根目录下编写.gitlab-ci.yml这样在push以后,gitlab-ci就会自动识别来解析了
stages: - deploy - build - ops deploy-web1_job: stage: deploy tags: - gitRunner的tag标签 only: - master script: - bash deploy 项目分组名 项目名 master build-web1_job: stage: build tags: - gitRunner的tag标签 only: - master script: - source /etc/profile - cd /data/wwwroot/master/项目分组名/项目名 - /data/wwwroot/apache-maven-3.6.0/bin/mvn clean package -Dmaven.test.skip=true ops-web1_job: stage: ops tags: - gitRunner的tag标签 only: - master script: - rm -f /data/wwwroot/tomcat/apache-tomcat-8.5.35/webapps/项目名.war - cp /data/wwwroot/master/项目分组名/项目名/target/项目名.war /data/wwwroot/tomcat/apache-tomcat-8.5.35/webapps/项目名.war
这里咱们只有一个stage是deploy。only指定了只有在master分支push的时候才会被执行。tags是shell,对应了刚才注册runner的时候的tags。
最重要的script部分deploy Example_Group Example_Project,这里是一条shell指令,为了方便通用性,deploy是我在服务器上编写的一个脚本,传入参数是Example_Group Example_Project分别是项目组名和项目名。执行这一条指令就可以自动部署到/xxx/Example_Group/Example_Project的服务器目录下。那么随便什么项目都用这个格式去套就行了,这样新项目的自动部署也不须要登陆到服务器上去修改了。
编写deploy脚本
在gitlab-runner的~/.local/bin/目录下新建deploy文件
$ su gitlab-runner
$ mkdir ~/.local/bin
$ cd ~/.local/bin
$ touch deploy
并编辑成以下内容
if [ $# -ne 3 ] then echo "arguments error!" exit 1 else deploy_path="/data/wwwroot/$3/$1/$2" if [ ! -d "$deploy_path" ] then git clone "gitlab服务器地址:${1}/${2}.git" $deploy_path cd $deploy_path git checkout $3 else cd $deploy_path git pull fi fi
加上执行权限,而后把这个脚本放在gitlab-runner的~/.local/bin下就能够生效了(为了避免用写难看的./deploy)
$ chmod +x ~/.local/bin/deploy
而且把~/.local/bin加到$PATH路径中(用户执行命令时候可以查找到这个目录),只要在~/.profile末尾加入这一句话
PATH="$HOME/.local/bin:$PATH"
配置ssh登陆
上面的deploy脚本是用ssh方式来和gitlab联系的。因此要给gitlab-runner这个用户配置一个gitlab上能ssh的用户。首先在gitlab-runner下生成一个密钥对
$ mkdir ~/.ssh
$ cd ~/.ssh
$ ssh-keygen
# 提示输入一直按回车默认就能够了
$ cat id_rsa.pub
移交部署目录权限
有些同窗可能说脚本执行失败了,有一个缘由是/var/example的全部者是root,gitlab-runner并无权限新建文件。因此咱们把/var/example目录的全部者交给gitlab-runner
$ chown -hR gitlab-runner:gitlab-runner /var/www
若是仍是不成功,能够在服务器上手工deploy XX XX一次,第一次访问这个服务器的时候,有个命令行提示是要把sign添加进已知服务器列表,须要手工输入个yes。若是在服务器上可以正常deploy,那么
这样就大功告成了。
注:若是在发布运行的过程当中一直报ssh的密钥验证不经过 则执行这个: ssh-keyscan -H 服务器ip >> ~/.ssh/known_hosts