Gitlab+Docker实现持续集成(CI)与持续部署(CD)


prtyaa
prtyaa 2023-12-31 22:43:07 63869
分类专栏: 资讯

GitLab CI/CD介绍

首先使用一张图说明GitLab CI的工作流程:


GitLab CI是 GitLab 提供的持续集成服务,只要在你的仓库根目录 创建一个.gitlab-ci.yml 文件, 并为该项目指派一个Runner,当有合并请求或者 push的时候就会触发build。

这个.gitlab-ci.yml 文件定义GitLab runner要做哪些操作。默认有3个默认有3个[stages(阶段)]: build、test、deploy。

当build完成后(返回非零值),你会看到push的 commit或者合并请求前面出现一个绿色的对号。这个功能很方便的让你检查出来合并请求是否会导致build失败, 免的你去检查代码。

大部分项目用GitLab’s CI服务跑build测试, 开发者会很快得到反馈,知道自己是否写出了BUG。

所以简单的说,要让CI工作可总结为以下几点:

在仓库根目录创建一个名为.gitlab-ci.yml 的文件
为该项目配置一个Runner
完成上面的步骤后,每次push代码到Git仓库, Runner就会自动开始pipeline。

配置Runner

详细的使用说明,请阅读官方文档:docs.gitlab.com/runner/

安装GitLab-Runner

#在ubuntu server16.04版本下使用命令即可安装
$ sudo wget -O /usr/local/bin/gitlab-runner https://gitlab-runner-downloads.s3.amazonaws.com/latest/binaries/gitlab-runner-linux-amd64

#接着授予可执行权限
$ sudo chmod +x /usr/local/bin/gitlab-runner

#创建一个gitlab-ci用户
$ sudo useradd --comment 'GitLab Runner' --create-home gitlab-runner --shell /bin/bash

#安装,并作为服务启动
$ sudo gitlab-runner install --user=gitlab-runner --working-directory=/home/gitlab-runner

至此,安装工作完成,接下来需要注册Runner,来将Runner和Gitlab绑定到一起。

其他系统安装参考

docs.gitlab.com/runner/

注册Runner

  • 输入命令
$ sudo gitlab-runner register

会要求输入gitlab的url和Token.
查找过程如下:
进入仓库->settings->CI/CD,找到Runner Settings这一项,点击Expend,即可在Setup a specific Runner manually这项中找到。如下:

 

注意,其他版本位置可能会不同

其中的url和Token就是遮起来的内容,只需要在注册过程中填入即可。


当这些做完之后启用命令启动Runner

$gitlab-runner run

教程上说是使用gitlab-runner start命令,但我试的时候并没有生效,但是用了gitlab run就可以了,建议先使用gitlab-runner start试一下,不行再用gitlab-runner run
启动成功后就可以看到,gitlab对应的仓库下(操作:进入仓库->settings->CI/CD,找到Runner Settings这一项,点击Expend,即可在Setup a specific Runner manually)看到注册的runner已经在运行了。


注:如果状态颜色是灰色的表示没有运行成功,也可以选择“Pause”和“Remove Runner”

自动化测试

创建.gitlab-ci.yml

.gitlab-ci.yml 介绍

  • .gitlab-ci.yml 用来配置 CI 用你的项目中做哪些操作,这个文件位于仓库的根目录。
  • 当有新内容push到仓库后,GitLab会查找是否有.gitlab-ci.yml文件,如果文件存在, Runners 将会根据该文件的内容开始build 本次commit。
.gitlab-ci.yml 使用YAML语法, 你需要格外注意缩进格式,要用空格来缩进,不能用tabs来缩进。

创建.gitlab-ci.yml

因为本人项目基本都是Gradle构建的,Gradle进行单元测试比较简单,只需要使用gradle test即可运行所有的单元测试

  • 新建一个.gitlab-ci.yml文件,并完成如下内容
stages:
  - build
  - test

before_script:
  - echo "Restoring Packages..."

build_job:
  stage: build
  script:
  - echo "Release build..."
  except:
  - tags

test_job:
  stage: test
  script:
  - echo "Tests run..."
  - cd cds.ci.test
  - gradle test
stage翻译为阶段的意思,在构建的过程中,必须要有一个先后顺序。最上面的stages配置意思是,先构建阶段为build的job,然后再构建阶段为test的job,下面build_job和test_job都是job,如果不配置stages,默认为:
stages:
  - build
  - test
  - deploy

