下文转自:比较不同的 PaaS 平台上的 Node.js 支持
Node.js的相对 其他的语言来说可能仍然是年轻的,但是它的虚拟主机却有很多的选择。在这篇文章中,我们就来看看几个“平台即服务(PaaS)”提供商。 我这里不涵盖某些“基础设施即服务(IaaS)”的选择,比如 AWS 和 Joyent,尽管这些选择之中的某些PaaS和IaaS之间的界限有一点点模糊。 在这一轮中,我主要考察两个方面:部署和环境变量的配置。我还把一些有关起步,仪表板的截图和对其它的杂项操作的观察囊括了进来。在以后的文章中,我们将会运行一些基础的性能测试,然后来看看架构伸缩难易程度。 |
The Players
设置我开始于一个非常简单的 Express app,使用 nconf可以提供多种不同的方式,让我们可以给app指定端口,监听我们的应用程序(必要时)以及一个dummy变量,我称之为SECRET。它会先寻找节点命令传递的参数,环境变量,然后从根目录的上一级到我们制定的默认位置,尝试加载的config.json文件。当加载app时,我们能知道变量从外部源加载是否正确。如果错误,加载app时将回滚到默认的SECRET。如果我可以访问app的启动日志,也就可以看到app监听在NODE_ENV上的哪个端口。 最后,我设置"engines": { "node": "v0.10.x" ...到 package.json文件中,就可以看到每个提供者如何响应。 现在没有特定的顺序..
|
Nodejitsu
https://www.nodejitsu.com/
变量配置 |
部署发布你的代码到Nodejitsu云是通过一个自定义的命令行接口(CLI)应用程序,安装rpm,注册以后将自动转存到 github 指令版本库. 但整体安装过程是相当痛苦的,当提示你选择一个二级域名,然后会自动添加到package.json文件,在我跑了几个测试中,部署是非常快的. 在每个部署的package.json文件的版本属性是自动递增与的,这不会麻烦我但可能会使另外一些人烦恼.
我遇到了三个小故障,第一是版本控制,在我部署时有信息输出,我展示下: |
部署Heroku的"toolbelt"CLI是用于管理您的帐户和应用,但部署是通过git,你只需要添加终端他们就会为您提供远程在你的git配置中,因 为他们不完全支持Node.js,我很惊喜地发现他们已经支持v 0.10.6,我的第一个部署似乎成功,但是我收到追踪错误引导我发现第一次需要指定有多少资源,我想致力于这个程序: heroku ps:scale web=1 在那之后,它是一帆风顺的. |
Misc Notes and DashboardI didn’t try Heroku for my own projects until about 3 months ago, partly because I have a modest level of comfort in setting up my own servers, and partly because I just figured they treated node.js as an afterthought. But if you can get over their lack of WebSocket support and some misleading marketing and stats, it’s a pretty smooth experience. They’ve also got a very polished and functional dashboard, with some handy features you won’t find elsewhere like pointing to an S3-hosted file for 404 pages, and the ability to transfer ownership of a project to a different user.
|
AppFogAppFog先前因PHP Fog而出名,现在已被CenturyLink收购。你可以指定你想使用的云,如不同地区的AWS、HP以及Azure云。 配置变量变量可通过web控制台或者CLI(命令行工具)设置。设置私密变量毫无问题。 文档要求监听process.env.VCAP_APP_PORT端口,但我尝试使用默认配置也能正常工作。日志显示它在监听57277端口。 部署也是借助CLI工具。写这篇文章的时候,AppFog使用v0.8.14版本,并且忽略package.json里的版本设置。 其他注意事项和仪表盘它的免费计划看起来挺慷慨的。它提供多达8个实例,总共2GB RAM,并可随意分割使用。它也有内置MongoDB的选项。 |
It ignores the node version value in package.json and runs a rusty ol’ v0.6.20 by default, but with some extra steps you can change that. Misc Notes and DashboardI had some problems getting the sample app running at first, so I started over and let OpenShift populate the git repository for me with their sample files. There are a few extra things in there, many of which are tucked under the.openshift directory. These include deploy hooks and config files. The README they include does a good job of laying out the structure and explaining the purpose of each file. But I still got stuck on the fact that I needed to listen on a specific IP address. That mean including this: var ipaddr = process.env.OPENSHIFT_NODEJS_IP || "127.0.0.1"; And then added ipaddr in the app.listen section of my server.js like this: app.listen(app.get('port'), ipaddr, function(){... I’ve had an exchange with the OpenShift folks and they’re going to update their getting started guide to make this more clear. |
CloudFoundry
At first look, CloudFoundry has a clear and friendly process for
getting started. However, a few screens into the process I was presented
with this message:
*We are in a time of transition:*
You are reading V2 documentation... Cloudfoundry.com will be upgraded to V2 in June 2013.
So I’ll circle back to them in the next installment of this series.
Until Next Time
Needless to say things are changing quickly in this space. Don’t put too much weight on any specific detail here without first checking for updates. For example, in the couple of days that it took me to type this up, Modulus sent out an email about upgrading their version of Node.js.
In future posts I’ll be walking through how we can monitor and test the performance of these platforms, and then take a shot at scaling them. In the meantime, let me know if I’ve missed your favorite Node.js PaaS.