2012年二月月 发布的文章

Blog新起点 – 从BlogBus搬家到WordPress

 

今天着实是一个值得纪念的日子,因为我终于完成了从BlogBusWordPress的搬家工作,从此我的Blog将站在一个新的起点上。
 
自从2004年开博以来,我坚持了七年多,至今仍孜孜不倦,写博客已经成为我的生活中不可或缺的一部分,即使在微博等大行其道的今天,我亦然如此。作出搬家的决定显然是十分痛苦的,因为要抛弃已经建立起来的使用习惯以及Blog人气(包括搜索引擎索引、外部引用的等)是十分艰难的。但我还是决定搬家,更多是因为我的一个小小的梦想:拥有一个自己可以完全控制的独立域名的个人站点。
 
tonybai.com这个顶级域名是在2010年申请的,2010年末曾经尝试过一次搬家,但因技术原因最终没能实现。但鉴于BlogBus提供的服务愈发地不稳定,我又动了搬家的念头,而且有了上次失败的教训,这次我做好了充足的资料和技术准备。但即使如此,搬家过程依旧很辛苦,并且足足花了我一周多的业余时间,下面就来罗嗦一下搬家的过程。
 
一、准备工作
· 申请域名
2010年我在dreamhost申请的tonybai.com。
 
· 购买主机服务
目前我的主机由91host.net提供,最初是我的同事Puras免费提供的。
 
· 安装WordPress
由Puras帮忙在我的主机空间上安装了WordPress 3.2.1。
 
· 从BlogBus导出Blog数据
使用BlogBus后台管理提供的导出工具,将你的Blog导出,顺利地话你将得到一个类似backup-20120217204644.xml这样的文件。导出后用编辑工具打开瞧瞧,看看导出的是否完整。
 
· 将BlogBus数据文件转换为可导入WordPress的数据文件
这次搬家我直接使用了"爱写字"提供的转换服务。首先在"爱写字"申请一个博客,然后通过其导入工具将上面导出的BlogBus的数据文件导入到"爱写字"中,我的导入过程很顺利,没有报错,但遗憾的是我在BlogBus上回复朋友的评论无法导入。
 
· 修改Blog文章和链接
"爱写字"支持免费域名绑定。我先将tonybai.com绑定到"爱写字"上,然后直接在"爱写字"上修改博客数据,包括建立分类、修改每篇Blog的自定义地址、内容中的链接以及自定义标签,这是一个极其繁琐且痛苦的活儿,也是整个搬家过程中最最耗时耗力的环节,我足足花了一周多。
 
· 导出WordPress数据文件
通过WordPress后台的导出工具,将修改好的Blog数据导出,这里有一个缺陷:那就是你的友情链接数据无法导出。
 
二、WordPress站点配置及数据导入
· WordPress设置链接格式
进入WordPress控制面板,选择"设置"->"固定链接",设置链接形式为:"http://tonybai.com/2012/02/29/sample-post/",之后WordPress提示我需要修改".htaccess"文件。由于之前没有该文件,我按WordPress的提示,编辑好.htaccess文件后,上传到站点根目录下。
 
· WordPress媒体设置
进入WordPress控制面板,选择"设置"->"媒体",去除"以年—月目录形式组织上传内容"选项,统一使用默认的上传文件目录(需在wp-content下手工创建uploads目录)。
 
· 安装WordPress Importer插件
WordPress的导入功能是通过插件提供的,我们需要手动安装。在"安装插件"中搜索"WordPress Importer",得到结果后,点击"安装",WordPress就会自动进行插件安装。
 
· 导入WordPress数据文件
WordPress Importer安装完毕后,即可进行数据导入。导入前先用Ftp工具将uploads目录权限设置为777,然后选择本地要导入的文件,导入即可。WordPress Importer支持.gz结尾的压缩文件,它可以在上传后自动解压并导入数据。
 
· 配置WordPress Theme
我选择的是"Notepad Theme 1.3",这个比较简单,不多说了。
 
· 设置边栏布局
通过控制面板中的"外观"-> "小工具",我们可以通过拖拽的方式自定义边栏的布局,比如使用分类、日历、标签云等。
 
· 安装必要插件
目前我安装的必要插件有CKEditor for WordPress、Akismet、Copyrighted Post、Google XML Sitemaps、WP-RecentComments、BackUpWordPress、Google Analytics for WordPress等。
 
