主机升级到AWS的t2.micro

亚马逊很厚道,价格实惠量又足。

最近把博客的主机升级到了AWS的t2.micro机型,现在博客有了更好的性能和更低的成本。当然一定程度上也是不得已而为之。之前我一直在使用EC2+RDS的架构,原因是EC2的t1.micro的内存太小(613M),不足以同时运行Apache和MySql,于是我就购买了额外的RDS服务,RDS价格有点小贵,大概$200一年。当得知EC2新的t2.micro机型有更大的内存(1G)之后,RDS首当其充地被弃用了。由于新的t2.micro价格比t1.micro低,又不是需要RDS了,于是博客的成本下降了一大半,现在大约是$150一年(东京机房的价格,美国的机房可以降到$100以下)。相比之下,专门的Wordpress主机(如Bluehost)的动辄$100、$200一年的费用,显得非常不值得。

用虚拟主机的术语,EC2的t2.micro提供了以下服务:

  • 1G内存
  • 至少8G存储,无上限,每GB价格$0.12每月。
  • 无限流量,每月最初1G免费,之后每GB $0.2。
  • 无限绑定域名。
  • 无限MySQL数据库,容量取决了存储空间大小。
  • 无限绑定邮箱。
  • 免费独立IP。
  • 不仅支持cPanel(可自行安装),还可以直接SSH到主机上进行管理。
  • 可配置VPN,无额外费用。

另外值得一提的是,t2.micro升级了Burstable Performance的管理。Burstable Performance是EC2的一项技术,作用是短期内提升主机的CPU性能。由于EC2的主机都是虚拟机,平时要和宿主上的其它虚拟机分享CPU,而micro机型一般只有10%的额度。EC2允许micro机型短时间内使超过10%的CPU,以应对突发状况,比如瞬间的大流量,这种技术称为Burstable Performance。在t1的时代,Burstable Performance只有一点点时间,大概1分钟,超过一分钟就会被EC2强制减少CPU的使用,非常不人性化。而在t2的改进是,Burstable Performance有了Credit的概念,如果一段时间内CPU的用量很少,就可以攒Credit,然后当需要大量使用CPU的时候则消耗Credit。这样就比t1允许更长时候的高频CPU使用,使t2.micro在实践中更高效。

保护WordPress的帐号安全

使用Wordpress写文章,无论是在Wordpress官方,还是自建的博客,都需要至少一个帐号。而Wordpress到目前(3.9.1)为止,都只提供了弱智的用户名/密码的登录方式。这种方式可以被数不清的方式来破解。最简单的一种是暴力破解,就是一个一个的尝试可能的密码组合,如果密码的长度不够,比如少于8位,可能会在一、两天之内就破解掉。由于博客的是公开并一直在线的,暴力破解也没有高深的技术含量,任何人只要有一个暴力破解工具,都可以进行尝试。于是Wordpress的帐号安全性相当差。

以前我试过一个插件,它提供了登录时的两步验证,两步验证本身固然是非常安全的,但是插件就不一定了,就像上一篇文章所说,如果插件的设计有漏洞,也可能被用来进行攻击。所以任何用于保护帐号安全的插件,都是一把双刃剑,在提供多重验证的同时,又打开了另一道门……

那有什么不用插件的保护方式么?答案是有的,只是不那么方便。

WordPress的登录入口是wp-login.php,所有的登入登出的逻辑都在这个文件中,而一旦登入完成之后呢,之后的操作则依靠wp-admin/目录下的其它文件。于是,只要防御好wp-login.php,Wordpress的帐号就不会被暴力破解。我的方法是这样的:在Apache中把wp-login.php设为不可访问,只有当自己需要登录的时候才把权限打开。示例代码如下:

由于Wordpress的登录会持续一段时间(好像是一个月?),于是在这一个月中都不需要去动Apache的设置,只有在一个月后浏览器的cookie失效的时候,才要麻烦一点去重启一下Apache。使用虚拟主机的朋友们也可能通过修改.htaccess文件来达到类似的效果,比如使用mod_rewrite把wp-login.php重写到根目录。至于其它的帐号安全,比如SSH的密码,或者虚拟主机的CPanel帐号等,那又是另外一回事了,以后再说。

