背景
当前端开发完之后需要部署代码到服务器上,而这个步骤是由前端打包代码,然后放置到静态服务器上的。有多少次迭代也就有多少次这种步骤,如果引入自动部署是不是就会节省很多这种工作呢
需要了解的知识
- gitlab
- gitlab-runner
- nginx
- .yml 命令
- 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 版本,是否满足当前项目所用框架的需求。
- 查看当前环境 node.js 版本
node -v
- 安装 n 模块
cnpm i -g n
- 更新 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 文件传递命令脚本。
如果有遇到其他奇怪的问题欢迎留言,例如那个权限变化