庞大的 EAR 部署答案

【问题标题】：Huge EAR deployment庞大的 EAR 部署
【发布时间】：2009-10-14 16:11:17
【问题描述】：

我试图弄清楚如何通过相当慢的 VPN 连接将一个巨大的 (40-50 MB) EAR 文件部署到服务器。 EAR 包含在 Glassfish 中创建的 EJB 和 WAR 项目，文件大小的 90% 来自使用的外部依赖库。

有没有人想出一个从 Netbeans 优雅地部署到生产系统的策略，其中部署（通过网络）只针对真正需要的（即只有一个 WAR，而不是整个 EAR，或者只有一个库，而不是整个库子项目）。
关于第一点，如何在Netbeans中将外部依赖库从项目中分离出来，使项目在开发机上编译，但是在创建EAR/WAR/EJB时它不包含所有的依赖JAR ，这使它变得巨大。

也许我们需要编写自定义的 ant 脚本？开始使用maven？

谢谢大家的热心回答，

博佐

【问题讨论】：

错字：这些项目显然是在 Netbeans (6.7.1) 中创建的，但部署到 Glassfish。解决方案不需要在其他 IDE 中工作。
40-50 MB 不算大。并且您需要 EAR 中的依赖项，否则它将无法运行。看看另一种部署机制，比如 SSH。
如果您通过慢速网络连接部署它，它会很大，与它是 SSH 还是 IPSec VPN 无关。不，我认为我不需要 EAR 中的 deps，它们可以放置在 domain/lib 和 domain/app-lib 中，但后者虽然很好，但要求我实际上拥有包含所有 WAR/EJB 依赖链接的 excel 文件 - Glassfish 的性能不如 Weblogic 或 JBoss（没有共享库，作为部署选项）。

标签： jakarta-ee ear

【解决方案1】：

这就是为什么将依赖项移出 EAR 并移入共享目录是一个坏主意的原因：通过将所有依赖项保留在 EAR 中，应用程序服务器能够干净地取消部署/重新部署该 EAR 并回收它的空间在 JVM 堆中使用（对于 Sun JVM，permgen）。如果您将一些依赖项移动到共享库中，您将面临这些依赖项将维护对 EAR 中定义的某些对象的硬引用的风险。这意味着不能删除 EAR 类，最终您的应用服务器将在 permgen 空间用完后崩溃。

我对 SSH 的建议是基于“VPN”是指 Windows SMB 的假设，它在复制文件时有很多来回通信。使用 SSH（或更准确地说是 SCP 或 RSYNC），您可以使用连接的全部带宽。

如果这仍然太慢，您应该考虑更改您的基础架构。由于 VPN 对我来说意味着公司网络，也许您可以将构建机器设置在与部署机器相同的网段上。从流程的角度来看，无论如何这是一个更好的主意：您不应该从开发人员工作站部署构建。相反，您应该将源代码签出到干净的环境中，进行构建、运行测试，然后进行部署。

另一种方法是查看您的特定应用程序是否支持“爆炸耳朵”——如果是，那么您只需上传已更改的 JAR。

【讨论】：

您好，感谢您的回答。 Exploding EAR 似乎是最简单的解决方案。您是否可以提供一些指针或链接来探索您建议的构建过程。或类似的方案。老实说，自从业务扩展以来，我们只是建立了一个生产级构建流程。所以，实际上我正在寻找关于如何在没有太多额外基础设施的情况下部署软件新功能的想法，但有一个可靠的部署流程。再次感谢，博佐。

【解决方案2】：

一种合理的方法可能是在本地构建您的 EAR，然后使用 rsync 镜像文件，然后触发重新部署。由于如果底层 jar 不改变，EAR 文件的大部分部分都不会改变，因此您将从 rsync 算法中受益匪浅。

【讨论】：

好主意，我喜欢，谢谢。最后，我在“构建服务器”上创建了一个 ant 脚本，它从 SVN 中提取源代码，构建它们并将它们部署到本地应用程序服务器，因此文件大小不再是问题，但你的想法很好。

【解决方案3】：

为什么不将库 jar 复制到 /glassfish 安装目录/glassfish/domains/domain1/lib 并且不将它们打包到您的 ear 文件中？

【讨论】：