原文：http://www.nczonline.net/blog/2015/08/wordpress-jekyll-my-new-blog-setup/

我早就考虑过把博客从WordPress迁移到Jekyll。之所以迟迟未动手，是因为不了解Jekyll的具体原理，也不确定是不是应该把博客托管到GitHub。另外，我也担心自己将来不能定时发博客。定时发表是我很常用的一个WordPress功能，特别是在我罹患莱姆病，状态起伏不定的这段时间。我最不能接受的就是不能定时发表，因为我从没想过手工发表。

可是，购买服务器的账单让我意识到，为了这个几乎完全静态的WordPress站，我花了太多冤枉钱。一季度50美元，一个月就是17美元。用今天的眼光看，花这么多钱支撑一个几乎不怎么更新的网站，太奢侈啦。我租这个服务器10多年了，一直都这个价。WordPress频繁的更新和无尽的安全漏洞也促使我考虑放弃它，换一个静态网站生成系统。最终，我决定把原来的WordPress站迁移到Jekyll。

迁移评论

第一步是把评论迁移到Disqus。倒不是我对Disqus多么推崇，主要是它能迅速集成到WordPress，而且还能在以后的静态站中使用。

因此我从安装Wordpress Disqus Plugin开始，把它集成到原站中。然后开始把评论导入Disqus，但发现不行。最终，还是手工导入了评论，因为Disqus插件好像每次只能导入很少评论。

输出博文

在确定评论已经安全导入到Disqus后，接下来就要考虑怎么导出其他内容。最终，我选择的是针对WordPress的Jekyll Exporter Plugin。安装后，只要点击“Export to Jekyll”下载包含所有内容的一个ZIP文件即可。这个插件很厉害，导出的内容很完整，包括所有标签、类别、固定链接、博文和页面，甚至都帮你复制了wp-content目录下的图片和样式表。解压后的文件基本上就可以作为下一个静态站的起点了。

Jekyll Exporter唯一没做的，就是没有提供WordPress的布局信息。这可以理解，因为WordPress中的布局信息都是PHP文件。不过，我就得自己手工从WordPress主题中复制HTML，再粘贴到Jekyll模板里。之后我把Disqus的JavaScript代码放到页面中，就神奇地发现评论出现了。

选择主机

开始的时候，我想用GitHub Pages，因为我知道有不少人用它。可是，有几个地方我觉得不爽。

1. 前面刚说了，不能定时发表。GitHub不支持让你重新生成一个站点，而这就意味着要么把博文留好，到想发布的那天再发出来；要么做一次伪提交，强制站点重新生成。不管怎样，我都觉得不好。
2. 只能使用GitHub安装的Jekyll插件，如果想使用其他功能，要么使用黑科技，要么放弃。我的需求是自动按年和按月生成存档，jekyll-archives可以满足，但在GitHub上无法使用。
3. 我希望有个地方在发表前预览变化，而我使用Windows，设置Jekyll很麻烦（我尽力了，尝试了3次），导致无法本地测试。当然可以在GitHub上另建一个仓库，可我不希望手工维护两个仓库。

经过一番调研，我知道可以在Amazon S3上托管我的静态站点，利用其免费政策可以一年不花钱。一年后，每月费用也不到1美元。跟我原来WordPress主机每月17美元比，可是大大省了一笔。况且，S3还可以为内容提供可靠的备份。

部署流程

决定使用S3以后，问题就剩下怎么把文章从GitHub迁移到S3，以及如何实现定时发表了。结果，两个问题，只需一个方案：架设一台Jenkins服务器。

我想了一下，构思出如下步骤：

1. 把文件检入本地Git仓库
2. 在把变化推送到master时触发构建操作
3. 构建时检查远程Git仓库，并运行Jekyll来生成文件
4. 构建时同步生成的文件和S3上的文件

如果上述方案可行，我就可以让它每天半夜自动运行。这就意味着我可以把发表时间定在未来的任意时刻。