· 安装robots.txt
为了控制搜索引擎的行为,编写了一个robots.txt,放到了站点根目录下:
 
  User-agent: *
  Disallow: /wp-
  Disallow: /feed/
  Disallow: /?feed
  Disallow: /comments/feed
  Disallow: /trackback/
 
· 设置Feed
为了编译了解订阅情况,我增加了一个二级域名feed.tonybai.com用于统一Feed地址。我通过Feedsky提供的服务将feed.tonybai.com绑定到feedsky提供的一个Feed(http://feed.feedsky.com/bigwhite)上,而Feed源使用的是WordPress自带的Feed地址http://tonybai.com/feed。另外我修改了Notepad Theme 1.3的源码,将页眉的RSS图标对应的Feed地址统一也改为了http://feed.tonybai.com,希望各位朋友也使用这个地址订阅本博客。
  
三、WordPress站点备份
· 采用BackUpWordPress备份整个站点
BackUpWordPress不仅仅可以备份DB,还可以备份整个站点文件。备份前将wp-content目录的权限改为777,这样该插件就会在wp-content/backups下自动定期生成备份文件。如果需要,还可设置将备份的文件mail到指定邮箱中。
 
· 备份Blog文章数据
为了保险,我还会定期将最重要的Blog文章数据导出(xml格式)并压缩备份。
 
四、其他设置
 
· 统计服务
原BlogBus是自带统计服务的,搬到WordPress后我采用两个第三方的统计服务:Google AnalyticsStatCounter,其中Google Analytics可通过"Google Analytics for WordPress"进行设置和验证;StatCounter的安装则是通过在边栏的自定义Html代码区域添加完成的。
 
· 自定义Html代码
新浪微博秀、Google Reader分享等Widgets可通过边栏的自定义Html代码添加到站点上。
 
OK,至此搬家过程的大部分工作都算是结束了,后续还会从BlogBus迁移一些图片到WordPress上,但都是些小活儿了。另外这次虽然离开了BlogBus(博客大巴),但我仍要感激BlogBus这七年来为我提供的免费服务,也希望BlogBus能够坚持地走下去,并且能走得更好。

使用Jenkins实现多平台并行集成

我们的后端C应用都是支持跨平台的,至少目前在LinuxSolaris上运行是没有问题的,这样一来我们在配置持续集成环境时就要考虑如何实现在代码Commit后触发多平台并行(同时)集成这个需求。

之前使用Buildbot时是通过为一个Scheduler配置多个Builder满足这个需求的。但现在要换成Jenkins,我们如何来实现呢?昨天在折腾Jenkins时我把问题想简单了,今天细致查看了一下Build Log后才发现之前的配置并未真正实现多平台并行集成。

最初的Jenkins配置大致是这样的:我在Jenkins上添加了两个节点(Slave Node),分别为x86-linux-ci-slave和x86-solaris-ci-slave,并且为这两个节点设置了一个相同的标签"foo-ci-slaves"。之后我创建了一个新Job – "foo-multiplatform-ci",选择的是"构建一个自由风格的软件项目(Build a free-style software project)"。为了使得该Job执行并行集成,我选择了"Restrict where this project can be run",在"Label Expression"中填上了"foo-ci-slaves",其他配置这里就不赘述了。

按照我最初的理解,这样配置后点击"立即构建",两个Slave Node上就会同时进行相关的集成。但Build Log告诉我事实并非我想象的那样:Jenkins只是在一个Slave Node上执行了Job。那使用Jenkins如何来实现前面所说的多平台并行集成呢?查来查去,我发现原来是我在创建Job时选错了配置,我应该选择"构建一个多配置项目(Build multiconfiguration project)"。

与free-style project相比,multiconfiguration project的配置页面中不见了"Restrict where this project can be run"配置选项,但却多出了一个"Configuration Matrix"配置区域。在该区域中,我们可以选择Slaves,在Node/Label中,我们可以看到当前Jenkins中配置的所有Label和Nodes。选择一个Label是无法满足我们的要求的,那样Jenkins只会从Label中的若干个节点中选择一个来执行集成。所以我选择Nodes,将x86-linux-ci-slave和x86-solaris-ci-slave都选上,保存后我们就会在"foo-multiplatform-ci" Job的主页面上看到两个configuration: x86-linux-ci-slave和x86-solaris-ci-slave。点击"立即构建",这两个configuration对应的小球标志就会同时闪动,这说明"foo-multiplatform-ci"正在两个Slave Node上并行运行呢,这才是我想要的结果。

支持多平台并行集成只是Multiconfiguration Project的一个用途之一,《Jenkins: The Definitive Guide》一书对此有更为细致的讲解,你可以结合自定义Axis(坐标轴)以及parameterized Build实现更为复杂的构建需求。但目前我尚未遇到类似需求,所以这里也不敢乱说^_^。

折腾Jenkins

Buildbot是产品线C应用项目中采用的唯一持续集成工具,一直以来用得还不错。但前些日子部门负责过程改善的同事找到我,说今年部门计划统一各个项目组所使用的Continuous Integration工具,Buildbot有些小众,没有入大家的法眼,部门期望使用的是Jenkins(即原来的Hudson)。既然组织有统一规划,那我自然积极支持。但首先要做的就是评估Jenkins是否能满足我们的需求,并且看看从Buildbot迁移到Jenkins的难度及工作量有多少。这不,今天下午就一直在折腾Jenkins。

一、安装Jenkins
Jenkins(前身Hudson)很流行,在各大主流操作系统平台上都有很好的支持,其安装甚是方便,特别是在各主流的Linux发行版平台上,均可使用OS自带的应用包管理工具进行自动安装;当然你也可以直接在官方下载war包。我采用的就是第二种方式,旨在获得更高的Jenkins版本,不过让我失望的是在Ubuntu 9.04(Java version: 1.6.0_20)上,最新的1.451和1.450版本均启动失败,这也是我之前不太喜欢使用Java实现的工具的一个原因之一 – 总是容易出现莫名其妙的异常,而且较难找到原因,也很难fix,除非自己重新构建war包。在这方面像Python等动态脚本语言就有先天优势,一旦出现问题,我可以直接在源码中定位和修改。

1.441版本的Jenkins让我看到了希望,至少启动是没有问题的。启动是通过下面命令行完成的:
java -jar jenkins.war –logfile=~/.jenkins/jenkins.log –daemon –httpPort=9333

如果你是使用包管理工具自动安装的Jenkins,那么Jenkins将被作为服务安装到指定位置(比如:/etc/default/jenkins),并且在/etc/init.d下面创建了jenkins的init脚本。这样当主机重启后,Jenkins会被自动拉起。但如果你和我一样是手工下载的war包,那你就需要自己来保证Jenkins服务一直可用了。这里的一个简单的方法就是编写一个Jenkins运行的监控脚本,如果发现Jenkins未启动,就启动它,Jenkins_monitor.sh示例如下:

#! /bin/bash

result=`ps -ef|sed '/grep/d'|grep jenkins.war`

if [[ x$result == x ]];
then
        cd '/home/tonybai/proj/jenkins' && java -jar jenkins.war –logfile=/home/tonybai/.jenkins/jenkins.log –daemon –httpPort=9333
else
        echo "jenkins is alive!"
fi

最后将Jenkins_monitor.sh加到crontab中即可:
$> crontab -l
# m h  dom mon dow   command
* * * * * bash /home/tonybai/proj/script/jenkins_monitor.sh

二、配置Jenkins
Jenkins的配置是完全通过Web页面完成的,这点全面超越了Buildbot。关于Jenkins如何配置,网上的资料可谓是汗牛充栋,这里就不再重复了,这里只说说配置过程中遇到的一些问题以及解决方法。

我们的产品需要进行多平台上并行持续集成,也就是说当trunk上有代码commit后,Jenkins应该发现代码变更,并同时通知多个不同Slave平台进行集成。之前的Buildbot是通过手工在不同平台上部署Buildslave满足这一需求的,Jenkins也是支持Master/Slave模式的,但Jenkins比Buildbot更加平易近人的地方在于Slave节点无需手工到主机上安装,只需通过在Web页面上添加Slave Node即可(实际上Jenkins在Slave Node上启动了一个Java程序"slave.jar")。

在配置Slave node时,我遇到了第一个问题:一个x86 Solaris平台的Slave node配置完后始终无法Online,而之前配置相同的一个x86 linux Slave节点却可以顺利Online。

直到查看Log后,我才弄清楚真正的缘由。下面是Jenkins Master通过ssh连接Slave Node的Log节选:

SSH connection reports a garbage before a command execution.
Check your .bashrc, .profile, and so on to make sure it is quiet.
The received junk text is as follows:
######################
  Application Server
    On Solaris 10
######################

hudson.AbortException
        at hudson.plugins.sshslaves.SSHLauncher.verifyNoHeaderJunk(SSHLauncher.java:364)
        … …
[02/14/12 14:03:23] [SSH] Connection closed.

原来问题出在我在Slave Node节点的.bashrc中增加的那段个性化签名。Jenkins无法识别这段签名,从而抛出异常,导致Connect失败。注释掉这段签名后就可以看到Slave Node的状态为Online了。

另外一个问题是有关Mail的配置的。公司的Mail Server年前做了一次升级,将安全连接方式由原先的SSL改为了STARTTLS,而Jenkins只支持SSL。没有mail通知的CI Server显然是不合格的。为此,我再次想起了当时Buildbot的Mail发送解决方案- 使用Stunnel。原先的Stunnel配置因公司Mail Server升级而失效了,所以需要对Stunnel做一些配置调整:

这个配置调整着实花了我一些时间,也走了一些弯路,最后在反复阅读Stunnel配置手册后,才发现让Stunnel在Client Mode下支持STARTTLS,只需要做一项配置修改,即增加"protocol = smtp"这一行,示例如下:
/* /etc/stunnel/stunnel.conf */

client = yes
… …

[smtp]
accept  = host_ip : listen_port
connect = mailserver_ip : mailserver_port
protocol = smtp

这样Jenkins就可以用普通smtp连接方式(非SSL)通过stunnel与公司Mail Server进行数据交互了。

三、创建Job并执行集成
有了Node(没有也行,在Master上也可以执行集成),我们就可以创建Job进行集成了。Jenkins Job的创建和配置也比较简单,这里同样不赘述了。我们的项目有了buildc这样的工具作为铺垫后,其构建脚本就变得相当简单了。在Job的execute shell中填写几行命令即可:

buildc config-make
make check-style
make compile-tests
make run-tests
make

对于setup工程来说,由于buildc的存在,我们也可以通过执行buildc pack build完成构建,甚至是上传安装包到指定位置。所以在折腾Jenkins的同时,我也在考虑是否可以利用Jenkins搭建一套安装包制作和发布系统呢!

四、其他
Jenkins还有一点要优于Buildbot,那就是Jenkins拥有Buildbot所没有的"立即构建(Build Now)"功能(经提醒,buildbot也支持force build功能,只不过需要在master配置中这样来配置:c['status'].append(html.WebStatus(http_port=8011, allowForce=True))),对于我来说,这个功能在调试CI脚本时尤其有用。另外,市面上有关Jenkins的书籍并不多,《Jenkins: The Definitive Guide》算是目前市面上讲解Jenkins最为系统和全面的一本了,目前它也在我的"在读"列表中。

从目前的实验结果来看,Jenkins替代Buildbot是完全可行的,而且迁移难度和工作量也没有太多。由于接触Jenkins时间尚短,其强大的功能还需待日后进一步挖掘。




这里是Tony Bai的个人Blog,欢迎访问、订阅和留言!订阅Feed请点击上面图片

如果您觉得这里的文章对您有帮助,请扫描上方二维码进行捐赠,加油后的Tony Bai将会为您呈现更多精彩的文章,谢谢!

如果您希望通过微信捐赠,请用微信客户端扫描下方赞赏码:


如果您希望通过比特币或以太币捐赠,可以扫描下方二维码:

比特币:


以太币:


如果您喜欢通过微信App浏览本站内容,可以扫描下方二维码,订阅本站官方微信订阅号“iamtonybai”;点击二维码,可直达本人官方微博主页^_^:



本站Powered by Digital Ocean VPS。

选择Digital Ocean VPS主机,即可获得10美元现金充值,可免费使用两个月哟!

著名主机提供商Linode 10$优惠码:linode10,在这里注册即可免费获得。

阿里云推荐码:1WFZ0V立享9折!

View Tony Bai's profile on LinkedIn


文章

评论

  • 正在加载...

分类

标签

归档











更多