使用Jenkins自动部署博客

840 阅读7分钟

这篇文章比较简单,适合初学持续集成的读者,本文可以帮助你对基于Jenkins的持续集成有一个比较全局的概念。

提出问题

为了使用HTTPS,我将博客从GitHub Pages迁移到了我的服务器上。由于博客基于Hexo,在迁移之前,我的工作流程是:

本地写Markdown格式文章->Hexo生成HTML并推送到GitHub->GitHub Pages自动使用最新内容

现在由于Hexo渲染以后的HTML文件需要放到服务器上,那么工作流程变为:

本地写Markdown格式文章->Hexo生成HTML并推送到GitHub->手动登录服务器
->进入放博客文章的文件夹->执行命令git pull

增加的两步虽然说操作量不大,但是总显得很麻烦。于是我希望,在我把博客的HTML文件push到GitHub以后,服务器能自动从GitHub上把HTML内容拉下来。由于使用了Nginx,所以只要博客的HTML发生了更新,那么使用浏览器访问kingname.info时,新内容自动就会出现。这样一来,对我来说,看起来就像是我刚刚push了网页内容到GitHub,博客就自动更新了。

让服务器从GitHub上面拉代码,这个操作本身很简单。人来操作就一行代码git pull。写个Python脚本也就两行代码。但问题是,服务器怎么知道GitHub发生了更新?

有人说,Kingname,你不是做爬虫吗?你写个爬虫,每一秒检查一下GitHub不就可以了吗?这种办法当然可以。但问题是,我一周就更新一次博客,但这个爬虫为了等这一次更新,一周要访问GitHub高达604800次?更何况我有时候一个月都不更新。

所以显然不能让服务器主动检查GitHub更新,这种“轮询”操作效率太低。那么如果反过来,一旦GitHub有更新,它就通知服务器,然后服务器再去拉代码,这不就简单高效了吗?

解决问题

为了实现这个目的,就需要使用一些持续集成的工具。本文使用的是Jenkins。

Jenkins在敏捷开发界可以说是大名鼎鼎了。使用Jenkins搭建一整套持续集成环境,可以实现开发者往代码仓库一提交代码,代码自动进行单元测试,覆盖率测试,代码风格检查自动生成报告,自动通知部门同事开始Code Review。当代码被合并入主干以后,服务器自动拉下最新代码,自动编译,自动在几千几万台服务器上部署。在整个过程中,开发者只需要做一件事,那就是git push(当然在实际情况下,后面还会加一些参数)。

本文实现的是博客的自动部署,没有任何测试,也没有Code Review,也没有编译,服务器也只有一台,复杂程度当然远远低于持续集成。不过管中窥豹,来看看这个简单地流程是如何走通的,对初学者也会有帮助。

本文假设你已经在服务器上面搭建好了Jenkins环境。如果你还没有安装Jenkins或者不会安装,那么可以“参考”这篇文章:搭建持续集成环境(一)。由于这篇文章是18个月以前写的,系统也是小众的Arch Linux,所以建议你还是在网上搜一下最新的Jenkins安装教程比较好。

设置GitHub

在GitHub中进入博客所在的Repo,并点击Settings,如下图所示。

在设置页面,单击左侧的Integrations & services,并选择Add service,如下图所示。

从下拉菜单中,选中Jenkins (GitHub plugin)。在新打开的界面,填写Jenkins的信息,如下图所示。

其中Jenkins hook url填写的是我的服务器的Jenkins地址加上/GitHub-webhook/,所以完整的地址为http://xx.xx.xx.xx:8080/GitHub-webhook/。把这里的xx换成实际的IP地址或者域名即可。需要注意的是,网址末尾的斜杠一定不能省略。

填写好信息以后保存,GitHub就配置好了。

配置Jenkins

Jenkins需要安装GitHub Plugin才能接收到GitHub发来的通知。进入Jenkins的系统管理-管理插件,在可选插件选项卡中,搜索GitHub plugin并安装,安装完成Jenkins会重启。重启以后可以在已安装选项卡下面发现GitHub plugin,如下图所示。

回到Jenkins首页,单击左上角新建按钮,新建一个项目,项目类型为构建一个自由风格的软件项目。任务的配置信息如下图所示。

其中的项目名称描述可以随意填写。勾选GitHub project,并把博客对应的GitHub Repo的地址填入。往下拉,看到源码管理,点选Git,依然填写博客对应的Repo地址。如下图所示。

继续往下拉,在构建触发器单击增加构建步骤,在弹出的下拉菜单中选择Execute shell。勾选GitHub hook trigger for GITScm polling。在Execute shell对应的输入框中输入命令,将当前目录下的所有文件和文件夹全部复制到/home/bexercise/kingname.github.io/文件夹下。如下图所示。

其中,文件夹/home/bexercise/kingname.GitHub.io/里面的内容如下图所示。这是Hexo生成的HTML文件和资源文件。

这里需要解释一下这一条命令:

cp -r ./* /home/bexercise/kingname.GitHub.io/

其中的cp -r表示复制文件和文件夹。./表示当前目录。./*表示当前目录下面的所有内容。因此整条命令的意思是把当前目录下的所有内容全部复制到/home/bexercise/kingname.GitHub.io/下,并且如果文件名相同,就会直接覆盖。需要注意的是,kingname.GitHub.io这仅仅是一个普通的文件夹而已,别看它的名字长得像个网址,但其实它只是一个名字比较怪的普通文件夹而已,没有什么特殊的意义。

这个项目在构建的时候,它会自动从GitHub上面对应Repo所有的文件拉取到当前的文件夹下,所以执行了这一条复制命令以后,博客HTML文件自然就被复制到了网站的根目录下。

修改权限

由于Jenkins在安装的时候,会自动创建一个名为jenkins的普通账号,这个账号没有管理员权限。jenkins执行命令的时候,它也会使用这个账号。但是由于kingname.GitHub.io这个文件夹是用户bexercise创建的,所以jenkins账号默认是没有权限读写这个文件夹的。现在需要给jenkins账号授予权限。使用bexercise这个账号登录服务器,使用以下命令给jenkins赋予权限,让它可以读写kingname.GitHub.io文件夹:

sudo chown -R jenkins:jenkins /home/bexercise/kingname.GitHub.io

执行完成这一行命令以后,jenkins才可以把其他地方的文件复制到这个文件夹里面。

使用方法

没有什么复杂的使用方法,在Hexo中,执行命令hexo d就可以把本地生成好的HTML文件提交到GitHub中。然后打开浏览器,打开博客,发现新的文章已经出现在首页了。

在Jenkins项目的执行历史里面,也可以看到它被自动触发而产生的历史记录。如下图所示。

举一反三

由于Jenkins可以运行Shell命令,进行单元测试本质上也是运行一条命令,那这不就可以实现自动进行单元测试了吗?那么如果把Shell命令改成运行一个Python脚本,那不就可以做任何事情了吗?如果Python脚本里面写了发送邮件的代码,那不就实现了你一提交代码,其他人就收到邮件了吗?