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
|