Nexus 私服无法下载远程 Jar 包问题排查指南

一、前言

前几天线上 ZooKeeper 出了一次不大不小的问题,由于缺少监控报警,导致事发第二天才引起我们的注意,所幸没有造成太大的影响。这起事情也督促我们尽快建立完备的监控体系,目前项目中使用 JavaMelody 监控应用状态,但是缺少实时报警。所以最近团队内部都在调研相关监控工具,初步选型 Sentry。

不过本篇跟 Sentry 其实没啥关系,主要是在调研过程中碰到 Nexus 私服无法下载远程 Jar 包的问题,这种情况在最早期系统重构时就有遇到,但后来又不知怎么滴就自己好了,时间关系也就没深究原因。既然这次又碰到了,那干脆就彻底解决掉。


二、问题起因

那天下午我在本地搭好 Spring Boot Admin Server 后,打算找个应用充当 Client 看下效果。Client 端需要依赖 spring-boot-admin-starter-client 包。

<dependency>
    <groupId>de.codecentric</groupId>
    <artifactId>spring-boot-admin-starter-client</artifactId>
    <version>2.0.4</version>
</dependency>

谁知这个依赖包死活下载不下来,打开公司的 Nexus 私服搜索这个包,发现是可以搜到的。
WX20200419-213520.png

现场未截图,上图为修复后的搜索结果


三、排查过程

① 由于公司 Nexus 私服中的中央仓库还是用的默认值http://repo1.maven.org/maven2/。所以第一时间更换为阿里云的http://maven.aliyun.com/nexus/content/groups/public/,重启之后发现还是下载不了。

② 对比了仓库组「Public Repositories」的「Browse Index」及「Browse Storage」,发现「Browse Storage」没有相应依赖包,但既然主界面搜索能搜到那就排除了仓库索引的问题,于是死马当活马医尝试执行了 Rebuild MetadataUpdate Index 操作后还是不行。
WX20200421-112347@2x.png

Public Repositories:这是个 Repository Group,它的作用是我们只需要在 setting.xml 文件中配置该 Repository Group 这一个地址就行了,它将自动从其所包含的 Repository 中下载构件。

③ 随后仓库列表里的 Repository Status 栏引起我的注意,发现包括中央仓库在内的三个远程仓库呈如下状态:
WX20200421-111920@2x.png
尝试右键 Allow Proxy 发现一会状态又变回 Auto Block 。

Nexus 有一个 Auto Block 特性。当客户端发送请求到 Nexus 拉取 Jar 包时,如果 Nexus 当前没有,就会到远程仓库上去找;但如果连不到远程仓库,就会造成客户端的大规模等待,因此 Nexus 设计了 Auto Block 特性,在连接不上远程仓库时会将仓库设置为 Auto Block 状态,不再去连接远程仓库,而是直接告诉客户端连接不上然后返回。当然此时 Nexus 内部还会有一个健康检查的机制定时去连接远程仓库,如果能连接上就将仓库状态自动设置为有效,否则延长重试的时间,直到 60 分钟重试一次。

知道上述原理后,只需要修改相应配置项即可。将选中仓库「Configuration」栏的「Auto Blocking Enabled」配置项改为 false,重新 Allow Proxy 发现状态正常了。
WX20200421-112147@2x.png
带着一丝期待再次下载依赖包,发现还是不行。
(╯‵□′)╯︵┻━┻

④ 理智告诉我要冷静,到这会我才想起来去看服务器上 Nexus 的日志,在 wrapper.log 文件中发现如下日志信息:
nexus_log.png
怎么会连不上阿里云远程仓库,明明浏览器访问能正常打开,但服务器却 ping 不通,黑人问号脸???
没办法,只能回到 Nexus 管理后台重新换了一个仓库地址,重启之后发现依赖包终于可以下载了。
✿✿ヽ(°▽°)ノ✿

⑤ 依赖包问题是解决了,但是连不上阿里云远程仓库让我很费解,最后发现原来是在服务器的 hosts 里配了「maven.aliyun.com」的 IP 映射,该 IP 应该是早前的解析地址,现在早已失效,所以删掉就好了。

59.110.144.164 maven.aliyun.com

四、总结

上述排查过程其实并不高效,没有第一时间找到根本原因。回到现在,可以总结出一套相对有效的排查步骤:

  • 首先关注服务器上 Nexus 的日志,一般情况下从日志就能看出到底是什么原因引起的
  • 其次检查本地 setting.xml 文件里的配置是否正常
  • 然后检查远程仓库的 Repository Status 是否正常,必要时将「Auto Blocking Enabled」配置项改为 false,中央仓库地址最好改为国内仓库地址
  • 再检查 Nexus 仓库组「Public Repositories」的 Ordered Group Repositories 是否配置正确,一般除了 Snapshots 的远程仓库在右侧之外,其余均在左侧
  • 如果搜索都搜不到,那就要检查仓库组索引是否正常,必要时右键执行 Rebuild Metadata 及 Update Index

五、其他

贴一份 setting.xml 文件的常规配置以供参考:

...省略其余部分...
<mirrors>
    <mirror>
        <id>nexus</id>
        <url>http://127.0.0.1:8080/nexus/content/groups/public/</url>
        <mirrorOf>*</mirrorOf>
    </mirror>
</mirrors>

<profiles>
    <profile>
        <id>nexus</id>
        <repositories>
            <repository>
                <id>central</id>
                <url>http://central</url>
                <releases>
                    <enabled>true</enabled>
                </releases>
                <snapshots>
                    <enabled>true</enabled>
                </snapshots>
            </repository>
        </repositories>
        <pluginRepositories>
            <pluginRepository>
                <id>central</id>
                <url>http://central</url>
                <releases>
                    <enabled>true</enabled>
                </releases>
                <snapshots>
                    <enabled>true</enabled>
                </snapshots>
            </pluginRepository>
        </pluginRepositories>
    </profile>
</profiles>

<activeProfiles>
    <activeProfile>nexus</activeProfile>
</activeProfiles>

http://127.0.0.1:8080/nexus/content/groups/public/ 替换为自身私服地址

该配置声明了一个 id 为 nexus 的镜像,镜像地址为私服,其中 mirrorOf 的值为星号,表示该镜像代理所有远程仓库,任何对于远程仓库的下载请求都会被转至私服。
另外还定义了一个 id 为 nexus 的 profile,这个 profile 包含了相关的仓库及插件仓库配置,同时配置中又使用 activeProfile 元素将 nexus 这个 profile 激活。需要说明的是仓库跟插件仓库配置它们的 id 都为 central,也就是说覆盖了中央仓库的配置,它们的 url 已无关紧要,因为所有请求都会通过镜像访问私服地址。

posted @ 2020-05-25 15:09  枫本非凡  阅读(6515)  评论(0编辑  收藏  举报