您如何远程更新Java应用程序？ [英] How do you remotely update Java applications?
问题描述
我们有一个Java服务器应用程序，它运行在许多计算机上，所有计算机都连接到Internet，有些则位于防火墙之后。我们需要从中心站点远程更新JAR文件和启动脚本，而不会对应用程序本身造成明显的中断。
We've got a Java server application that runs on a number of computers, all connected to the Internet, some behind firewalls. We need to remotely update the JAR files and startup scripts from a central site, with no noticeable interruption to the app itself.
该过程必须无人值守且万无一失（即由于不合时宜的互联网中断，我们无法承受破坏应用程序。）
The process has to be unattended and foolproof (i.e. we can't afford to break the app due to untimely internet outages).
过去我们使用各种外部脚本和实用程序来处理类似的任务，但由于它们有自己的依赖关系，因此结果难以维护且便于携带。在制作新内容之前，我想从社区获得一些意见。
In the past we've used a variety of external scripts and utilities to handle similar tasks, but because they have their own dependencies, the result is harder to maintain and less portable. Before making something new, I want to get some input from the community.
有没有人为此找到了一个好的解决方案？有什么想法或建议吗？
Has anyone found a good solution for this already? Got any ideas or suggestions?
只是为了澄清：这个应用程序是服务器，但不适用于Web应用程序（此处没有webapp容器或WAR文件）。它只是一个自治的Java程序。
推荐答案
你没有指定服务器应用程序的类型 - 我是假设您没有运行Web应用程序（因为部署WAR已经完成了您正在谈论的内容，并且您很少需要Web应用程序来执行拉式更新。如果您正在讨论Web应用程序，请参阅以下讨论仍然可以应用 - 你只需要为WAR文件而不是单个文件实现更新检查和乒乓。）
You didn't specify the type of server apps - I'm going to assume that you aren't running web apps (as deploying a WAR already does what you are talking about, and you very rarely need a web app to do pull type updates. If you are talking about a web app, the following discussion can still apply - you'll just implement the update check and ping-pong for the WAR file instead of individual files).
你可能想看看jnlp - WebStart基于此（这是一种客户端应用程序部署技术），但我非常确定它可以针对服务器类型的应用程序执行更新。无论如何，jnlp在提供可用于下载所需JAR所需版本的描述符方面表现相当不错......
You may want to take a look at jnlp - WebStart is based on this (this is a client application deployment technology), but I'm pretty sure that it could be tailored to performing updates for a server type app. Regardless, jnlp does a pretty good job of providing descriptors that can be used for downloading required versions of required JARs...
对此有一些一般性的想法（我们有几个应用程序）在同一个存储桶中，正在考虑自动更新机制）：
Some general thoughts on this (we have several apps in the same bucket, and are considering an auto-update mechanism):
-
考虑使用能够运行的bootstrap.jar文件在启动应用程序之前读取jnlp文件并下载所需/更新的jar文件。
Consider having a bootstrap.jar file that is capable of reading a jnlp file and downloading required/updated jars prior to launching the application.
JAR文件可以即使在应用程序正在运行（至少在Windows上，这是最有可能对运行文件进行锁定的操作系统）。如果您使用自定义类加载器，或者您有一堆可能随时加载或卸载的JAR，您可能遇到问题，但如果您创建机制来防止这种情况，那么覆盖JAR然后重新启动应用程序应该是足以进行更新。
JAR files can be updated even while an app is running (at least on Windows, and that is the OS most likely to hold locks on running files). You can run into problems if you are using custom class loaders, or you have a bunch of JARs that might be loaded or unloaded at any time, but if you create mechanisms to prevent this, then overwriting JARs then re-launching the app should be sufficient for update.
即使可以覆盖JAR，您也可以考虑使用ping路径的ping-pong方法（如果你不喜欢）已经将你的应用程序启动器配置为自动读取lib文件夹中的所有jar文件并自动将它们添加到类路径中，然后这就是你真正想做的事情）。以下是乒乓球的工作原理：
Even though it is possible to overwrite JARs, you might want to consider a ping-pong approach for your lib path (if you don't already have your app launcher configured to auto-read all jar files in the lib folder and add them to the class path automatically, then that's something you really do want to do). Here's how ping-pong works:
应用程序启动并查看lib-ping \ version.properties和lib- pong\version.properties并确定哪个更新。假设lib-ping有更高版本。启动程序搜索lib-ping * .jar并在启动期间将这些文件添加到CP。当你进行更新时，你可以将jar文件下载到lib-pong中（或者如果你想节省带宽而从lib-ping复制jar文件，而JAR实际上没有改变 - 尽管这很费劲！）。将所有JAR复制到lib-pong后，最后要做的就是创建version.properties文件（这样可以检测并清除导致部分lib文件夹的中断更新）。最后，你重新启动应用程序，并且bootstrap选择了lib-pong是所需的类路径。
App launches and looks at lib-ping\version.properties and lib-pong\version.properties and determines which is newer. Let's say that lib-ping has a later version. The launcher searches for lib-ping*.jar and adds those files to the CP during the launch. When you do an update, you download jar files into lib-pong (or copy jar files from lib-ping if you want to save bandwidth and the JAR didn't actually change - this is rarely worth the effort, though!). Once you have all JARs copied into lib-pong, the very last thing you do is create the version.properties file (that way an interrupted update that results in a partial lib folder can be detected and purged). Finally, you re-launch the app, and bootstrap picks up that lib-pong is the desired classpath.
-
乒乓球如上所述允许回滚。如果你正确地设计它，你可以拥有一个你测试的应用程序，然后永远不会更改检查，看它是否应该回滚给定的版本。这样，如果您搞砸并部署破坏应用程序的内容，则可以使版本无效。应用程序的这一部分只需要从坏的lib- *文件夹中删除version.properties文件，然后重新启动。保持这部分很简单是很重要的，因为这是你的安全故障。
ping-pong as described above allows for a roll-back. If you design it properly, you can have one piece of your app that you test the heck out of and then never change that checks to see if it should roll-back a given version. That way if you do mess up and deploy something that breaks the app, you can invalidate the version. This part of the application just has to delete the version.properties file from the bad lib-* folder, then re-launch. It's important to keep this part dirt simple because it's your fail safe.
你可以有两个以上的文件夹（而不是ping / pong，只有lib- yyyymmdd并清除除了最新的5之外的所有内容，例如）。这允许更高级（但更复杂！）回滚JAR。
You can have more than 2 folders (instead of ping/pong, just have lib-yyyymmdd and purge all but the newest 5, for example). This allows for more advanced (but more complicated!) rollback of JARs.
这篇关于您如何远程更新Java应用程序？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
