使用gitlab-ci搭建CI,CD平台

之前项目刚刚起步，所有的前后端项目上测试环境，上正式环境都是在本地去打包，然后传到服务器上去启动。这就非常麻烦，这样的一个很大的缺点是不方便代码的管理，在本地打包，如果打包的人代码没提交，下次上线，另外一个人打包可能就有代码缺失的风险，多搞几次，都不知道线上代码到底是什么样了。而且有的是要横向部署多个，手动传包就更麻烦。于是我这边就研究了自动部署的方法，然后就可以省些这种麻烦的事。

首先什么是CI,CD

• CI : Continuous Integration

持续集成，主要是在代码提交后，自动执行一些测试案例，和代码质量扫描。
保证本次代码提交没问题

• CD : Continuous Deployment

自动部署，主要是代码检查过后，然后就会自动部署到测试环境，或者正式环境。
把打包，备份，停止，启动等等操作让机器自动执行。

这篇文章的目的，就是让大家了解自动部署，然后可以手动搭建一套包括代码质量扫描，自动部署的一套代码管理平台应用(通过gitlab-ci)，以及了解自动部署相关代码分支管理的东西。（在提交代码的时候，使用sonar扫描java代码，生成代码质量分析报告，然后再自动部署项目的方法。）

代码管理

我们所有的代码都是基于 gitlab 去管理的，所以这里默认你有一个搭建好的 gitlab 服务。

技术选型

现在最主流的ci，cd软件是jenkins, 以前的方案也是使用jenkins，我觉得它很好，功能齐全，插件很多，但是我觉得他比较重量级，如果团队规模大，运维测试团队分离，使用jenkins会更合适。而我们团队规模不大，上线，上测试基本都是开发自己去完成，基本是 dev-ops 的开发模式，我这里经过调研后就选择了更轻量级的gitlab-ci,在能完成我们所需所有功能的前提下更方便我们使用。

gitlab-ci的优点

• 和gitlab高度耦合，支持非常好（gitlab上就有ci-cd和脚本执行过程等等很多写好的页面，直接使用）
• 只需要安装一个 gitlab-ci-runner, 安装非常简单
• 所有部署的脚本都是基于 .gitlab-ci.yml 去执行，只要会写脚本，那么这里可以通过shell脚本做任何事情，控制感非常强

在开始部署使用之前，我想说一下自动部署的原理和流程

先手动部署的流程

• 我们开发，写代码
• 可能这里需要跑测试用例以及代码扫描
• 本地执行命令打包（例如jar包，这里需要有相关的软件环境如maven）
• 手动传包到服务器的对应地方
• 然后手动执行重启脚本
• 部署完成

我们就是要把上面的一系列的动作全部自动交给机器去执行。然后触发的机制就gitlab上代码的变动。(把本地打包，传包，停止应用，启动应用的步骤交给机器脚本执行)

代码管理机制

当使用自动部署以后，代码就得比较严格的管理起来，因为自动部署都是通过分支上代码的变动来触发的，如果代码随意变动，就会导致自动部署的误触。

• gitlab上dev和master的分支的代码都需要被保护起来，只能通过merge-request合并。不能直接push，而且合并只能是有权限的管理员才能操作，需要审核代码。
• dev的代码merge了以后，自动部署到测试环境，master的代码merge了以后，自动部署到正式环境。

接下来就开始搭建自动部署平台的步骤

• 1.安装gitlab-ci-runner
• 2.把runner注册到gitlab
• 3.在项目根目录添加一个.gitlab-ci.yml
• 4.搭建sonar扫描平台
• 5.完成的.gitlab.yml的演示

1.安装gitlab-ci-runner

首先要明白runner的概念，当代码提交后，需要执行一段代码，去完成自动部署的逻辑。那么如果执行这段逻辑呢，就得通过 runner，也就是为每个项目配置一个runner，提交了项目代码后，runner就会去触发那段逻辑。

安装

#安装依赖
curl -L https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.rpm.sh | sudo bash
 
# 安装 gitlab-ci-runner
yum install gitlab-ci-multi-runner 

# 常用命令
gitlab-ci-multi-runner status  -- 查看安装状态
gitlab-ci-multi-runner list  -- 目前已经有的runner
gitlab-ci-multi-runner register  -- 注册新的runner

把runner注册到gitlab

每个项目都得有一个runner，需要在安装gitlab-ci-runner的机器上去去注册，所谓的注册，就是把runner和项目关联起来，让一个项目能找到自己对应的runner

1.首先在gitlab上选一个你需要自动部署的项目
2.进入setting去设置
3.在安装gitlab-ci-runner的机器上去执行 `gitlab-ci-multi-runner register`
4.输入gitlab的地址和token（下图所示）
5.成功后，下图所示位置多一个runner标志

进入cicd页面.png

runner注册成功就多一个runner.png

在项目根目录添加一个.gitlab-ci.yml

.gitlab-ci.yml是核心的脚本，当触发代码变动的时候,runner就会执行.gitlab-ci.yml的命令，所有执行的命令都在里面，下面结合示例讲解。

首先还需在那台机器上去

# 定义两个阶段 ，测试阶段和发布部署阶段
stages:
  - test
  - deploy

