部署大型Java Web应用程序(> 100 MB .war)时,当前正在使用以下部署过程:
关于这种方法的好处:
这种方法的坏事:
我想找到一个具有以下属性的部署过程:
题:
已经注意到,将更改推送到WAR文件时,rsync不能很好地工作。原因是WAR文件本质上是ZIP文件,并且默认情况下是使用压缩成员文件创建的。对成员文件的较小更改(在压缩之前)会导致ZIP文件的比例差异很大,从而使rsync的增量传输算法无效。
一种可能的解决方案是用于jar -0 ...创建原始WAR文件。该-0选项告诉jar命令在创建WAR文件时不要压缩成员文件。然后,当rsync比较旧版本和新版本的WAR文件时,增量传输算法应能够创建较小的差异。然后安排rsync以压缩形式发送差异(或原始文件);例如rsync -z ...在下面使用或压缩数据流/传输。
jar -0 ...
-0
jar
rsync
rsync -z ...
编辑:根据WAR文件的结构,可能还需要使用它jar -0 ...来创建组件JAR文件。这适用于经常更改(或简单地重建)的JAR文件,而不适用于稳定的第三方JAR文件。
从理论上讲,此过程应比发送常规WAR文件有显着改进。实际上,我没有尝试过,所以我不能保证它会起作用。
缺点是部署的WAR文件将大大变大。这可能会导致更长的webapp启动时间,尽管我怀疑这种影响是微不足道的。
完全不同的方法是查看您的WAR文件,看是否可以识别可能(几乎)永不更改的库JAR。从WAR文件中取出这些JAR,然后将它们分别部署到Tomcat服务器的common/lib目录中。例如使用rsync。
common/lib