推送配置文件

配置好.gitlab-ci.yml文件之后,只要把它加入git后然后推送到远程仓库,CI就会开始自动化集成。这样我们提交代码到GitLab是在每次提交的后面都会有自动测试的结果


如果失败了,也可以进入对应的阶段,查找错误原因。gitlab提供了可视化的界面,非常方便。

 

代码审查

安装Docker

  • 由于apt官方库里的docker版本可能比较旧,所以先卸载可能存在的旧版本:
$ sudo apt-get remove docker docker-engine docker-ce docker.io
  • 更新apt包索引:
$ sudo apt-get update
  • 安装以下包以使apt可以通过HTTPS使用存储库:
$ sudo apt-get install -y apt-transport-https ca-certificates curl software-properties-common
  • 添加Docker官方的GPG密钥
 $ curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -
  • 使用下面的命令来设置stable存储库
$ sudo add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable"
  • 再更新以下apt包索引
$ sudo apt-get update
  • 列出可用的版本
$ apt-cache madison docker-ce
  • 选取要安装的特定版本
$ sudo apt-get install docker-ce=<VERSION>

SonarQube介绍

安装SonarQube

  • 获取postgresql的镜像
 $ docker pull postgres
  • 启动postgresql
 $ docker run --name db -e POSTGRES_USER=sonar -e POSTGRES_PASSWORD=sonar -d postgres
  • 获取sonarqube的镜像
 $ docker pull sonarqube
  • 启动sonarqube
$ docker run --name sq --link db -e SONARQUBE_JDBC_URL=jdbc:postgresql://db:5432/sonar -p 9000:9000 -d sonarqube
  • 将sonar-gitlab-plugin-2.1.0.jar添加到docker中的sonarqube容器中
$ docker cp sonar-gitlab-plugin-2.1.0.jar sonarqube:/opt/sonarqube/extensions/plugins

打开http://localhost:9000 点击login
用户名密码均默认为admin

 

Gradle集成SonarQube

代码审查可以使用Gradle集成Sonarqube。整体来说,共分为三步:

  • 在build.gradle中添加配置,启动sonarqube插件
  • 配置sonar系统认证权限信息,以便将分析结果上传到sonar中展示;
  • 运行分析命令:gradle sonarqube,然后就可以在sonarqube页面上看到分析结果。

但我们需要在gitlab上进行持续集成,所以我们将gradle sonarqube命令写入到.gitlab-ci.yml脚本中,在提交代码到gitlab是执行。
首先对build.gradle进行配置:

buildscript {
    repositories {
        # 添加库路径,实际项目中原来此处可能还有别的库,在此位置追加。追加库的位置可能会导致项目报错(找不到某些依赖的错误)
        maven { url "http://192.168.109.63:8081/nexus/content/groups/public/" }
    }

    dependencies {
        #在此位置追加一下依赖行
        classpath "org.sonarsource.scanner.gradle:sonarqube-gradle-plugin:2.6.2"
    }
}


plugins {
    # plugins段放置位置有要示,放在buildscript段前面会报错,放到文件最末尾也报错,紧跟buildscript放置OK
    #添加插件信息
    id "org.sonarqube" version "2.6-rc1"
}

apply plugin: "org.sonarqube"

subprojects {
    sonarqube {
       # 如果同时存在src/main/java与src/main/test,则要按以下方式设置,如果没有单元测试用例目录test,也可以只填写src
        properties {
            property "sonar.sources", "src/main/java"
        }
    }
}

#配置sonarqube的权限信息
sonarqube{
 properties {
  property "sonar.host.url", "http://192.168.90.58:9000"
  property "sonar.projectName", "${artifactIdParam}"
  property "sonar.projectKey", "${artifactIdParam}"
  property "sonar.projectVersion", "${versionParam}"
        property "sonar.login","admin"
        property "sonar.password","admin"
 }
}

完成gradle与sonar的集成后,接下来需要编写.gitlab-ci.yml脚本,增加执行代码审查的脚本。

code_review
  stage: test
  script:
  - echo "Start reviewing code"
  - gradle sonarqube  

完成之后提交代码到gitlab,即可显示执行结果。

# plugins段放置位置有要示,放在buildscript段前面会报错,放到文件最末尾也报错,紧跟buildscript放置OK
plugins {
    #添加插件信息
    id "org.sonarqube" version "2.6-rc1"
}
#声明插件
apply plugin: "org.sonarqube"