# sonar-check是一个任务。属于测试阶段，script下面是这个阶段要执行的脚本，
# tags是这个项目注册的runner
# only：代表dev分支代码变动，就执行个job
sonar-check:
  stage: test
  script:
    - echo "暂时不做代码扫描~"
  tags:
    - service-ipo-schedules
  only:
    - dev

# 同上，主要核心在于 script 的内容
jar-deploy:
  stage: deploy
  script:
    - mvn clean package -Dmaven.test.skip=true
    - echo "打包完成~"
    - scp -P 10086 ./target/hk-ipo-schedules.jar [email protected]:/data/ipo-service/ipo_schdules/
    - echo "传包完成~"
    - ssh -p 10086 [email protected] "cd /data/ipo-service/ipo_schdules/&& ./kill.sh && ./start.sh"
    - echo "启动完成~"
  tags:
    - service-ipo-schedules
  only:
    - dev

可以在下面这个页面去查看ci-cd的执行日志。

runner执行的job.png

点击job，查看日志.png

搭建代码质量管理平台

到上面为止，基本ci和cd的功能就有了，但是这还不够，因为我们还需要一个代码审核平台，当提交代码，会扫描一遍代码，提示出有多少bug，多少code smells。这里我选择使用 snoar 这个代码管理平台。首先就搭建好 snoar ,然后就配合gitlab-ci一起使用。我们都是用docker去搭建。

sonar项目列表.png

sonar项目扫描详情.png

扫描具体代码的问题.png

首先搭建一个postgres,是一个关系型数据库，提供给sonar使用,步骤如下：

# 拉取镜像
docker pull postgres
# 启动容器脚本
docker run --name postgresqldb -e POSTGRES_USER=root -e POSTGRES_PASSWORD=root -d postgres

# 启动后，使用idea里面数据库工具，或者其他数据库工具测试能不能连上，账号root，密码root

然后安装 sonarqube

# 拉取镜像
docker pull sonarqube

# 启动容器脚本
docker run --name sonarqube --link postgresql -e sonar.jdbc.password=sonar -e sonar.jdbc.username=sonar  -e SONARQUBE_JDBC_URL=jdbc:postgresql://192.168.40.90:5432/sonar -p 9001:9000 -d -v sonar_data:/opt/sonarqube/data -v sonar_extensions:/opt/sonarqube/extensions sonarqube

我安装sonarqube的时候我会报个错
ERROR: [1] bootstrap checks failed
[1]: max virtual memory areas vm.max_map_count [65530] is too low, increase to at least [262144]

主要原因是系统默认分配的最大内存映射区域数不够大。
解决方案：https://blog.csdn.net/xaioAdmin/article/details/107039989

我搭建sonar机器的内网ip为192.168.40.90,映射端口为9001，所以我登陆http://192.168.40.90:9001 账号admin，密码admin。如果能够访问到页面，说明搭建成功。如果有中文的需求，可以在页面的应用上面安装 Chinese Pack 这个插件，但是有些名词翻译的奇奇怪怪，我安装了又卸载了。

下面说一下sonar的基本使用：

1.在maven的setting中添加profile

    sonar
    
        true
    
    
        
          http://192.168.40.90:9001
        
    


2.在java项目的pom文件中添加一个sonar的plugin

    
        
            org.springframework.boot
            spring-boot-maven-plugin
            
                true
            
        
        
            org.sonarsource.scanner.maven
            sonar-maven-plugin
            3.4.0.905
        
    


3.在项目下执行 使用 mvn clean install sonar:sonar 执行

4.扫描后，就会在http://192.168.40.90:9001这个网址上生成一个项目的报告，指出有多少bug，多少code smell。点进去查看是哪行代码。

4..gitlab-ci.yml文件配合sonar

stages:
  - test
  - deploy
  
sonar-check:
  stage: test
  script:
    - mvn clean package -Dmaven.test.skip=true
    - echo "打包完成~"
    - mvn sonar:sonar
    - echo "代码扫描完成~"
  tags:
    - service-ipo-schedules
  only:
    - dev

# start.sh 和 kill.sh 是启停脚本，里面内容是jara -jar 和 kill
 -9 之类的
jar-deploy:
  stage: deploy
  script:
    - mvn clean package -Dmaven.test.skip=true
    - echo "打包完成~"
    - scp -P 10086 ./target/hk-ipo-schedules.jar [email protected]:/data/ipo-service/ipo_schdules/
    - echo "传包完成~"
    - ssh -p 10086 [email protected] "cd /data/ipo-service/ipo_schdules/&& ./kill.sh && ./start.sh"
    - echo "启动完成~"
  tags:
    - service-ipo-schedules
  only:
    - master

上面脚本实现的功能就是代码提交到dev后，首先使用sonar扫描代码，然后maven打包，通过scp传包，然后使用kill.sh去杀掉之前的进程，然后start.sh脚本启动新的jar包的过程。如果想做的更好，可以自己搭建一个docker私服，可以结合Dockerfile把jar包打成image传到私服，然后拉取镜像，通过容器去部署。

踩坑

• gitlab-ci的runner中执行命令的用户不是root，是gitlab-runner。导致ssh登不上，执行命令没权限。