博客家

JBoss Repository Manager的案例研究

通过弗雷德西蒙

8分钟阅读

JBoss开发人员在使用新的构建基础设施时遇到的大多数问题都是公开讨论的在这里。这是关于Hudson、Maven和sontype - nexus集成遇到的问题的重要信息来源。

既然我们(JFrog)参与了Hudson、Maven和存储库管理器环境多年来，我们向JBoss提供了一些反馈。

最主要的是:我们不提倡或支持任何特定的构建技术，所以当Maven不适合时，我们不怕说出来。

本案例研究生动地揭示了Nexus和Artifactory!
以下是我要讨论的问题:

  1. modv或http(s)部署URL
  2. 在pom.xml中管理distributionManagement XML标记
  3. 使用密码进行Maven部署
  4. 超时和性能问题
  5. Maven元数据XML问题
  6. Maven部署失败
  7. 创建和验证校验和

1)修改dav或http部署URL

的部署超时问题richfaces，建议使用纯https而不是dav ： https作为url部署。

以下是关于Maven部署工具需要知道的所有注意事项:

  • 主要有3种种类使用的马车与Maven:轻量级http(目前的默认值)，重量级http(旧Maven版本的默认值)，Dav。
  • Dav在部署时使用事务，它在客户端有更好的内存管理，并且具有计算校验和的Bug。Dav是部署大文件时必须使用。现在，问题是dav是您可能会因为事务而超时，所以建议是正确的!
  • Maven中包含轻量级http，将整个字节数组缓存到内存中，因此无法用于大型部署。
  • Dav重量级协议的默认配置使每个部署的文件在网络上传输两次。这是由于标准HTTP协议总是尝试在没有身份验证的情况下发送请求，然后再发送请求。检查这找到配置的方法preeemptive在Maven简单http客户端中进行http身份验证。
  • Maven正在缓存凭证资料来源:URL。这意味着，如果对读查询进行身份验证，则使用相同的读凭据为部署!参见“配置身份验证”在这里。


基本上，看看上面的选项，标准Maven没有什么令人满意的。

为了解决这个问题，我们(JFrog)创建了一个构建客户端插件它使用Apache commons http客户端管理构件的部署，具有抢占式身份验证和优化的响应时间。说明:该客户端用于每天多次从多个Hudson服务器和代理部署4.5Gb的完整DVD映像到Artifactory…

2)管理distributionManagementXML标记

要正确管理上述所有参数，以及每个项目的确切存储库位置的已部署URL，您需要在pom.xml中配置distributionManagement标记。这产生了很多摩擦，使SVN标签的重建几乎不可能。

出于充分的理由，JBoss希望将存储库管理器拆分为多个服务器和本地存储库，这样每个项目将把它们的工件部署到专用的存储库中。

由于这个发行版是一个渐进的变化，所有以前的构建和SVN标签都是过时的，不能复制…

我们相信管理部署配置参数应该在Maven之外完成，这就是为什么我们有一个Artifactory-Hudson插件它就是这样做的。您的pom.xml中没有存储库管理器url，您可以在Maven之外的Hudson中调整部署参数(超时、http或https等)。顺便说一句:Artifactory-Hudson插件提供了更多的特性，比如Artifactory和Hudson之间的完全双向可追溯性，用于在每个Hudson作业执行期间生成和使用的所有工件。

3)使用密码部署Maven

像描述在这里在settings.xml中加密密码有点烦人，但它可以工作。现在，您需要知道它仍然强制您使用https，因为明文密码将在网络上传递。现在，储存库管理器密码的问题是，除了maven之外的所有自动化脚本都需要它们(Hudson，buildr(Ant, auto-backup, rsync，…)，因此您总是发现自己处于一个棘手的情况，请参阅这和那。

为了解决这个问题，我们实现了一个加密密码系统其工作原理如下:

  • Artifactory为每个用户生成一个非对称密钥对，
  • 在UI中输入你的明文密码，你会得到一个带有你个人加密密码的settings.xml块。
  • 上面加密的密码可以在任何地方使用(不仅仅是maven)，并且只允许REST API访问(maven部署等)，不允许UI访问。
  • 有了加密的密码，https来做maven部署不再是必须的了=>服务器上的负载少了很多。
  • 与JBoss Hudson服务器上使用的所有密码的完全明文解密相比，窃取加密密码或私钥(保存在Artifactory DB中)对安全性的影响最小。
  • 您可以强制在REST和maven部署时始终使用加密密码。

4)超时和性能问题