这样做的好处是不需要安装任何的插件,简洁、高效,更不用担心插件的升级维护问题,同时也达到了和插件一样的安全防护的目的。一举两得。

谨慎使用WordPress插件

WordPress的主要功能之一就是插件,它庞大的插件群使它可以被打造成各式各样的Wordpress,不仅有博客,下载站,还有电子商务网站。不同的插件提供了不同的功能,丰富了Wordpress的用途;功能类似的插件互相竞争,互相提升,也使得Wordpress越来越强大,越来越受欢迎。

但是插件丰富的同时,安全问题也需要被重视起来。

WordPress的开发背后有一个商业机构支撑,它可以保证各种漏洞的及时修补;和Wordpress自身不同的是,众多Wordpress插件都是非盈利的,由一、两个开发人员维护着,有些甚至不经常维护,很久不更新。这样可能导致某些安全漏洞长期存在,被黑客利用。这不,前几天又爆出几万个Wordpress站点因为装了某个新闻插件而被黑客利用的新闻。

在良莠不齐的插件面前,博客主仅有的选择就是谨慎使用Wordpress插件,或者尽量不使用插件,如果必要的话,尽量使用收费的商业版本。这并不意味着你一定要付钱,只是如果一个插件是收费的,说明它背后有商业化的团队在支持,可靠性更高。

目前本站使用的插件,除了几个官方发布的如Akismet外,第三方插件只有6个:

1. Enigma:这个是我自己写的插件,用来防止文章中的敏感信息,如Email地址,被爬虫收集。具体用法见此,由于它只有一个php文件,并且完全没有UI界面,相当安全。

2. Shortcode Exec PHP:用来在文章中插入一些常用的php代码,比如连接Gist的代码。这个插件目前已经没有人维护了,我也正在打算弃用它,但由于使用得比较多,还需要一点时间。

3. Subscribe to Comments Reloaded:用于给博客的访问发送更新的通知,包括新评论的通知。

4. W3 Total Cache:非常牛x的缓存插件,可以极大地减轻服务器的负载,没它不可。

5. WordPress SEO:SEO插件,提供了一些必要的SEO功能

6. Yet Another Related Posts Plugin:用于在博文下方提供其它相关博文的链接,有助于SEO。

另外,减少插件的数量,也能一定程度地减轻服务器的负载,毕竟需要运行的代码少了,或多或少会快一些。

在Chrome中开启高分辨率支持

Windows从很早开始就支持了高分辨率(High DPI)的显示屏,在显示设置中使用高分辨率来使屏幕上的字体和图像变大,但不会模糊。效果如下(图片来自网络),和Retine版本的Macbook Pro上的效果类似:

但不幸的是,High DPI的功能需要应用程序支持。也就是说,如果应用程序不支持High DPI,即使在Windows中设置了,会造成应用程序的界面变得模糊,字体很虚,不容易识别。但很多开发商都不重视High DPI这个功能,以至于它到现在都没法正常地使用。Chrome也是一直到了37.x (目前的Beta)才支持High DPI。

设置方法如下:

  • 打开注册表,找到目录:HKEY_CURRENT_USER\Software\Google\Chrome\
  • 如果其下没有Profile这个键,就创建一个新的,方法是右键单击“Chrome”键,“新建”->“键”。
  • 在Profile中新建一个名为“high-dpi-support”的“DWORD值”,把它的值设为“1”。

然后重启Chrome就可以了。如果你觉得有什么问题,想把High DPI的功能关闭,直接把上述high-dpi-support的值改成“0”即可。

使用Cloud 9在线编写GAE应用

最近在尝试写一点GAE(Google App Engine)的应用,以丰富自己的业余生活,同时也提升一下“全栈”的能力。在大公司的一个缺点就是每个人都只能接触到项目的一部分,在本职工作上的能力固然很强,但“从无到有”的开发能力则偏弱。这对于拓宽自身能力和视野都是有阻碍的。

先说一下这是个什么样的应用:
GAE是一个性价比很高的平台,运行一些小程序几乎免费,而且有免费的流量和存储,对于新手入门网络开发再好不过了。相比之下,AWS和Azure都显得诚意不足,AWS给提供了一年的免费额度(每张信用卡),Azure则是每天免费一小时。尽管在GAE上面开发没那么自由,它不是完整的机器,只支持4种语言,但对于新手来说,这或许算是一个优点。

