其实蛮纠结这篇文章到底放在哪个分类下呢?开发环境搭建?还是环境搭建?后面想了一下,写博客总结是和我们日常开发一样重要的任务!也是一种开发,那么博客的搭建自然就算在开发环境搭建下面了!
哈哈,废话不多说,开搞!
之前曾经在Github Pages上使用jekyll搭建过一个博客,也绑定了自己的域名,使用体验十分好,每次在本地编辑完,只需要执行git push命令即可完成博客的更新。
后来由于工作原因,想跑点自己的代码在服务器上,因此购买了服务器,就一不做二不休,将博客也迁移到自己服务器上,方便进行后续的扩展和开发。
不过即使在自己的服务器上搭建博客,仍然推荐在github上保存一份仓库,因为我相信,我们自己的服务器并没有github的服务器稳健,如果后续我们不再购买,或者服务器崩溃数据丢失,在github上有完整仓库也可以很快重新搭建。
这里的技术使用指的是如果你会这些技术,那么在搭建过程中就会方便很多,不回去百度,而且碰到问题也可以自己进行调试。
当然,即使你不是计算机从业人员,只要你跟随博客操作,多查多看多想,也是可以完成的。
首先登陆阿里云官网,购买服务器,如果只是搭建博客,可以购买乞丐版(我就是!!),价格很便宜。
可以首先领取阿里云的一个月免费试用,等操作熟悉,确定继续试用后再进行续费(第一年99,后续每年600多700),同事如果你是学生,可以参加阿里云的云翼计划,更加划算。
购买成功后,登录自己创尔账户,进入阿里云控制台,选择自己的服务器
在右侧点击远程连接,输入自己的密码。
这一步如果是windows平台,可以使用xshell等工具,mac平台可以直接在命令行输入:
ssh root@你的服务器地址(10.10.10.10)
然后输入密码即可进行服务器命令行。
服务器上的操作使用命令行大部分都可完成,不建议安装图形界面等
如果为了安全,可以登录后新建其他用户,root用户权限过大,容易发生误操作 我对自己很自信(lan)所以一直在使用root用户。
之后可以开始jekyll的安装了。
Jekyll的安装过程这里不再详细叙述,网上教程很多,这里给大家介绍一个个人觉得不错的。
同时附上Jekyll的官方中文文档。
在上文的jekyll搭建教程中,已经安装好了Jekyll,但是在实际使用中会有一点改变,主要是服务启动方法的改变。
教程中,最后使用如下命令启动Jekyll服务:
jekyll serve -H 0.0.0.0 -P 80
这样启动的服务在你关闭命令行后就会停止,而我们在服务器的服务不可能保存命令行连接,因此需要修改为:
jekyll serve -H 0.0.0.0 -P 80 --detach
这样以守护进程的方式启动了Jekyll服务,不再依赖于命令行连接。
当你想要停止服务时,可以使用以下命令:
pkill -f jekyll
或者
ps -ef | grep jekyll
kill -9 jekyll服务进程编号
按照官方文档及上文教程中的指示,我们删除掉_posts目录下的文章,重新编写自己的md文件,并重启jekyll服务即可展示我们的博客了。
服务器配置成功后,需要开放你想使用的端口,在阿里云控制台即可进行操作。
操作十分简单,点点点就好了,具体方法自行百度一下。
域名购买成功后,需要再域名购买商提供的网站控制台修改域名解析,将域名解析到你的服务器地址,同时,国内域名购买后需要备案,
登录阿里云网站后点击备案,按照教程一步步操作就好。
这里强烈建议大家购买后尽快进行备案
我们的服务器上不可能只运行一个博客,但是80端口只有一个,怎么办呢?
在启动Jekyll服务时,使用的命令:
jekyll serve -H 0.0.0.0 -P 80 --detach
其中-P指定的就是启动时的端口,你可以修改为任意你服务器开放了的端口,如:
jekyll serve -H 0.0.0.0 -P 8899 --detach
这样,你就将Jekyll服务启动在了8899端口下,那么问题来了,刚才说的只能访问80端口呢!不急。
我们在购买域名后,可以设置子域名。
1.首先去域名购买网站的控制台,在解析记录中,添加你想使用的子域名,同样解析指向你的服务器,如:
blog.yuming.com
2.在服务器上安装nginx。
$sudo apt-get install nginx
3.启动nginx
$sudo /etc/init.d/nginx start
4.修改nginx配置文件
cd /etc/nginx
vi nginx.conf
在 http 后的大括号内添加图片内容:
其中
liston:80。想要监听的端口 server_name:blog.yuming.com。为你设置的子域名 location 后面的 http://localhost:8899。为你启动的Jekyll端口。
5.重新nginx
service nginx restart
然后在浏览器访问你的子域名即可跳转至你的博客。
至此,我们已经已经拥有了一个博客,实现了基本功能如:
能写能看,强无敌!
----------------进一步优化方案分割线---------------------
让我们来一个一个解决。
经常性的登录服务器肯定是不科学的,每次写完扔到服务器上再去服务器上重启服务肯定是要改善的对不对?
最好有一点git基础知识
这里就要用到git了,git不就可以把日常写的代码,文件等等推送到远程吗?而且我们刚才建立博客的时候,是克隆的github上的仓库呀。
PS:不要使用git init –bare,这个是建立裸库的,也就是服务器端记录你的改动,你的文件,但是没有工作区,你在服务器上是不能看到你的文件的。
(日常使用的git服务器大多是裸库,因为服务器端不需要进行修改,所有修改都是通过本地操作后push完成,但是我们需要在服务器端读取文件展示)
通过git init 初始化的仓库,由于存在工作区,因此不允许push,防止工作区混乱,因此需要在/blog/.git/config文件内添加下图内容。
该内容作用为允许其他仓库向此仓库push。
注意:这个方法是个人总结出的比较方便的方法,但是需要用户自己保证不在服务器端的工作区进行文件的改动及commit操作,否则极其容易造成工作区混乱,如果很喜欢在服务器上写,可以建立裸仓库用来保存,在其他文件夹建立本地仓库clone一份进行改动。这种方式不做介绍。
//初始化仓库
git init
//关联远程仓库
git remote add origin 10.10.10.10:/你的仓库目录/.git
//拉取远程最新代码
git pull origin master
//本地改动commit
git add .
git commit -m "改动"
//拉取远程最新并解决冲突
git pull origin master
//推送到远程
git push origin master
这样,当我们改动了博客,不再需要去scp文件到服务器,只需要进行常用的git push命令就可以将当前提交推送到远程仓库啦!
是不是感觉提升不大呢?从scp改动git push而已。
不要急!重点在下面!
怎样将登录服务器,重启Jekyll这一个步骤在本地进行或者自动化进行呢?
这就要用到git的钩子了。
可以戳这里了解下什么是钩子
总的来说就是git为我们提供了一种可以监听动作的机制,比如监听提交(还有其他机制,这里只用提交)。
当我们每次往服务器进行一次提交,git监听到后可以自动执行一个脚本,这个脚本里面我们可以写自己的内容,是不是美滋滋?
post-receive
文件,文件内容为:#! /bin/bash
pwd
cd ..
unset GIT_DIR
git reset --hard
echo 'jekyll build success,and you blog is updated!'
该脚本的作用为:cd到博客目录,拉取最新的代码。
PS:这一步其实是因为我们创建git仓库时没有使用--bare
,导致创建的仓库带有工作区,那么在远程push了一次提交后,服务器并不会自动拉取最新代码,因为服务器认为你当前也在修改代码,所以我们在提交后需要用脚本来完成工作区文件的更新,以用于展示。
同时,这里需要Jekyll的配合。
使用--watch
参数启动服务,Jekyll可以自动监听_posts文件夹下的变化以用于更新展示内容,但是在Jekyll里面有个问题,当你执行以下语句:
jekyll serve --watch --detach
你想要后台运行Jekyll(不绑定命令行连接),又想动态监听变化,加了两个参数,但是执行结果是不会监听变化,这点是设计如此还是bug不清楚,但是我们可以执行以下命令来达到同样的结果:
//亲测可用
setsid jekyll serve --host 0 --watch --force_polling &>/dev/null </dev/null &
总结一下: 在服务器上,我们以后台监听变化的形式启动Jekyll,然后添加git钩子,在每一次的push后,服务器自动拉取最新代码,同时Jekyll监听到变化自动重新展示,就实现了:
本地编辑,git提交并push到服务器,就完成了博客的更新
搞完上一步,这一步骤就简单了,你可以在本地再次添加一个远程仓库,关联到github,每次改动后,push到github,再push到服务器上。
如:
git remote add origin_github git@github.com:XXXXX/blog.git
这样的话,每次更改完:提交一次到github,提交一次到服务器。
PS: 后续可以考虑写个脚本,将两次提交放到脚本里进行,不然每次提交两次也蠢蠢的。
博客评论系统其实很多,但是前两年关闭了几个,所以我选择了一个很机智的解决方案。
Gitment:使用 GitHub Issues 搭建评论系统
这是作者写的教程页面,完全按照教程来亲测可行,而且很简单。
Gitment基于Github Issues开发,为每一篇文章建立一个Issue,后续的评论作为Issue的回复存储在github上。
对于这个缺点,可以通过执行脚本来批量初始化,但是目前没有研究,后续写了脚本或者学习到怎么批量初始化会再来贴在这里。
而且对于大部分人的产出速度来说,手动点一次完全可以接受(手动滑稽)。
本地在编辑markdown时,有许多的工具可供选择,一般推荐的话都要列举一番优缺点,但是我不,我用过好几个,这个是最舒服的,所以给大家推荐一下。
Atom,我目前在用的有Mac版本,Ubuntu版本,都比较好用。
Atom相比于其他的编辑器,有一个很不错的项目展示系统,类似于这样:
可以很方便的看到当前目录下的文件,尤其是写博客时,方便管理。
同时支持许多插件的扩展。 比如:markdown-img-paste, 可以很方便的截图然后粘贴上传至sm.ms或者七牛云图床。
但是会有一点点小bug,偶尔不好使,尚且没有完全折腾透彻。
其他的插件目前还没有用到。
图床的选择有很多,比如公共的sm.ms免费图床,或者七牛云图床。
七牛云有一定的免费流量,超出之后需要收费,我觉得暂时是够用的,后续的费用也不是很高,可以接受。
可以使用上面说的atom的插件进行上传,也可以使用“图床on七牛”chrome插件进行上传,都算是比较方便,图片数量不是很大时完全够用。
同时,网上有许多七牛的批量上传方法,有需要可以自行研究一下。
自己花了两天内的零碎时间逐渐折腾好了这一套配置,想着总结一下写出来,方便后续自己查找,同时帮助广大网友少走弯路,但是实际写出来总感觉叙述的不是特别清晰,没有达到预期的效果。
如果有人按照操作出现问题,或者有什么不明白的问题,欢迎评论或者向底部邮箱发送邮件,可以一起探讨一下更加合适的解决方案。
完。
2018-09-24 完成
以上皆为个人所思所得,如有错误欢迎评论区指正。
欢迎转载,烦请署名并保留原文链接。