这个问题涉及到dav模式、JVM内存参数、操作系统打开文件句柄调优，还涉及到下一个关于maven-metadata.xml文件的问题。

根据我们的经验，最新的1.6 Sun JVM的一个问题是对年轻内存大小的错误计算。因此，在更新/升级服务器时，您应该验证-XX:NewSize和-XX:MaxNewSize至少设置为总堆大小的2/3。Artifactory(像Nexus一样)每个请求都需要大量的内存空间(管理文件)，因此JVM的年轻伊甸园空间是最重要的参数。只是要小心设置一个兆字节的好倍数，因为JVM在将内存块从年轻的根空间移动到旧的根空间时存在错误。

据我所知在这里，这就是我的建议:”-server -Xms1g -Xmx1g -XX:PermSize=128m -XX:MaxPermSize=128m -XX:NewSize=512m "

5) Maven元数据XML问题


这个问题解释起来有点棘手，我希望我能说清楚

对于每个SNAPSHOT版本的maven pom或jar文件，maven需要2个maven-metadata.xml文件。我将以富人问题为例:

部署:org/richfaces/用户界面/ modal-panel 3.3.4-SNAPSHOT / modal-panel-3.3.4-SNAPSHOT。砰的一声需要更新:

  • org/richfaces/用户界面/ modal-panel 3.3.4-SNAPSHOT / maven元数据。xml要更新此版本的时间戳和/或最新唯一版本号，
  • org/richfaces/用户界面/ modal-panel maven元数据。xml更新可用快照版本列表和最新创建的快照版本。


问题是maven客户端正在完成这项复杂的工作，并结合了maven元数据。XML文件被maven反复请求以构建其版本解析方案。

在这个例子中，对于的每个模块richfaces3.3.X-SNAPSHOT, maven部署jar(由于问题1而两次)砰的一声源，读取maven-metadata的先前值。然后将它们写下来(由于问题1，两次)dav和沉重的读在这些文件上，会出现超时。

计划的性能调优在这里将有助于解决这个问题，因为读取将被卸载到nginx。

请注意，由于上述设计，您将遇到一个更大的问题:maven元数据的反复损坏。xml文件!


像每个人一样，大多数JBoss项目在Hudson中都有上游和下游依赖项。例如:richfaces-jsf2取决于richfaces。所以，多个单独的SNAPSHOT是很常见的哈德逊工作(比如说)richfaces3.3.4-snapshot和richfaces-3.3.5-SNAPSHOT)将并行执行。从上面的maven设计中可以看到，maven元数据的计算。XML文件几乎肯定会失败。

为了解决这个问题，我们的部署系统(在哈德逊插件)知道Artifactory是一个智能存储库管理器，因此只发送砰的一声， jar和已验证的校验和发送给存储库管理器。Artifactory然后排队Maven元数据异步重新计算任务，从而避免并行冲突和超时。实现这一机制是远不明显，但我们今天有了积分测试部署5个不同的快照版本并发(并且重复)，没有任何问题

6) Maven部署失败

可以看到在这里例如，在尝试部署到Nexus的失败的Hudson工作中，您最终会部署一半的项目。意思是在成功建造572号之前richfaces，储存库中随机列出了好罐子和坏罐子砰的一声 为相同的项目/版本。建议仅在完整构建成功之前实际执行部署。

部署需要是Hudson的构建后操作(就像在我们的插件中完成的那样)。

7)创建和验证校验和

由于maven正在计算和部署校验和到JBoss Nexus实例，你有一般的问题，如:
  • 玩dav可能产生了很多你不知道的错误校验和;
  • 没有错误校验和验证部署因此，构建也将如此成功,但是用户将得到一个错误的校验和错误;
  • 自相关的之间的哈德逊maven的校验和不能信任你会失去可追溯性在哈德逊和Nexus之间

说明:Artifactory能够失败部署，如果校验和不匹配，有许多校验和政策配置。


为了JBoss开发者和用户的利益，我希望Red Hat能够解决他们的构建基础设施问题

受欢迎的标签

试试JFrog平台

在云中或自托管

开始试验

orgydF4y2Ba预订演示