9

在花了几个小时试图了解如何在基于 OSGi 的应用程序的情况下进行持续部署之后,我终于在 stackoverflow 上提出了我的第一个问题,希望能找到一些迹象表明我可能做错了什么或错过了什么——不知何故感觉走错路了。。。

这就是我想要实现的目标:

  1. 构建一些包并将它们安装到 maven 存储库(这里没问题,使用 bnd)

  2. 现在有了构成我的应用程序的所有包(通过所有测试等),我想部署和运行应用程序,即使用这些包启动一些 OSGi 框架。

  3. 开始不是问题——“mvn pax:provision -Dframework=equinox”可以解决问题。我的应用程序启动了 jetty,因此很容易通过浏览器进行验证以查看一切是否正常(除了所有测试)

  4. 但是,现在,尝试“连续”,下次我想应用这个过程时,我真的应该确保首先关闭我的应用程序的运行实例(至少释放正在使用的端口)。所以,要重新运行一切,我必须先关闭旧的安装。

这就是我的问题开始的地方:有什么可以帮助我解决这个问题吗?我知道有maven-deploy-plugin,但这似乎只有在将一些 WAR/EAR 文件部署到一些标准应用程序容器中时才有用(似乎不需要重新启动它)。

我真的只需要运行一些脚本来启动OSGi 环境——然后,下一次,在我再次启动它之前优雅地关闭它。用tomcat、jetty、jboss之类的,有一些shutdown.sh脚本或者mvn jetty:stop指令,但是真的要自己写那种脚本吗?这就是我认为我开始走错路的地方,我猜肯定有人在我之前遇到过这些问题并解决了它们;)

我知道我可以以某种方式尝试使用JMX或使用telnet 控制台来访问正在运行的实例以发出“stop 0”命令,但这感觉不对

从詹金斯开始的进程应该编译/构建/部署项目,但我猜不是启动长时间运行的线程,所以我必须以某种方式启动一些“外部”进程,我想在下次再次尝试时首先杀死它。

有任何想法吗?也许我错过了什么?提前感谢您对此的任何意见!

4

4 回答 4

4

在我看来,telnet 方式似乎是最干净的。

但是,如果您想发挥创意,您​​可以创建一个简单的关闭包,然后在准备重新部署之前安装它。确保您已启用自动部署,以便在安装时激活捆绑包。当这个包激活时,它的工作是彻底关闭当前正在运行的 Equinox 容器。

我仍然建议使用 telnet 方法,因为您需要确保在尝试重新部署之前关闭容器。

如果您不喜欢这些方法中的任何一种,请查看Apache Karaf。您可以发送正在运行的容器命令。您甚至可以停止、卸载然后重新安装所有捆绑包,而无需停止 Karaf。

Karaf 可以在 Apache Felix 或 Eclipse Equinox 之上运行。

于 2012-06-02T20:14:38.870 回答
3

也许我遗漏了一些东西,但是当您想要重新部署/更新您的应用程序时,为什么要关闭整个 OSGi 框架?OSGi 的全部意义在于,您无需重新启动整个系统即可更新捆绑包(还记得“您必须重新启动 Windows 才能使更改生效”的东西吗?)。更重要的是,重新启动整个框架将隐藏任何关于在你的包的停止方法中释放资源的错误,所以我绝对建议只更新包进行测试(并在几个启动/停止周期后检查日志和资源消耗! )

如果我这样做,我将只启动一次完全独立于 maven 的 OSGi 框架,然后使用许多可能的方法之一来部署和更新其中的包,而无需重新启动框架。

例如: * 您可以配置系统,以便始终将更新版本的包放在磁盘上的给定位置,然后使用 OSGi 控制台/telnet/您选择调用的 OSGi 框架附带的任何管理工具“更新 ”。

  • 或者您可以使用一些可以连接到正在运行的框架实例并更新捆绑包的工具。例如对于 Eclipse,有一个来自 ProSyst 的插件可以做到这一点。

  • 或者你可以使用一些真正的远程管理软件,它可以帮助你同时在多个目标上测试远程部署,也可以直接监控部署状态。一种这样的系统是例如mPower Remote Manager

关于释放端口 - 如果你有这个问题,原因很可能是捆绑本身,重新启动 OSGi 框架不会解决它,因为在现实生活场景中,fw 不应该在更新时重新启动一个捆绑包。检查您是否在捆绑软件的 BundleActivator 的 stop() 方法中正确停止所有线程并释放所有资源。

于 2012-06-04T08:32:05.450 回答
2

在 bndtools 中,这一切都是自动化的……一旦你保存了一个源文件,它就会构建 jar 并告诉框架在哪些包是新包时要更新或安装。试试吧,大约 3 秒的惊人的短编辑-编译-构建-运行-调试周期。

于 2013-06-03T11:49:31.110 回答
2

在一些新的见解和检查了很多方法之后,我想记录下我发现最适合我自己关于持续部署基于 OSGi 的应用程序的初始问题的方法。

这里的主要问题是不能仅仅通过将它们放到某个目录中来更新正在运行的 OSGi 应用程序中的包(例如,可以使用 org.apache.felix.fileinstall 来完成),而是能够持续部署当前的来自 SCM 的软件状态 - 通过 jenkins 自动进行,就像第一次部署时的样子。

对我来说,解决方案非常简单,真的:有一个守护进程版本的 pax-runner,我可以按如下方式使用它:

在 jenkins 项目配置中,Post-steps,执行 shell 我放了类似的东西:

export BUILD_ID=dontKillMe
myproject/etc/scripts/postDeploy.sh &

postDeploy 脚本看起来像

#!/bin/bash

cd <myproject>/workspace/skysail.server.ext.osgimonitor/target
cp project.zip /somepath/pax-runner-1.8.5/

cd /somepath/pax-runner-1.8.5/

unzip project.zip

cd project
./rund.sh

最终的 rund.sh 脚本类似于

java $JAVA_OPTS -cp .:bin/pax-runner-1.8.5.jar org.ops4j.pax.runner.daemon.DaemonLauncher \
--startd --clean scan-composite:file:rund.composite \
--log=DEBUG

rund.composite 只是一个引用一些这样的配置文件的文件

scan-file:bundledefs/core.setup
scan-file:bundledefs/logging.setup
scan-file:bundledefs/restlet.setup

最后,作为这些文件的示例:

mvn:commons-lang/commons-lang/2.6
mvn:org.codehaus.jackson/jackson-core-lgpl/1.9.5
mvn:org.codehaus.jackson/jackson-mapper-lgpl/1.9.5
mvn:javax.xml.stream/com.springsource.javax.xml.stream/1.0.1
mvn:org.xmlpull/com.springsource.org.xmlpull/1.1.4.c
mvn:com.thoughtworks.xstream/com.springsource.com.thoughtworks.xstream/1.3.1
mvn:org.codehaus.jettison/com.springsource.org.codehaus.jettison/1.0.1
...

使用此设置,每当 jenkins 构建项目时,都会触发部署后脚本,并以干净的初始状态重新启动应用程序。

于 2013-01-13T19:39:01.913 回答