前端自动部署——gitlab-runner CI

2,384 阅读4分钟

背景

当前端开发完之后需要部署代码到服务器上,而这个步骤是由前端打包代码,然后放置到静态服务器上的。有多少次迭代也就有多少次这种步骤,如果引入自动部署是不是就会节省很多这种工作呢

需要了解的知识

  1. gitlab
  2. gitlab-runner
  3. nginx
  4. .yml 命令
  5. shell 命令

步骤

1. nginx 服务器上安装 gitlab-runner

# Download the binary for your system
sudo curl -L --output /usr/local/bin/gitlab-runner https://gitlab-runner-downloads.s3.amazonaws.com/latest/binaries/gitlab-runner-linux-amd64

# Give it permissions to execute
sudo chmod +x /usr/local/bin/gitlab-runner

# Create a GitLab CI user
sudo useradd --comment 'GitLab Runner' --create-home gitlab-runner --shell /bin/bash

# Install and run as service
sudo gitlab-runner install --user=gitlab-runner --working-directory=/home/gitlab-runner
sudo gitlab-runner start

2. gitlab-runner 注册

sudo gitlab-runner register --url https://xxx.cn/ --registration-token xxx

其中的 url 和 token 可以在 group 或者 project 中获取。

位置:Settings => CI/CD => Runners => URL & Token

3. 项目添加 .gitlab-ci.yml

image: node:alpine

# 构建阶段:build & deploy 两个 job;按照先后顺序执行
stages:
  - build
  - deploy
  
cache:
  paths:
    # 这里将这两个文件缓存,为了在第二个job中使用。其实只要缓存第二个也就够了
    - node_modules/
    - dist/

build:
  stage: build
  only: 
    # 只在提交到 dev 分支的时候触发
    - dev
  script:
    # 使用 cnpm 安装依赖,默认之前全局安装过 npm
    - npm install
    # 打包
    - npm run build

deploy:
  stage: deploy
  only:
    - dev
  script:
    # 删除项目部署位置的文件(/home/web/xm/)。文件数量会随着部署线性增长故需要删除
    -rm -rf /home/web/xm/
    
    # 将打好的包(dist/*) 复制到项目部署的位置(/home/web/xm/)
    - cp -rf dist/* /home/web/xm/
    
    # 项目部署完毕,调用 API 刷新 CDN 缓存
    - curl "https://refreshCDN.com?url=https://hhhh.com"
    
    # 项目部署完毕,调用 API 通知相关人员
    - curl "https://noticeAPI.com?t=666"

4. 提交代码,测试流程

问题 & 方案

1. 服务器上打包失败

需要检查一下服务器上的 node.js 版本,是否满足当前项目所用框架的需求。

  1. 查看当前环境 node.js 版本
node -v
  1. 安装 n 模块
cnpm i -g n
  1. 更新 node.js 至最新稳定版本
n stable

2. yml 文件 script 出错

当我们提交代码触发 runner 之后可能会提示我们 .gitlab-ci.yml 文件中命令出错。此时比较有可能出错的地方是 script 中的特殊符号,就需要使用引号将其包裹

; { } [ ] , & * # ? | - < > = ! % @ `

3. 无操作权限

将新包放到项目位置的时候可能会涉及到文件的删除和写入。

linux 系统是多用户多任务性质的,可能项目位置的权限并不是 gitlab-runner,我采取将项目位置权限更改为 gitlab-runner。所有这必需在 /etc/password 文件内

修改文件权限

chown -R gitlab-runner 8/

修改文件夹权限

chgrp -R gitlab-runner 8

还有一种办法可以让 gitlab-runner 安装的时候将权限设置成 root,那就意味着 gitlab-runner 可以更改当前服务器上的所有资源

4.权限变化

最新的几次使用 gitlab-runner 发现安装项目的目录和权限会变化,这可就很奇怪了。看配置文件就是 /home/gitlab-runner/ 其他也没有奇怪的地方

尝试卸载,居然卸载失败了。。。可能我步骤不对

后来发现使用 gitlab-runner 这个角色登录注册 runner ,然后跑 gitlab-runner run。之前是到 root 去注册和 run 了

express gitlab-ci.yml 实例

image: node:alpine

# 
stages:
    - buildRelease

buildRelease:
    stage: buildRelease

    tags:
    - express-tag

    only:
        - release
        
    script:
        # 删除之前的文件,可以考虑做备份操作
        - rm -rf /home/webTest/Internal/express/*
        
        # 将文件拷贝到项目的目录,这里暂时不用安装依赖
        - cp -rf * /home/webTest/Internal/express/
        
        # 进入 express 目录,为了接下来的安装依赖
        - cd /home/webTest/Internal/express
        
        # 安装依赖
        - cnpm i
        
        # 使用 pm2 管理进程,重启服务 
        - pm2 restart 0

部署 express 最大的不同在于拷贝了之后再安装依赖。

甚至都可以不用删除之前的文件,直接替换,然后重启。部署的效率比我们手动部署快多了,还可以减少错误。当然部署完毕之后需要检查是否成功

总结

上面的前两步可以在gitlab runner获取对应平台的安装方法。遇到的三个问题和对应的解决思路可以参考下。

按照上述步骤即可完成 nginx部署gitlab-runner 的功能,我这边的流程走得通的。针对 gitlab-runner 我的理解是一种两个服务器之前的通讯,借助 .gitlab-ci.yml 文件传递命令脚本。

如果有遇到其他奇怪的问题欢迎留言,例如那个权限变化