个人站点升级持续集成,自动构建和部署
前言
利用markdown
+Hexo
写文章,整体体验已经很棒。在写作过程中,节省了我不少时间。
但是,美中不足的,就是发布的时候,需要手动输入命令,build
好文件,再用scp
部署到服务器上。
本文,用于记录解决这个痛点的过程。采取的解决方案就是持续集成。
以下是我用于部署个人站点的服务器概况:
服务器 - 阿里云ECS
系统 - CentOS 7
Git仓库管理工具 - Gitlab(9.0.0)
CPU - 1核
内存 - 2 GB (乞丐版💔)
正常情况下,注册GitLab-Runner
的服务器和部署生产文件的服务器是分开的。
因为穷🌚,我只有一台服务器,所以两者都部署到一起,大家就别太纠结这个点了。
一、持续集成
持续集成(Continuous integration),简称 CI,是指开发代码频繁地合并进主干,始终保持可发布状态的这个过程。其中包含持续构建和持续发布。
GitLab 8.0以上的版本就有提供持续集成服务。只要在项目中添加一个.gitlab-ci.yml
文件,然后再添加一个Runner
,即可进行持续集成。
我对自动发布博客的总体实现思路:
添加Runner
用于监听git push
操作,然后用.gitlab-ci.yml
指导步骤的执行,最后用shell
脚本copy目标文件到指定目录下。
二、注册Runner
前提:请自行Google
gitlab-ci-multi-runner
安装教程。
1. 查看注册必需的URL
和token
浏览器打开一个GitLab项目,到 Settings
-CI/CD Pipelines
下,可以看到一个 Specific Runners
块,主要有以下内容:
How to setup a specific Runner for a new project
1.Install a Runner compatible with GitLab CI (checkout the GitLab Runner section for information on how to install it).
2.Specify the following URL during the Runner setup:
http://gitlab.***.com/ci3.Use the following registration token during setup: TB8nknzg1woVb4pCx666
Start the Runner!
其中第2项的URL
和第3项的token
,是注册Runner
所必需的。
Runner
凭借token
注册监听对应的URL
。
2. 在服务器上配置GitLab-Runner
这里,我用SecureCRT连接上服务器,进行以下操作:
// 1.运行命令
sudo gitlab-ci-multi-runner register
// 2.根据提示输入`URL`
Please enter the gitlab-ci coordinator URL (e.g. https://gitlab.com/):
http://gitlab.***.com/ci
// 3.根据提示输入`token`
Please enter the gitlab-ci token for this runner:
TB8nknzg1woVb4pCx666
// 4.然后输入runner的描述
Please enter the gitlab-ci description for this runner:
wall-runner
// 5.输入标签,可以多个,用逗号隔开即可
Please enter the gitlab-ci tags for this runner (comma separated):
test
// 6.是否运行无此标签的构建
Whether to run untagged builds [true/false]:
true
// 7.将Runer锁定到当前项目
Whether to lock the Runner to current project [true/false]:
true
// 8.选择Runner的类型
Please enter the executor: ssh, docker+machine, kubernetes, docker, docker-ssh, parallels, shell, virtualbox, docker-ssh+machine:
shell
这样,一个GitLab-Runner
就创建成功。刷新浏览器页面,在Settings
-CI/CD Pipelines
下可以看到runner已经绑定成功。
三. 配置.gitlab-ci.yml
在要添加持续集成功能的项目的根目录下,创建.gitlab-ci.yml
文件,编写构建步骤。
在编写之前,先大致了解下写法:
# 定义stages
stages:
- install
- deploy
# 定义需要缓存的文件
cache:
paths:
- node_modules/
# 定义任务
job1:
stage: install
script:
- cnpm install
only:
- master
# 定义任务
job2:
stage: deploy
script:
- bash pub.sh
only:
- master
stages
关键字定义Pipeline
中的各个构建阶段的先后顺序cache
关键字定义每个构建阶段,不需要清除的文件- 每个构建阶段有自己的别名,比如例子中的
job1
和job2
。也有真正的stage
名,用于stages
中标识先后的顺序 script
用于定义当前构建阶段需要执行的命令only
用于指定哪个Git分支的push操作才能触发自动构建
以下是我在blog
项目应用的.gitlab-ci.yml
# 持续集成
stages:
- install
- build
- minify
- deploy
cache:
paths:
- node_modules/
- public/
- db.json
# 安装依赖
install_npm:
stage: install
script:
## - cnpm install hexo-cli@1.1.0 -g ## 同一台服务器,不用多次安装
- cnpm install
only:
- master
# 编译,生成静态文件
build_public:
stage: build
script:
- npm run build
only:
- master
# 压缩文件
mini_file:
stage: minify
script:
- npm run minify
only:
- master
# 部署
deploy:
stage: deploy
script:
- bash pub.sh
only:
- master
四、用于部署的Shell脚本
前言中,有提到一个痛点就是scp
部署文件。因为网速的原因,每次跑scp
命令都要等好几分钟,电脑也不能关机。得等到传输完成,才可以。
升级为持续集成后,就不需要在本地跑命令了,都统一在服务器上跑。
而能代替文件传输这个步骤的,就是写一个Shell
脚本,让服务器自动copy文件到对应的目录下。
以下是我应用的Shell
脚本pub.sh
#!bin/bash
cp -f -r -v ./public/* /mnt/blog/
作用就是将public
文件夹下所有文件copy到/mnt/blog/
下。
五、权限问题
因为我是同一台服务器上跑命令,所以当前Runner
进程必须对相关文件夹有写入和读取权限。
所以,我把几个文件夹的读写权限赋予Runner
进程。
使用chown
命令,对文件夹对拥有者权限进行更改:
chown wall-runner 文件路径
如果Runner
服务器和生产环境服务器是相互独立的,则可以使用ssh
的方式去连接。配置好密钥和绕过指纹检查即可。
六、享受愉快的持续集成体验
经过上述的配置,每次push
代码到master
分支。Runner
监听到操作后,就会启动自动构建,完成部署。
这样,我发表新文章,只需要负责把markdown
写好,push
代码到GitLab
。其他的工作,服务器会自动帮我做好。
写好文章,我也可以愉快地关机休息,不用去打理其他的事,感觉真棒!
而且,每次构建记录都有保存在GitLab上。可以在Pipelines
中查看每次构建的结果。
还可以在README.md
加入构建状态图标:
有需要的,就买个服务器折腾下,挺好玩的🌚
附上阿里云服务器的优惠券
最近笔者在整理第一本电子书书稿《前端面试手册》,有兴趣的同学可以关注下~
喜欢我文章的朋友,可以通过以下方式关注我:
- 「star」 或 「watch」 我的GitHub blog
- RSS订阅我的个人博客:
![wall的个人博客](https://img2018.cnblogs.com/blog/718206/201908/718206-20190808234850902-481673533.png)