maven私服nexus2-14-5迁移到nexus3-7-1
# 注意前置
注意,本文讲解的是针对我们原来所用的 nexus2.14.5 版本的升级配置流程,如果您的老私服版本并不是这个,那么请先参考这里:升级兼容性 – Repository Manager 2 到 3 (opens new window)。选定对应可升级版本之后,再阅读本文获取经验。
另外,虽然本文介绍了两种可行的方案,但是,我仍旧推荐使用 HTTP 下载的方式进行升级,至于原因是什么,请往下看就知道了。
那么书接上回。
可能大家还记得上篇最后发生了什么,就是com.third:google.guava:jar:14.0.1
这个包下载失败,从而导致项目编译终止。我们也都知道,解决的办法就是手动下载对应的包,然后传到私服上去即可。
但是,总觉得很麻烦,因为在公司几年的项目积累下,可能会有不止 1 个,十个,甚至百个这样下载不下来的包。为了针对这个问题,我想过如下几个办法:
# 1,两种失败的尝试。
# 1,给服务配代理。
这种思路大概就是你不能下载某些包,无非就是这资源需要翻墙,那就让服务能上外网呗。
[root@nexus local]$curl cip.cc
IP : 47.91.208.248
地址 : 中国 香港 阿里云
运营商 : 22.396428
数据二 : 香港 | 阿里云
数据三 : 中国香港香港 | 阿里云
URL : http://www.cip.cc/47.91.208.248
2
3
4
5
6
7
8
9
10
然后编译测试拉取,发现仍旧不行。
# 2,直接迁移。
网上有不少方案是讲直接更改 nexus 里边的配置,然后让新服加载老的数据的,但这种不优雅的方式,经过我的测试之后,发现可行性并不是很大,尤其是在 nexus2.x 到 3.x 之间的升级之上。故而不推荐这种方式。
# 2,成功方式 1–代理旧私服。
提示
这个思路应该是最妙的。我想,既然我们可以添加一个远程的 proxy,为什么不能把老的私服作为一个远程 proxy 呢,虽然这种方案需要新老两个私服同时运作,但作为一种新老交接的情况,似乎也可以容忍。
说干就干,我又添加了一个 proxy,将其中的地址定义为老私服的地址,配置如下:
Proxy
:改成老私服地址。Authentication
:添加用户名密码。
这里配置完并保存之后,我们再去到 group 里边添加上:
这里上下有一个优先级,所以我们给它调整为第一位:
保存之后,回到项目中再次构建:
惊然发现,项目就此顺畅的构建成功了。去到私服里边看看:
看到了,是他,老泪纵横的,看到了这种奇妙的思路也成功了。
提示
不过,这种方法的问题在于,我这里只测试了一个项目的构建,也就是仅仅将此项目对应的依赖从老项目当中拉了过来,如果此时还只能让两个私服共存,但你不知道什么时候才真正的完全拉完,因此有点尴尬。
# 3,成功方式 2–HTTP 下载。
于是,这就引出了今天的第四种方案,那就是 nexus 内置的一种迁移方式:HTTP 下载 (opens new window)。也就是,只需要对着 nexus 点点点,即可实现一劳永逸的搬迁,这个方案,着实令人欣喜。
接下来,不废话,直接进入正题。
# 1,老私服配置 Upgrade:Agent。
如果想实现迁移,首先要配置 Upgrade:Agent ,这个配置比较简单,直接通过截图来展示:
- 1,点击 Capabilities。
- 2,New 一个新的。
- 3,选择 Upgrade: Agent。
- 4,创建一个 Access Token,用于远程连接。这里设为 123456。
创建之后查看一下:
# 2,新私服配置连接。
新服安装以及登陆,这且按下不表,可以参考前边的文章,这里直接进入配置环节。
1,点击 Capabilities,New 一个新的。
2,选择 Upgrade。
3,创建。
4,配置链接开始升级。
5,配置老私服地址。
将老私服地址填入,并将刚刚定义的 token 写入。
就在当我以为一切都是这么愉快欢乐得的时候,问题来了:
说升级时,与版本关系紧密。还给了个建议,说2.14.8
版本的好像更容易升级。
ok,既此开始,我陷入了无尽的版本深渊当中,也正是自此开始,我开始关注升级过程中,版本的重要性。
首先我们老私服的版本是2.14.5
,这个版本说实话在 2.x 界是并不低的,而我现在所用的新私服版本是3.12.1
的,于是我首先尝试安装了3.1.0
的进行升级,发现仍旧会有这样那样的报错。
直到,我在官方文档当中碰到了这么一篇文章:升级兼容性 – Repository Manager 2 到 3 (opens new window)。
就是遇到了这篇救命文章之后,这所有的问题,都不是问题了。
在文档当中有这样一个表格:
从表格当中,我看到了与公司老私服对应版本2.14.5
可升级的3.7.1
,也看到了如果想直接跳到 3.12.1,则需要先将 2.14.5 升级为 2.14.8,然后才能从 2.14.8 升级到 3.12.1。
反正都是个升级,我最终选择了,在另一台测试机器上安装一个 3.7.1 版本的私服作为临时中转。
于是,安装,登陆,配置,说话间,就来到最关进的认证阶段:
此时此刻,看到绿色的 success,不得不说,我眼含泪水,终于等到你。
剩下的就好办了,一路 next 即可。
不过这里稍微可以配置一下。
Destination
:选择我们创建的 blob:maven-use。Method
:这里边有三种类型,Hard link(文件系统硬链接),Filesystem copy(文件系统复制),Download(HTTP 下载)。
此三种类型区别,可以参考官网介绍:数据传输方法。 (opens new window)
此处我们选择默认的,就是我们用的 HTTP 下载的方式。
识别到了老私服里边的仓库,这里直接全选,吼吼。
万事已毕,只等一声令下:Begin。
历史瞬间,剪影留念。
接着,就可以看到迁移前的体检阶段:
检测已经结束,一共有 59622 项内容,点击继续即可同步。
看到这个界面,就是成功了:
当同步完成,我们可以在 public 里边看到这些从老私服同步过来的包。
然后把这个 public 加入到我们创建的 group 里边:
然后再将上回书中的项目进行构建,此时发现:
已经可以构建成功了,说明我们做的迁移工作,是生效了的。
当我看到成功的界面是,我止不住激动心情,去找到同事分享这种成就感以及喜悦!
# 4,两种成功的方式之总结。
上边列举了两种成功的方式,这两种方式的差别还是非常大的,我们来通过一个小小的数据来对比一下:
看了两个sonatype-work
大小的对比,就能清晰了解到,在前边我们所担忧的问题,果不其然的在这里出现了,一个8G
多,一个800多M
,这两者之间的差距,恐怕就是我们需要让新老私服共存的时间差吧,于是乎,最终,我最推荐的方式还是HTTP下载的方式。
如果你想要使用最新版本的私服,那么可以先通过 HTTP 下载的方式从 2.x 升级到 3.x,然后再直接将对应的sonatype-work
复制到最新版本的私服当中,直接启动即可。
# 5,研究感言。
这是一个没有老师的自学,网上或多或少也有不少教程,有一些教程是帮助你的,有一些教程是坑害你的,这与教程本身无关,而与你遇上这些教程的缘分以及个人的悟性有关,总而言之,只有认真学习,勤思多练,才能在荒漠当中,走踏处一条明路。
# 6,参考链接。
- 1,https://help.sonatype.com/repomanager3/upgrading/data-transfer-methods#DataTransferMethods-HTTPDownloading
- 2,https://help.sonatype.com/repomanager3/upgrade-compatibility—repository-manager-2-to-3 (opens new window)
- 3,https://www.ilanni.com/?p=12366
![微信](https://t.eryajf.net/imgs/2023/01/834f12107ebc432a.png)
![支付宝](https://t.eryajf.net/imgs/2023/01/fc21022aadd292ca.png)
- 01
- 学习周刊-总第175期-2024年第36周09-05
- 02
- 魔方复原-记录个人理解的教程09-01