具体问题:迁移WordPress到App Engine

为了让这个博客更好地写技术文档,我希望安装一些更加扁平式设计的模板。但是距上一次升级博客已经很久了,WordPress版本已经到3.7.1,新的模板也大多工作在这个版本下,而且,需要的环境是PHP5/MySQL5;所以,我不得不考虑升级我的系统平台。

首先我想到的是将博客迁移到Google App Engine上——之前我已经在上面创建过两个小应用,它是免费的,并且提供域名绑定。

我参考了这篇官方文档:Running WordPress in App Engine,根据步骤,先下载PHP SDK for MAC,安装后遇到了一点小问题,它必须从虚拟盘拖放到MAC本地硬盘,我拖放到/Library并安装到/usr/local/bin后,误认为/Library下的安装文件是可以删除的,删除之后发现/usr/local/bin下的*.py都不工作了。这让我不得不重新安装SDK一次。

安装MySQL,并启动它,使用SQL语句创建数据库;下载WordPress,在本地配置好App Engine需要的文件后,运行命令启动站点:

$ APP_ENGINE_SDK_PATH/dev_appserver.py APPLICATION_DIRECTORY

访问http://localhost:8080,一切正常,导入事先从原博客导出的xml文件,下载原始图片与附件,一切完美。

接下来创建Cloud SQL让我有点小头疼——它是需要付费的,最便宜的价格$0.025/hour,计算了一下,一年¥1100+的费用已经超过了目前虚拟主机商的¥400,但为了体验一下云数据库的魅力,我还是毅然地输入了信用卡号。

瞬间收到短信被扣除了$1.

建立Cloud SQL instance非常简单,几乎就是输入instance id,选择费用方案,完成后它会自动启动到可用状态。继续下一步,我读到,在Cloud SQL上运行SQL“有多种办法”——意思是运行起来有点麻烦——它写到:“我们在Cloud Storage上提供了一份公开的初始化数据库的脚本供你使用。”我检查了这份脚本,是使用默认的用户名、密码创建一个MySQL数据库,抱着先试试的态度,我在我的instance上导入了这份脚本,并修改WordPress的数据库配置以访问Cloud SQL:

if (isset($_SERVER[‘SERVER_SOFTWARE’])
&& strpos($_SERVER[‘SERVER_SOFTWARE’],’Google App Engine’) !== false) {
define(‘DB_HOST’, ‘:/cloudsql/YOUR_PROJECT_ID:wordpress’);
} else {
define(‘DB_HOST’, ‘localhost’);
}

部署本地的WordPress到App Engine:

$ APP_ENGINE_SDK_PATH/appcfg.py update APPLICATION_DIRECTORY

访问http://your_project_id.appspot.com,出现了WordPress的安装页面,所有本地数据库的内容不会随着update命令发布到App Engine.

问题一:WordPress importer导入旧博客数据遇到文件夹无法写入错误

因为一开始我在本地安装好了importer并测试了导入;所以这次我没有发现在App Engine上是无法安装插件的。收到文件夹权限错误后,我本能地在App Engine上寻找文件夹,不幸的是,它是完全没有文件夹结构的,在百度App Engine上我可以看到我的文件是通过SVN或Git部署到云存储中,但在Google App Engine中找不到我的源代码。在尝试了StackOverflow的搜索后,我明白了Cloud Storage和File System是完全不同的两个概念;继续浏览Google的安装文档,我还需要安装Google App Engine for WordPress我才能使用文件上传功能,测试发一篇文章,果然图片上传功能全部报权限错误。

我尝试安装这个插件。安装插件页面正在报错;Google文档告诉我所有的插件都需要在本地安装再部署到App Engine.

问题二:Cloud SQL对数据导入支持太差

于是我尝试能不能从数据库入手直接导入我的数据。instance创建后,没有直接数据导入的接口,更没有phpAdmin这样的界面供我操作。回到那个“有多种方式在Cloud SQL上执行SQL”的文档,我快速查阅了一下如何导入数据。

第一种方式是上载MySQL的数据库备份,先上载到Cloud Storage,再使用“导入”功能,Cloud Storage和Cloud SQL之间缺乏直接访问的通道,包括导入地址,都不得不手动输入。奇怪的一点是,我不知道一个instance是否支持多数据库,我使用不同名的数据库备份,日志告诉我导入成功,但访问站点却出现数据库连接错误。Cloud SQL没有提供任何错误记录,无法排查错误原因。

第二种方式是执行Cloud Storage上的SQL语句,我重新创建了一个instance,悲剧的是instance id一经使用过,即使删除后都是不能重用的,浪费了许多良好的数据库命名。但这样一来,我不得不又回到了一个空白的数据库,又需要解决文件写入的问题。

最后我发现Google App Engine不翻墙是无法访问的……所有我删除了所有的Project、Instance,也关闭了Billing……共计花费$1,一天时间,未来是否还有帐单还未知。

接下来我尝试了一下百度App Engine,操作上太混乱了,常常迷失在个人帐户、百度BAE、云存储的导航条中不知道该怎么回去;辛苦搭建好后(使用百度提供的WordPress Config文件),访问站点,404错误,Google搜索告诉我百度BAE上必须使用专有的WordPress,但我没有使用百度版WordPress的兴趣。

新浪BAE点第一个按钮就提示我要“云豆”,赶紧退出来了。综合来说,我需要的是一个平台,而不是一个完整的应用——否则我自己搭建网站干嘛?不如注册一个免费的博客。

最后的最后我联系了我的主机服务商,他们告诉我升级到PHP5+MySQL5是免费的……然后经过两个小时,我的博客升级成功了。唯一的小插曲是我先使用自动升级,它会根据数据库记录的域名跳转回旧主机上,又会提示我PHP版本过低;手动升级后还需要把数据库重建一次才能正常访问。

这一天的尝试说明了什么呢?如果WordPress可以看着是一套旧系统,向云端迁移时,它会遇到以下问题:

存储层要完全重写

数据库、文件,等等……我们要面对的不是文件系统,应用程序运行环境与存储层是完全分离的。就算之前你已经采取了分布式文件存储,Cloud Storage的结构和File System也是完全不一样的。如果系统中没有良好的API设计,迁移的难度将非常之大。

数据库可操作性太弱

不知道是不是费用少功能也就最少,但可操作性太差的数据库,这个弱点是致命的。无法直接运行SQL,连phpAdmin的功能都不具备,Cloud SQL还需要改进太多。

部署方式千奇百怪

Googel App Engine需要一个本地的运行环境,这个有些让人费解,而且这个本地运行环境还是无法和云端进行数据库同步的。另一种部署模式如Heroku只需签入代码,这种操作更加轻量级。百度BAE上还要把代码打包成zip文件,再用网页上传zip包的方式就太倒退了……

,
© 2018 Silent River All Rights Reserved. 本站访客数人次 本站总访问量
Theme by hiero