什么是最好的Playframework 1.x部署策略?

jos*_*hua 10 playframework

我开发了一个基于Play Framework的小应用程序(我还在学习).现在我需要捆绑它以便运输.一种方法是创建一个war文件并将其部署在一个servlet容器中,例如tomcat-这在文档中非常清楚.另一种选择是使用内置的http服务器.这是我想要做的,因为它是推荐的方式.

现在我如何从我的开发应用程序中取出应用程序,以便将其部署到生产服务器中 - 我的意思是如何编译和生成可以分发给我的客户端的捆绑包,这些捆绑包将执行类似解压缩分发停放和运行脚本启动服务器?

或者我这样说,我是否需要在生产服务器上设置播放路径,然后将我的项目文件复制到生产服务器,以便我的用户可以使用play run运行它,就像我在开发环境中一样?

文档只说我需要改为生产模式.

i.a*_*iel 21

让我解决一些事情.没有必要错,但肯定是不准确的:

你肯定需要在你的环境变量中玩游戏

不,你没有.Play是一个包含大量脚本的文件夹.所有播放需求都是Java安装和JAVA_HOME定义.我甚至认为,您可以通过命令行定义Java.您可以使用没有环境变量的绝对路径来调用play.例如,您甚至可以在应用程序中提供框架.

如果你想要自动部署,恕我直言,没有办法围绕WAR文件.

不正确.我通过Hudson/Jenkins为我的所有播放应用程序使用自动部署,并且我不使用WAR.Play应用程序只不过是一个包含Java源代码和配置文件的文件夹.您可以将它们打包为ZIP/TAR/RAR /您想要的任何格式,并使用脚本来运行/安装它们.

另一方面,在构建WAR文件时,您不需要生产服务器上的Framework.

不正确,因为该play war命令实际上将整个框架捆绑在WAR中.所以你仍然拥有它,只是它包含在你的WAR中,而不是安装在服务器的某个地方.

此外,正如此处所讨论的,最佳部署策略是使用它的独立jetty配置.恕我直言,Tomcat应该用在最后的手段和/或只有在有正当理由的情况下才能使用.

编辑:引用的问题建议仅在该特定情况下使用独立Jetty(作为Tomcat的替代).如果它是您的选项,那么最佳部署策略与Play捆绑的HTTP服务器相同!(它基于Jboss Netty).为什么?它不使用Servlet API,因此它没有每个请求线程限制 - 这允许Play!使用异步IO(Play!continuations)做一些巧妙的技巧,请参阅此主题以获取详细信息.

注意:虽然Jetty/Tomcat也支持异步IO,但它们通过自己专有的API支持它 - 如果你打包Play!应用程序作为WAR,它没有利用这些API.所以,如果你打包你的应用程序是WAR准备看到许多线程闲置在服务器中.Async IO使用Servlet API 3.0和Play进行了标准化!2.0将利用这一点.同时,您最好的选择是坚持使用内置服务器.

  • 首先,servlet容器会加载很多Play不需要的组件,从而产生内存过载.其次,为了在服务器容器中部署游戏,你需要建立一个战争.在此期间,可能会发生转换错误(特别是如果依赖于模块,外部jar,libs).另一个冒险的风险.表现也是一个问题.servlet容器将执行另外的处理.一个轻量级的容器,比如内置的Jetty就足够了.原因很多,这是IMO最重要的原因. (3认同)

sve*_*iak 3

如果您不想构建 war 文件,那么您肯定需要在环境变量中进行 play,因为在生产服务器上运行它需要“play start MYAPP”(启动应用程序并将其放入后台进程)。如果没有框架本身,该应用程序无法独立运行。

我的意思是,我如何编译并生成一个可以分发给我的客户的包,该客户将执行诸如解压缩分发停车场并运行脚本来启动服务器之类的操作?

嗯,这正是 war 文件的用途。如果你想要自动部署,恕我直言,没有办法绕过战争文件。另一方面,在构建 war 文件时,您不需要生产服务器上的框架。您可以通过 play war 发起战争,并使用 maven tomcat 插件将其分发到您的生产服务器(如果它是 tomcat)。