与MONGO_URL对抗捆绑的"meteor run --production"

Question

也许我的问题与此重复,但我觉得它增加了一些细节,使它有所不同.

我目前有一个Meteor Docker设置,基于节点:0.10图像,首先捆绑应用程序并运行"node main.js"作为其CMD.该映像还安装Meteor并使用其命令引导环境并安装必要的软件包.

在我看来,如果使用节点:0.10,我可以使用更小的Linux映像并简单地安装curl/git/meteor,那么图像将大大简化.删除构建步骤将进一步简化事情,因为根据我的理解,"meteor build"无法构建移动应用程序,如果它们已配置但不需要(即如果我通常构建Android/IOS应用程序,我不能轻易如果我只想要一个包,就不要构建它们.此外,我的开发环境已经使用了MONGO_URL和一个容器化的MongoDB实例,因此在开发时我甚至都没有使用本地数据库.

那么,"meteor run --production"与一组MONGO_URL和"node main.js"之间有什么区别？在一个实例中发生了什么,而在另一个实例中没有？

特别是,"流星运行 - 生产"是否检测到MONGO_URL的存在而不是旋转一个单独的,未使用的mongod？我清楚地看到MONGO_URL指向的数据库中的数据,但我不确定meteor命令是否会旋转一个单独的数据,并且会浪费CPU周期/ RAM.基于上一个问题,我收集它仍然会轮询文件系统以进行更改.但这只是在Linux下使用inotify吗？我认为这是一个相当小的性能影响我是否正确？

我想,如果我需要服务器的每一盎司性能,捆绑是可行的方法.但是,如果使用MONGO_URL设置运行"meteor run --production"只会导致轻微的性能损失,同时大大简化了我的设置,那么简化我的Dockerfiles并将我的开发/生产设置更加紧密统一对我来说可能是值得的.

谢谢.

Answer 1

值得注意的是meteor run --production......意味着"在模拟生产的开发环境中运行"而不是"这就是你应该如何在生产中运行你的应用程序".

因此,development当您运行上述命令时,process.env.NODE_ENV将设置为.

https://github.com/meteor/meteor/issues/180#issuecomment-30043150