个人站点升级持续集成，自动构建和部署-白红宇

前言

利用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/ci

3.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文件，编写构建步骤。在编写之前，先大致了解下写法：

# 定义stagesstages:  - 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  - deploycache:  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/bashcp -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」 我的

RSS订阅我的个人博客：

前言