在 jenkins 上持续部署基于 OSGi 的应用程序答案

【问题标题】：Continuous deployment of OSGi-based application on jenkins在 jenkins 上持续部署基于 OSGi 的应用程序
【发布时间】：2012-06-07 14:15:34
【问题描述】：

在花了几个小时试图了解如何使 持续部署 在 基于 OSGi 的应用程序 的情况下工作之后，我终于提出了我的第一个问题stackoverflow，希望对我可能做错或错过的事情有一些迹象 - 不知何故我觉得自己走错了路......

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

构建一些包并将它们安装到 maven 存储库（这里没问题，使用 bnd）
现在有了构成我的应用程序的所有包（通过所有测试等），我想部署并运行应用程序，即使用这些包启动一些 OSGi 框架.
开始不是问题 - “mvn pax:provision -Dframework=equinox” 可以解决问题。我的应用程序启动了 jetty，因此很容易通过浏览器进行验证以查看一切是否正常（除了所有测试）
但是，现在，尝试“连续”，下次我想应用此过程时，我真的应该确保关闭正在运行的实例 首先是我的应用程序（至少释放正在使用的端口）。所以，要重新运行一切，我必须先关闭旧的安装。

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

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

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

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

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

【问题讨论】：

标签： jenkins osgi continuous-deployment bnd pax-runner

【解决方案1】：

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

【讨论】：

【解决方案2】：

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

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

对我来说解决方案非常简单，真的：有一个 pax-runner 的 daemon version，我可以按如下方式使用它：

在 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 构建时，都会触发部署后脚本，并以干净的初始状态重新启动应用程序。

【讨论】：

【解决方案3】：

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

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

例如： *您可以配置系统，以便始终将更新版本的捆绑包放在磁盘上的给定位置，然后使用 OSGi 控制台/远程登录/任何您选择称为“更新”的 OSGi 框架附带的管理工具.

或者您可以使用一些工具来连接到正在运行的框架实例并更新捆绑包。例如，对于 Eclipse，有一个 plugin from ProSyst 正是这样做的。
或者你可以使用一些真正的远程管理软件，它可以帮助你同时在多个目标上测试远程部署，也可以直接监控部署状态。一个这样的系统是例如mPower Remote Manager

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

【讨论】：

感谢您提出的好问题、您的想法和链接（我会尽快检查）...但我仍然想知道在运行的 OSGi 固件上重新部署是否会给我与之前完全相同的结果一个干净的固件启动...）可能，为了安全起见，我应该同时做两个，启动一个干净的安装和重新部署。与在某些容器上更新 WAR 文件相比，我想，在 OSGi 的所有动态下，fw 的当前状态对新包的行为有更大的影响——也许我弄错了？而且，当然，最好的解决方案只依赖于纯 OSGi，没有额外的软件。

【解决方案4】：

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

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

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

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

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

【讨论】：

感谢您的提示，我猜 Karaf 正是我想要的。似乎是为 OSGi 捆绑包设置持续集成的完美工具，我会试一试。