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

一、前言

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

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


二、问题起因

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

1
2
3
4
5
<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 应该是早前的解析地址,现在早已失效,所以删掉就好了。

1
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 文件的常规配置以供参考:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
...省略其余部分...
<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 已无关紧要,因为所有请求都会通过镜像访问私服地址。