具体实施中，基本上参考了这篇文章： Trigger Jenkins builds by pushing to GitHub。我用了AWS上的一个微实例，因为第一年免费，不过一年后可以切换到DigitalOcean（随需而用的微实例价格分别是每月5美元和10美元）。

最终我使用的是S3Cmd与S3同步。开始我试过AWS CLI，但它限制同步文件的大小和最后修改时间。因为每次构建都会重新生成整个站点，而最后修改时间每次都会变化，结果就是不管实际有没有改动，都会同步。S3Cmd则在同步前还会检查文件内容，确认是否真的有改动。这一点不同，把每次构建2000次PUT请求一下子减少为大约每次3个PUT请求。

Jenkins服务器很好用。相同的构建还可以通过发送给GitHub仓库主分支的推送请求触发，每天半夜自动化。在_config.yml文件设置future: false后，我写的任何博文不到发布日期都不会生成。我使用的是最新的GitHub Pages，因此这个配置与GitHub自身使用的兼容。

引导流量

开始的时候，我以为S3可以满足所有流量需求。S3一般不会自动压缩文件，因此所有HTML、CSS和JavaScript都会以原始形式发送（花费更多流量和钱）。我在S3的前端先使用Cloudfront，也就是AWS的CDN。可Cloudfront也不进行任何压缩（我很震惊）。

Twitter上有人建议使用CloudFlare，因为它支持压缩，还有其他优化、DDos保护、免费SSL功能，而且也有免费政策。更重要的是，CloudFlare会在自己的CDN上缓存请求，而这也减少了对S3的请求数量。

遗憾的是，作为S3新手，我犯了一个低级错误：给代码库起错了名字。当时我不知道代码库要跟域名相同（不知道为什么要做这个限制），一开始名字叫“nczonline”，因此我创建了nczonline.net。问题就在于代码库的名字不叫“www.nczonline.net”。而由于配置错误，这对过渡期间访问站点的任何用户都是显而易见的。在此期间，有人建了一个代码库叫“www.nczonline.net”，由于代码库的名字是全局的，我不可能再建一个重名的。鉴于AWS命名的限制，这也意味着我不能把流量从www.nczonline.net导给S3。流量可以从www.nczonline走，但必须设置重定向到www.nczonline.net，才能利用免费的邮件转发（在把顶级域名设置为CNAME的情况下显然是不行的）。

我还是想从S3走流量，因此必须在CloudFlare和S3中间设置一个转换，让S3请求可以通过www.nczonline.net提供。最终我在同一个AWS微实例上设置了Nginx，并用它作为到S3的代理。试验几次后，我发现S3只是查看Host首部来决定是否提供流量，于是通过下面的配置就可以简单解决这个问题：

server {

    # Listen for traffic - old school and new
    listen 80 default_server;
    listen [::]:80 default_server ipv6only=on;

    # Setup the hostnames that are allowed for this server
    server_name nczonline.net www.nczonline.net;

    # Proxy all requests to AWS
    location / {
        proxy_set_header Host nczonline.net;
        proxy_pass http://nczonline.net.s3-website-us-west-1.amazonaws.com/;
    }
}

在设置Nginx指向S3后，我又在Nginx上指向CloudFlare，我的站点终于正常工作了。不仅如此，Nginx还会自动压缩HTML、CSS、JavaScript，这又给我省了钱。

到这里，似乎我只要把域名指向Nginx，而不用再使用CloudFlare了。可是，CloudFlare的边缘缓存、DDoS保护和免费SSL功能（全部免费）让我觉得还是值得拥有。

值吗？

整个过程比我想象得要麻烦，不过我觉得很值得。我了解了AWS、GitHub和Jenkins，对通过S3提供内容服务应该权衡哪些因素，以及存在哪些限制也有了经验。但最令我欣慰的还是拥有了对自己博客的全栈控制权。使用WordPress总让我不太放心，性能问题、数据库故障、安全漏洞都让人担忧。而且，一想到自己的内容保存在数据库的某个角落时，就觉得不舒服。最近我基本上只用Markdown来写作，因此保持这种内容格式并通过Git仓库控制版本是我必然的选择。这样不管发生什么事，我的内容都可以信手拈来。