1. 项目概述
作为一名在DevOps领域摸爬滚打多年的老兵，我深知制品库在持续交付流水线中的重要性。最近在帮客户做技术栈国产化迁移时，发现了一款名为Hadess的开源制品管理工具，经过实测发现它完全能够替代Nexus作为企业级制品库。今天我就来分享如何将现有Nexus中的制品平滑迁移到Hadess，这个过程中踩过的坑和总结的经验都会毫无保留地告诉大家。
Hadess作为国产开源制品库，支持Maven、npm、Go、Docker等主流制品类型，界面简洁但功能完善。最让我惊喜的是它的迁移工具做得非常人性化，特别是对Nexus的兼容性处理得很到位。下面我会从环境准备、安装配置到实际迁移，手把手带你完成整个流程。
2. 环境准备与工具安装
2.1 Nexus环境检查
在开始迁移前，我们需要确保源Nexus服务正常运行。这里以Nexus 3.x版本为例：
bash复制# 检查Nexus服务状态（假设使用默认8081端口）
netstat -tlnp | grep 8081
# 如果使用systemd管理
systemctl status nexus
注意：如果Nexus部署在容器中，需要确保网络可达。我遇到过因为防火墙规则导致迁移失败的情况，建议先用curl测试接口连通性：
bash复制curl -I http://nexus-server:8081/service/rest/v1/repositories
2.2 Hadess安装部署
Hadess提供多种安装方式，我这里选择RPM包安装（CentOS 7+环境）：
- 下载最新安装包（当前稳定版为2.3.0）：
bash复制wget https://download.tiklab.net/hadess/tiklab-hadess-2.3.0.rpm
- 安装前依赖检查：
bash复制# 检查Java环境（需要JDK11+）
java -version
# 检查磁盘空间（建议至少50GB可用）
df -h /opt
- 执行安装：
bash复制sudo rpm -ivh --nodeps tiklab-hadess-2.3.0.rpm
- 启动服务：
bash复制cd /opt/tiklab-hadess/bin
./hadess start
启动成功后访问 http://server-ip:9700 ，初始账号admin/123456。第一次登录务必修改密码！
3. 迁移配置详解
3.1 Nexus连接配置
在Hadess中配置Nexus源时，有几个关键点需要注意：
- 进入"系统设置 > 服务集成"，点击"添加Nexus服务"
- 填写连接信息时：
- 地址格式：
http://<nexus_ip>:<port> - 账号需要具有admin权限
- 如果Nexus启用了HTTPS，需要提前导入证书
- 地址格式：
踩坑记录：曾经遇到因为Nexus启用匿名访问导致认证失败的情况，解决方案是在Nexus的Security > Anonymous Access中临时关闭匿名访问。
3.2 制品库映射策略
Hadess目前支持Maven制品的全量迁移，建议采用以下策略：
| Nexus仓库类型 | Hadess对应仓库 | 迁移建议 |
|---|---|---|
| hosted | local | 全量迁移 |
| proxy | remote | 重建配置 |
| group | group | 按需重建 |
对于大型仓库，建议分批迁移。我曾处理过一个包含10万+制品的仓库，采用以下命令查看制品数量：
bash复制# Nexus API查询制品数量
curl -u admin:password -X GET "http://nexus:8081/service/rest/v1/components?repository=your-repo" | jq '.items | length'
4. 迁移实操步骤
4.1 Maven制品迁移
-
在Hadess创建目标仓库：
- 类型选择"Maven"
- 部署策略建议"Allow Redeploy"（便于迁移失败重试）
- 存储配额根据实际需求设置
-
进入仓库设置 > 制品导入 > Nexus导入：
- 选择配置好的Nexus服务
- 勾选需要迁移的源仓库
- 设置并发数（大型仓库建议5-10）
-
开始迁移后，可以通过日志观察进度：
bash复制tail -f /opt/tiklab-hadess/logs/import.log
4.2 迁移后验证
迁移完成后务必进行完整性检查：
- 数量核对：
bash复制# Hadess API查询制品数量
curl -u admin:yourpassword -X GET "http://hadess:9700/api/v1/maven/repos/your-repo/artifacts/count"
-
关键制品校验：
- 选择具有依赖关系的典型制品
- 通过mvn命令测试下载
bash复制
mvn dependency:get -Dartifact=groupId:artifactId:version -DremoteRepositories=hadess-repo -
元数据检查：
- 对比Nexus和Hadess中的pom文件
- 检查签名文件(.sha1, .md5)是否完整
5. 常见问题与解决方案
5.1 迁移失败处理
问题现象：迁移过程中断，日志显示超时
解决方案：
- 调整Hadess JVM参数（/opt/tiklab-hadess/conf/hadess.conf）：
code复制JAVA_OPTS="-Xms4g -Xmx8g -XX:MaxMetaspaceSize=1g"
- 降低并发数（建议改为3）
- 对大型仓库采用分批迁移策略
5.2 依赖解析异常
问题现象：迁移后构建时提示依赖找不到
排查步骤：
- 检查Hadess仓库的"包含元数据"选项是否开启
- 对比Nexus和Hadess中的_remote.repositories文件
- 检查group仓库的成员顺序
根本原因：通常是元数据文件未正确迁移导致，可以通过重建元数据解决：
bash复制curl -u admin:password -X POST "http://hadess:9700/api/v1/maven/repos/your-repo/rebuild-index"
5.3 性能优化建议
经过多个项目实践，总结出这些优化点：
-
存储配置：
- 使用SSD存储
- 单独挂载大容量分区到/opt/tiklab-hadess/data
-
服务参数：
- 调整Nginx超时时间（如果有反向代理）
- 增加Hadess的HTTP线程数
-
迁移策略：
- 非业务高峰期执行迁移
- 对TB级仓库采用增量迁移方案
6. 迁移后维护建议
完成迁移只是第一步，后续维护同样重要：
-
监控设置：
- 配置制品库的磁盘告警（建议80%阈值）
- 监控API响应时间
-
定期维护：
bash复制# 清理过期快照 curl -u admin:password -X POST "http://hadess:9700/api/v1/maven/repos/snapshots/cleanup?days=30" # 重建索引（每月一次） curl -u admin:password -X POST "http://hadess:9700/api/v1/maven/repos/your-repo/rebuild-index" -
备份策略：
- 使用Hadess的导出功能定期备份关键仓库
- 备份配置文件（/opt/tiklab-hadess/conf/）
从Nexus迁移到Hadess后，我们的CI/CD流水线运行更加稳定了，特别是国内团队访问速度提升明显。对于还在使用Nexus OSS版的朋友，不妨试试这款国产工具，它在中文文档和社区支持方面确实更有优势。如果在迁移过程中遇到任何问题，可以参考Hadess的GitHub Wiki或加入他们的技术交流群。