我的计划是做一个短链接工具,类似t.cn、bit.ly。市面上这类工具有很多,为什么还要再做一个呢?我一直都在使用短链接功能(如mv2.it/gtranslate)。之前用了一个工具:YOURLS,它是一个很强大的工具,并且开源,可以随便部署在自己的服务器上。和公开的短链接工具不同,自己部署的实例可以选择好看的链接,比如上述的“gtranslate”,而不是几个随机字符。使用YOURLS的问题是,在AWS上升级一下太麻烦了,要SSH到主机上,下载新版文件,再复制到Apache的路径下。而且我对PHP也不熟悉(后面会详述),如果想添加一些功能会比较痛苦。但细想一下,短链接工具的内部逻辑其实很简单,它连关系型数据库都不用,一个哈希表就可以存下所有数据了。而且界面也简单,开发起来很方便。于是就有了自己做一个的动力。

接下来是开发环境:
在语言上我选择了Go。一开始我试过Java,因为Java是在GAE的4种语言中我最熟悉的一种,上手没有阻碍。但是后来发现,实现同样的功能,Go只需要大概十分之一的代码,而且Go提供了丰富的标准库,不需要去找第三方的,尤其是文档不足的,开源库。然后我就把Java的代码全删除了,完全用Go编写。之所以不考虑Python和PHP,是因为它们是弱类型且不用编译的。我在Javascript中已经吃够了苦头,虽然解释型语言有着各种各样的自由,但我依然需要一个编译器来帮我做一些粗略的检查,那些不必要的错别字、大小写问题可以很快被找出来,也省去了很多测试用例。如果要我新学一问语言,我肯定会考虑可编译的强类型语言,于是我就选了Go。

至于IDE,暂时这还是Go的弱项。由于是一门新语言,附属设施的建设还不到位。Eclipse的官方库还没有包含Go的编辑器,有几个开源工具正在开发中(进度不详);各类文本编辑器都有对Go的语法支持,但对标准库的自动补全暂时还都没有。不过正因为它有编译器,自动补全的必要性也不是那么强了。于是我用Sublime Text写了一会,感觉还可以,除了免费版经常跳出来版权提示之外,没什么不满意的地方。但后来,我还是把开发环境移到了Cloud 9上面去。

为什么选择Cloud 9?
Cloud 9是一个在线开发环境,大致相当于一个EC2的主机,提供了网页版的文本编辑器和命令行(Shell)权限,并且可以和Github无缝整合。这比起自己找一台机器,搭建一个Git开发环境要方便多了。关键一点,Cloud 9是免费的,比起自己搭建的机器肯定是便宜的,至少省电费。Cloud 9的优势是可以绑定Github帐号,直接使用“git push”就可以同步代码,密码都省了;并且提供了方便的预览(Preview)功能,写Markdown和网页都很方便。

如何在Cloud 9上部署GAE?
Cloud 9的基础用法就不介绍了,通过UI操作很直观,不需要看帮助就可以上手。要把工程部署到GAE上去,你需要一个GAE的SDK。以Go SDK为例:

先把SDK下载下来:
wget https://storage.googleapis.com/appengine-sdks/featured/go_appengine_sdk_linux_amd64-1.9.7.zip

解压到.go_appengine目录,使用“.”开头可以让它不在Cloud 9的树型目录中显示出来:
unzip go_appengine_sdk_linux_amd64-1.9.7.zip
mv go_appengine .go_appengine

在~/.bashrc中设置环境变量:
export GOROOT=/home/ubuntu/workspace/.go_appengine
export PATH=$PATH:$GOROOT
export GOPATH=/home/ubuntu/workspace

其中workspace的实际路径可以通过echo ${PWD}找到。

接下来就可以使用goapp部署了。假设当前路径是工程的根路径,直接运行goapp deploy即可。

Cloud 9有哪些不足之处?
目前唯一发现的不足之处是,Cloud 9的免费版是公开的,也就是说你的workspace是公开的,任何人可以查看。这样就不可以使用.gitignore来忽略一些敏感文件(比如包含密码的文件)了。在设计代码的时候需要格外小心。

暂时没有发现其它问题,发现了再补。