用白薅来的gitlab自带的gitlab-runner部署一个vue项目

@[TOC](用白薅来的gitlab自带的gitlab-runner部署一个vue项目) ## 前戏

最近学习 GitLab 中的 CI/CD 过程考虑中，配置 GitLab Runner 时遇到一些困难。到服务器配置较低，搭建项目环境（如 Node.js、Maven 等）会带来额外的负担。这个过程可能会增加部署的复杂度和时间成本，对于服务器资源有限的情况极为明显。因此，优化这一流程是至关重要的。

我是换了各种姿势但是最终还是认为再加一台服务器比较靠谱，在日常的生产环境中我也是这样认为的，如果在资源充足的情况下最少配置两台服务器，配置两个gitlab-runner，一个用来deploy,一个用来build。抱着这个想法，最终有了白嫖这个行动。

重头戏

gitlab提供了很多个实例运行器，其中有小的arm的还有docker的，各种类型的runner。

在上面的基础上我就有了大胆的想法，直接用gitlab提供的runner(这里一定要注意，首先它不一定安全，其次它应该是一个纯净版的，所以在使用的时候就用不了cache,以及本地maven仓库的jar。),自己的项目，或者说用来测试的，感觉都是一个不错的选择。

正戏

首先我们根据前戏中的想法，让gitlab提供的gitlab-runner来做build，自己的服务器只做部署操作，于是就有了下面的.gitlab-ci.yml

stages:
  - build
  - deploy

# 构建阶段
build:
  stage: build
  image: node:16  # 使用 Node.js 14 镜像作为构建环境
  script:
    - npm install  # 安装项目依赖
    - npm run build  # 执行构建命令，生成静态文件
  artifacts:
    paths:
      - public/  # 将构建好的静态文件作为 artifacts，以供后续阶段使用
  tags:
    - saas-linux-small-amd64
# 部署阶段
deploy:
  stage: deploy
  only:
    - master  # 只有在 master 分支发生变更时才执行部署
  script:
    - cp -r public/* /home/vueProject/my_log/public
    - sudo /usr/local/nginx/sbin/nginx -s reload
  tags:
    - acowbo

这里重点关注tags，我们进行了指定，build指定saas-linux-small-amd64，而deploy指定为acowbo也就是自己服务器部署的gitlab-runner。

image-20240511093352253

至此我们的配置还没有结束

收拾残局

在部署vue项目中，我们可以选择部署到Tomcat也可以选择部署到nginx，这里我选的是nginx，但是执行命令的是gitlab-runner这个用户。所以我们要看执行的命令是否属于gitlab-runner用户或用户组。如果权限不够，我们可以执行以下命令来解决

chown -R gitlab-runner:gitlab-runner /usr/local/nginx/logs/error.log

加餐方法如下：

1. 执行sudo visudo
2. 加入如下gitlab-runner ALL=(ALL) NOPASSWD: /usr/local/nginx/sbin/nginx -s reload,这个可以确保你可以用sudo的方式执行此命令

成果