subprojects {
    sonarqube {
       # 如果同时存在src/main/java与src/main/test,则要按以下方式设置,如果没有单元测试用例目录test,也可以只填写src
        properties {
            property "sonar.sources", "src/main/java"
        }
    }
}

sonarqube{
 properties {
  property "sonar.host.url", "http://192.168.90.58:9000"
  property "sonar.projectName", "${artifactIdParam}"
  property "sonar.projectKey", "${artifactIdParam}"
  property "sonar.projectVersion", "${versionParam}"
        property "sonar.login","admin"
        property "sonar.password","admin"
 }
}

至此gradle集成SonarQube完成,接下来需要编写脚本并上传

编写.gitlab-ci.yml

在刚才的自动化测试脚本里追加如下内容:

code_review:
  stage: test
  script:
  - echo "Start reviewing code"
  - gradle sonarqube

这样在提交代码到远程仓库时即可实现代码审查。结果如下:


进入项目下就可以看到具体的代码审查结果

 

自动化部署

要实现自动部署,需要在.gitlab-ci.yml中指定执行的脚本,与自动化测试类似。

stages:
  - deploy
deploy:
    stage: deploy
    script:
      - echo "start deploy....."
    only:
      - master
    tags:
      - shell

这里我们只有一个stage是deploy。only指定了只有在master分支push的时候才会被执行。tags是shell,对应了刚才注册runner的时候的tags。
这是一个最简单的执行模块,在实际开发中我们要通过一个shell脚本来将资源自动部署到指定位置。例如修改脚本如下:

stages:
  - deploy
deploy:
    stage: deploy
    script:
      - echo "start deploy....."
      - deploy
    only:
      - master
    tags:
      - shell

其中deploy是编写的shell脚本,可以实现将要发布的内容自动部署到发布目录下:

#!/bin/bash
deploy_path="/home/xuda/tomcat8/webapps"
project_path="gitlab_ci_cd_test";
judge_path = "$deploy_path/$project_path"
if [ ! -d "$judge_path" ]
then
   project_url="http://XXXXcom/xuda/gitlab_ci_cd_test.git"
   git clone $project_path $deploy_path
else
   cd $deploy_path
   git pull
fi

这个脚本的大意就是,先判断tomcat的webapps下有没有gitlab_ci_cd_test文件夹,如果目录不存在,那么就在webapps文件夹下git clone一个,如果存在了就git pull一个到指定目录下。这样就实现了自动部署,我们同样可以在gitlab的仓库下看到结果


最后,附上一张gitlab仓库的项目结构图

 

总结

GitLab的持续集成持续部署的功能还是很强大的。因为刚毕业进入这家公司看到他们的持续集成做的非常棒,所以学习了基本的安装。如果想要完成比较复杂的功能也是完全可以实现的,这时可以结合Shell脚本来操作。因为水平有限,如果有问题可以提出,学习交流。

 

网站声明:如果转载,请联系本站管理员。否则一切后果自行承担。

本文链接:https://www.xckfsq.com/news/show.html?id=33430
赞同 0
评论 0 条
prtyaaL0
粉丝 1 发表 2554 + 关注 私信
上周热门
银河麒麟添加网络打印机时,出现“client-error-not-possible”错误提示  1319
银河麒麟打印带有图像的文档时出错  1232
银河麒麟添加打印机时,出现“server-error-internal-error”  1018
统信桌面专业版【如何查询系统安装时间】  948
统信操作系统各版本介绍  941
统信桌面专业版【全盘安装UOS系统】介绍  899
麒麟系统也能完整体验微信啦!  886
统信【启动盘制作工具】使用介绍  496
统信桌面专业版【一个U盘做多个系统启动盘】的方法  437
信刻全自动档案蓝光光盘检测一体机  383
本周热议
我的信创开放社区兼职赚钱历程 40
今天你签到了吗? 27
信创开放社区邀请他人注册的具体步骤如下 15
如何玩转信创开放社区—从小白进阶到专家 15
方德桌面操作系统 14
我有15积分有什么用? 13
用抖音玩法闯信创开放社区——用平台宣传企业产品服务 13
如何让你先人一步获得悬赏问题信息?(创作者必看) 12
2024中国信创产业发展大会暨中国信息科技创新与应用博览会 9
中央国家机关政府采购中心:应当将CPU、操作系统符合安全可靠测评要求纳入采购需求 8

添加我为好友,拉您入交流群!

请使用微信扫一扫!