服务提供商 | 部署方法 | 如何配置环境变量 | 性能 |
---|---|---|---|
Nodejitsu | CLI | CLI/web界面 | 马上就搞 |
Heroku | git | CLI | |
Modulus | CLI/网页上传 | CLI/web界面 | |
App Fog | CLI | CLI/web界面 | |
Azure | CLI/git | CLI/web界面 | |
dotCloud | CLI | CLI/.yml文件 | |
Engine Yard | git | ey_config npm模块 | |
OpenShift | git | SSH + 创建文件 | |
CloudFoundry | 马上就搞 | 马上就搞 |
我开始于一个简单的Express应用,并使用了nconf以便简洁的用一个配置处理多个平台上不同的监听端口设置方法(有时候是必须要设置的),同时加入了一个傀儡变量SECRET。nconf会首先查找传给node命令的参数,之后查找环境变量,然后尝试加载根目录上一级的config.json文件,最后回退到我们在代码中设置的默认值。通过这个过程,在应用被加载时,我就能了解到我们的设置有没有从以上的几个外部来源中被正确的读取到。如果没读到,那么加载应用的响应值就会是默认的SECRET。如果我能获取应用启动后的日志,我还能确定应用所监听的端口号——它被记在NODE_ENV环境变量中。
最后,我在package.json文件中设置了这个对象:"engines": { "node": "v0.10.x" …,以观察各平台的不同反应。
以下排名不分先后……
作为首批提供Node.js托管服务的提供商之一,Nodejitsu成了Joyent的官方合作伙伴——在Joyent终止了他们的no.de服务之后(搞毛,这域名多牛掰)。Nodejitsu现在没有永久免费服务了,但是他们提供一个每月$3的廉价独立方案,还有一个30天的免费试用。
根据文档所说,你可以用任何你想用的端口号,只要是80端口或者大于1024的端口就行。
用我们自己的SECRET设置去覆盖默认值很容易。可以用CLI或者web界面来搞,和其他几个本次一同参测的平台一样。
将你的代码推送到Nodejitsu云平台需要通过一个特制的命令行应用(CLI),可以通过npm安装。注册之后你会马上被扔到一个附带安装指令的github repo,虽然这点还算好——但总的来说安装过程还是挺蛋疼的。你得选择一个子域名,然后它会被自动添加到package.json文件里。从我做过的几个测试来看,部署还是很快的。系统会自动增加package.json里的version属性的值,虽然这对我来说无所谓,但有的人可能会觉得很烦。
整个过程中有三个小挫折。第一个是版本问题。部署过程中系统提示如下信息:
info: jitsu v0.12.10-2, node v.10.4
同时人家告诉我系统还不支持0.10.x,必须得用0.8.x版本才行。
第二个是如果我修改了package.json文件里的name属性,系统就不让我部署。
第三个是每回我重新部署的时候,我自己设置的ENV变量都会被抹掉。没准有个办法能解决这问题(译者注:但显然作者没找到)。
Nodejitsu以Node.js为中心这一点让我尤为称道,反正自定义设置是通过标准的package.json文件来处理的。你甚至可以自定义部署前(predeploy)和部署后(postdeploy)的钩子(hook)。我个人感觉部署应用和查看日志都挺方便的。
虽然Heroku用"toolbelt" CLI来管理你的账号和应用,但部署过程得用git来完成。你只需要把他们给你的endpoint作为remote加入到你的git配置里去就行了。由于他们不光提供Node.js服务,所以当我发现他们居然支持v0.10.6的时候我真的很兴奋!
我第一次的部署看起来是成功了,但随后收到的错误信息迫使我去研究一开始得给这个应用配置多少资源才行:
heroku ps:scale web=1
之后就一切顺利了。
三个月之前我才第一次尝试在Heroku上搞我自己的项目,一方面是因为我对设置自己的服务器多多少少有点偏执,另一方面是因为Heroku把node.js作为一种追加方案来提供(译者注:也就是Node.js不是Heroku最重要的产品)。不过如果能忽略不支持WebSocket以及有误导性的市场策略和统计信息这俩情况,那这也能算是一次如丝般顺滑的体验。
他们下了大力气弄出来这个既漂亮又实用的控制面板,还附带几个很方便的特性(你在别处一般找不到),比如设置某个S3托管的文件作为自定义的404页面,以及向其他用户转移项目所有权的功能。
评论删除后,数据将无法恢复
评论(5)