【发布时间】：2013-08-15 20:09:45
【问题描述】：
我有一个作为单实例部署运行良好的meteor.js 应用程序，但现在我想设置基础架构以启用和自动创建更多实例（每个客户端1 个）。
我打算为每个部署都有一个为给定客户端保留的子域。
我想我必须：
- 为每个客户检索所需的子域（通过某些注册站点）
- 捆绑应用程序
- 在单独的端口上部署一个实例，每个端口都有一个单独的数据库
- 设置反向代理将子域转发到适当的内部端口
- 设置一些东西来监控进程并在它们崩溃或重新启动时重新启动它们
- 在更新和发布应用程序代码时自动重新捆绑并部署到所有实例
据我所知，我认为适合这项工作的工具属于编排系列（Capistrano、Fabric、Func、Rundeck），但我不明白他们负责哪些部分以及哪些部分是/应该是留给其他工具。
我的很多问题都来自于不知道如何连接这些步骤和/或是否应该连接它们。其他人则来自于不知道最佳实践是什么，或者不知道在哪里可以学习围绕做这类事情的设计模式。
例如：
- 我知道如何在命令行上捆绑应用程序，但该步骤是否应该是 shell 脚本、python 脚本或 ruby 的一部分......部署中的第 2 步也是如此（我知道如何在命令行，但不是如何自动化它）
- 我想我可以设置一个反向代理，但我不知道有哪些反向代理工具可以动态修改或配置，以及是否有任何脚本语言适合进行动态配置。
- 我不知道在更新/重新部署应用程序时需要或应该考虑哪些因素。
基本上，似乎有很多工具和相当多的方法来做这些事情，但很少有关于哪些工具可以很好地协同工作或如何正确地做到这一点的指导。如果我不觉得选择一组可以很好地协同工作的工具实际上是掷骰子，我会非常积极地学习必要的工具和语言。
【问题讨论】：
-
我和你有类似的想法，但最终以完全不同的方式接近它：groups.google.com/forum/#!topic/meteor-talk/8u2LVk8si_s。您确定完全有必要为每个客户端实际运行一个单独的应用程序，还是一个为应用程序提供隔离外观的插件就足够了？它也将减少资源密集型。
-
我不确定您在这方面是否仍然需要帮助 - 因为您在不同的线程上有另一个非常相似的 Q。也就是说，如果所有应用程序共享相同的代码库，您不应该尝试为每个子域生成一个服务器实例。相反，正确的模式是使用 * DNS，让 nginx 池化请求，然后在客户端连接时通过读取 Meteor 中的标头来隔离子域。横向扩展是通过跨服务器通信（目前仅限于 Meteor 直到 Galaxy 登陆）或无共享架构来完成的。
-
是的，随着我对域空间的了解越来越多，我尝试以两种不同的方式提出这个问题。对我来说，为每个子域生成一个服务器实例似乎比正确和安全地隔离应用程序要容易得多（即使它不能扩展）。话虽如此，我显然在这个领域没有经验，所以我会相信你的话，这是正确的方法。如果你们中的任何一个有兴趣查看代码，我很乐意为顾问的帮助付费。
-
@StephanTual 顺便说一句，我尝试查看您的博客/网站stephantual.com，它似乎已关闭
-
谢谢@funkyeah，我确实已经关闭了那个vps，以便与DDP客户一起尝试新事物哈哈......流星恐怕是一种瘾：D
标签： javascript shell deployment meteor