gitlab流水线自动部署流程

自动部署之前，需要准备的是放gitlab的服务器，运行gitlab-runner的服务器以及后端代码运行的服务器。需要先搭建好runner并放在自己的项目中，gitlab的 runner 主要作用是用于监视相关项目的变动，然后可以自动拉取对应的分支进行自动构建，测试，和部署。就是对编写好的ci文件进行管理。
其自动部署就是将存放在gitlab上的仓库代码利用rsync实时同步到实际要跑后端代码的那台服务器上，文件传输的方式就是利用SSH，将文件传输过去之后继续让代码后台跑起来，这样就实现了实时部署。
前端的这个部署文件也是将前端代码传输到后端的服务器上，与后端的jar包放在同一个目录下是一个static文件夹下，然后利用nginx进行方向代理进行端口转发就可以了。
首先需要了解的前提：

1. runner将整个项目文件导入到一个docker中，设置了将docker作为执行器的话。所有在ci文件里写的指令都是在docker容器中运行的，所以实际上是运行runner的这台服务器里的一个docker在向后端服务器同步文件。
2. 作为一个什么都没有的docker它的基本运行环境应该是乌班图，所以在ci文件里写的指令应该是基于ubantu的。首先要进行代码的打包，前后端都一样，要运行npm或者mvn指令进行打包，这两种指令依赖于ci文件中image的指定，一般都有了无需特别安装。
3. 注意，可以想象，在刚进去这个docker的时候就处于整个仓库的根目录下，可以直接进行打包。
4. 将rsync安装在docker里，为接下来文件传输做准备。注意rsync一般都是利用ssh进行文件传输的。所以难题来了，怎么让后端服务器认识这个docker呢，这个docker也没有已经生成ji好的公私钥。
5. 为了解决上述问题，我们就需要准备一对主机公私钥，用传递变量的形式注入docker作为其身份信息。然后将后端服务器的主机公钥作为known_host保存到docker这样后期后端验证docker身份时验证通过。之后将docker运行的服务器中的root用户公钥存入pubkey文件，并也存入后端服务器的authorized_keys中，这样docker向后端服务器传输文件时就可以认识docker。
   到此，基本需要注意的都完成了接下来是整个部署流程

准备一对公私钥

在自己本机生成一对公私钥，将public_key和private_key分别在gitlab界面中的项目组中设为变量
添加变量的方式在设置，进入CI/CD，点击变量即可添加

在gitlab界面添加公私钥以及追加known_hosts

这个公私钥就是第一步准备好的公私钥，之后要用这对公私钥进行两台主机之间的文件传输。追加的known_hosts是后端运行代码的服务器的公钥

编写ci文件

image: maven:3-jdk-11  # 要用到的打包工具以及运行环境 这是从image库里看到的是一个docker

stages:
  - test
  - package
  - deploy

maven-test:          # CI/CD 任务名称
    stage: test      # 任务阶段，一般有 build、test、deploy等。执行顺序为：build →test →deploy
    services:
      - name: mysql		#还需要一个mysql服务器
        alias: db
    script:          # 执行任务的脚本，每条是一个 Shell 命令。
      - mvn test -s ci_settings.xml -Dspring.profiles.active=dev # 先用mvn test进行打包 执行jar包的命令 xml文件是项目配置文件可以不写
                     # 通过环境变量$DB_URL、$DB_USER和$DB_PASS提供密码信息。环境变量在仓库设置中配置。
    except:          # 不在 developer 和 master 测试。maven package 会自动执行编译和部署，因此不需要再次执行test阶段的任务。
      - main
      - dev

idrsmc-test-and-package: #名字随意起
    stage: package
    services:
      - name: mysql
        alias: db
    script:
      - mvn package -s ci_settings.xml -Dspring.profiles.active=dev
    artifacts:      # 任务成果，一般为编译后的产物。
        paths:      # 也可以指定一个或多个目录。
          - target/migration-2.1.0-SNAPSHOT.jar
          - target/site/apidocs # api接口文件
        expire_in: 1 week # 产物会占用 GitLab 服务器的空间，应当定期清理。
    only:           # 只在 developer 分支和 master 分支执行部署操作。
      - dev
      - main

deploy-server:
  stage: deploy
  image: ubuntu
  needs:
    - idrsmc-test-and-package # 需要先完成上一步
  script:
    - |
      echo -e "\e[0Ksection_start:`date +%s`:my_first_section\r\e[0K准备 SSH 凭据"
        which ssh-agent || ( apt-get update -y && apt-get install openssh-client git -y )
        which rsync || ( apt-get update -y && apt-get install rsync -y )
        eval $(ssh-agent -s)
        echo "$SSH_PRIVATE_KEY" | tr -d '\r' | ssh-add -
        mkdir -p ~/.ssh
        chmod 700 ~/.ssh
        echo "$SSH_KNOWN_HOSTS" >> ~/.ssh/known_hosts
        chmod 644 ~/.ssh/known_hosts
        echo "$SSH_PUBLIC_KEY" > ~/.ssh/id_rsa.pub
        chmod 644 ~/.ssh/id_rsa.pub
        echo "$SSH_CERTIFICATE" > ~/.ssh/id_rsa-cert.pub
        chmod 644 ~/.ssh/id_rsa-cert.pub
      echo -e "\e[0Ksection_end:`date +%s`:my_first_section\r\e[0K" 
      #  上述都是在为了之后的文件传输进行铺垫，就是要利用rsync进行ssh传输
      

      echo -e "\e[0Ksection_start:`date +%s`:my_first_section\r\e[0K部署到 $TARGET_SERVER"
        rsync jar包目录 $TARGET_SERVER:文件目录
        ssh $TARGET_SERVER "systemctl restart 项目名称.service" #运行项目
      echo -e "\e[0Ksection_end:`date +%s`:my_first_section\r\e[0K"
  only:
    - dev
    - main

执行流水线

部署好之后，进入gitlab项目，点击流水线，就可以运行了。

流水线执行过程中可能会遇到的问题：

1. 没有可用的runner所以任务暂存之类，建议直接到设置-》CI/CD中查看runner，是否有可以用的，有的话就检查一下自己ci文件中有没有写tags，tags用来绑定runner
2. xxx指令不存在，大概是没有安装什么软件，直接安装就好了，注意使用的是ubantu系统的指令（这个好像是可以在哪里修改系统类型）
3. ssh认证出错，应该主机公钥和用户公钥没有写对。用户公钥是到root下的.ssh目录里找，主机公钥是要到/etc/ssh里面找以ssh_host开头的就是主机公钥

如何远程执行jar包

建议将运行jar作为一个服务进行启动，这样ssh 指令可以直接启动。此时我们的指令还是在ssh环境里，所以要符合ssh语法。写一个jar.service文件