简介nexus-3.24.0-02-unix.tar.gz 是 Sonatype Nexus Repository Manager 3.24.0-02 针对 Unix/Linux 的官方安装包。作为广泛使用的软件仓库管理器Nexus 能够统一存放、代理与分发 Maven、NPM、NuGet 等多种格式的制品解决团队依赖来源分散、内网访问公共仓库缓慢等问题尤其适合同时使用 Java 与前端构建工具的中大型项目。压缩包约 149.69MB解压后得到 nexus-3.24.0-02 程序目录和 sonatype-work 独立工作目录运行文件与数据分离便于备份、迁移及版本升级其中 sonatype-work 存放制品、索引、日志与数据库内容理解该目录结构对后续运维排错很有帮助。当前已有 212 人学习下载适合刚接触私服搭建的开发者也适合希望规范依赖来源、降低公网带宽消耗的运维与构建负责人。该版本本身比较稳定支持代理 Maven 中央仓库与 npmjs 等公共源可将常用组件缓存到内网显著提升构建速度。部署后可通过 Web 界面或核心配置文件灵活调整端口、存储路径、仓库组与权限矩阵并能将 Nexus 设为团队 NPM 默认注册表实现私有包托管与版本统一管理配合 CI/CD 使用时可复用既有仓库配置减少外网依赖的同时增强制品供应链的可控性与安全性。1. nexus-3.24.0-02-unix.tar.gz这个 2020 年的私服包今天还在大批生产环境里跑着手上这份 nexus-3.24.0-02-unix.tar.gz是 Sonatype Nexus Repository Manager 3 在 2020 年放出的 3.24.0 补丁版 Unix 安装包。它不是新版本却是无数内网私服的起点一个 Java 进程同时管 Maven、npm、pypi、raw 多格式仓库离线环境拷过去就能跑。适合正在搭私有制品库的研发和运维也适合接手一台不知道装了什么版本的旧私服、想先搞懂它的人。反直觉的是3.24 早就过了官方维护期但生产环境里的存量依然很大——相当多机器的 JDK 还是 8升级又怕数据迁移出事于是一留就是好几年。理解它等于理解市面上很大一批私服的运行方式。2. 拆包前的三个决定JDK 8、内存边界和仓库格式怎么定2.1 Nexus 是什么3.24 在私服产品线里的坐标先回答最常被问到的问题——nexus 是什么。Nexus Repository Manager 3简称 NXRM3是一个集中式制品库对外它给构建工具提供一个统一地址去下载依赖对内它保存团队自己发布的构建产物还能按格式做权限隔离和保留策略。3.24.0-02 是 3.x 中期的补丁版处于“功能已经很全、JDK 要求还很友好”的窗口期它原生支持 JDK 8再往后的 3.30 开始转向 JDK 11很多老内网机器根本不想动 JDK这就是 3.24 到现在还被人点名要找安装包的原因。和 Nexus 2 相比3.x 把 UI 和 REST API 统一了引进了 blob store存储池的概念仓库创建、备份、迁移都围绕 blob store 展开。和 Artifactory 比它的优势是单个进程覆盖格式多Maven、npm、pypi、docker、raw 都原生支持社区资料也好找劣势是某些企业级权限模型要在 OSS 之外才完整。至于 nexus 替代的问题如果只代理 Maven轻量方案确实有一堆但要做到“一个入口、多格式、有缓存有权限”NXRM 这类产品仍然是最省事的路径。顺便说一句3.24.0-02 和 3.24.0 是同系列的关系02 是补丁包修掉了一批安全告警和配置缺陷同系列内升级成本最低这也是我推荐直接拿 02 的原因。2.2 环境参数表JDK、堆内存、数据盘和运行用户动手解压前先确认 4 个参数否则后面一定会回来补课。参数本机建议为什么JDKOpenJDK 88u2123.24 官方支持 JDK 8不要拿 11 硬跑堆内存默认 2703m小机器改 1024m改 etc/nexus.vmoptions 里的 -Xms/-Xmx数据盘/data 独立挂载预留 2 倍空间sonatype-work 里是 OrientDB 和 blob日志也在这运行用户新建 nexus 专用用户禁止 root 运行这是硬性限制确认环境一般是这几条命令java -version df -h /data nproc第一条看 JDK 是不是 8第二条确认数据盘有空间别让同事把私服装在系统盘一个 docker 镜像仓库把 inode 吃光整台机器跟着卡第三条看核数2C 的小机器建议把堆压到 1024m4C 以上再考虑用默认值。常见误用是把 Nexus 当普通 web 服务随便拿个 JDK 跑——3.24 用 JDK 11 大概率在启动日志里看到类加载错误避坑章会细说。仓库格式怎么定是拆包前最该想清楚的事。我的做法是列一张仓库规划表先数团队现在用哪几种格式Maven 基本绕不开npm 有就建pypi 有就建docker 走私有镜像就单独拆一个 blob store。每种格式最少三件套一个 proxy 拉外网一个 hosted 存内网产物一个 group 对外统一地址。别一上来就建几十个仓库后面权限和清理会变成负担。网络规划上我一般让 Nginx 做 TLS 终结Nexus 自己只监听内网 8081证书管理放在反代层省掉 Nexus 侧维护 HTTPS 的麻烦进程托管没有官方 systemd 单元常见做法是 bin/nexus 脚本配合自写 unit或者干脆用 crontab 监控进程够用就行。3. 解压到启动用最小命令把 Nexus 跑在 Unix 上3.1 解压与目录结构程序目录和数据目录要分清不管是从官网下载还是内网离线同步拿到的 nexus-3.24.0-02-unix.tar.gz解压后都会出现两个东西nexus-3.24.0-02 程序目录里面 etc/nexus.vmoptions 和 etc/nexus.properties 是唯二需要手改的配置文件另一个 sonatype-work 是数据目录第一次启动后会在里面生成 nexus3 子目录存放 OrientDB 数据库db/、blob 仓库、日志 log/ 和初始密码 admin.password。最常见的翻车是把数据目录留在程序目录里升级时整个目录被覆盖才知道后悔。我习惯把 sonatype-work 挪到独立数据盘再用软链接指回来这样升级只需要替换程序目录数据目录永远不动。cd /opt tar -zxvf /data/packages/nexus-3.24.0-02-unix.tar.gz mv nexus-3.24.0-02 /opt/nexus mv /opt/nexus/sonatype-work /data/nexus-work ln -s /data/nexus-work /opt/nexus/sonatype-work useradd -r -m -d /home/nexus -s /bin/bash nexus chown -R nexus:nexus /opt/nexus /data/nexus-work逐行说解压到包所在位置把程序目录固定成 /opt/nexus以后升级就是换这个软链接目标把数据目录整体搬到 /data再用 ln -s 让程序依旧从原路径找到它新建系统用户 nexus 用来跑进程最后把两处属主都改成 nexus。注意 chown 一定要在软链接建立之后执行并且对 /data/nexus-work 也要做否则启动时写日志会直接 Permission denied。提示数据目录的软链接方案在 3.x 全系列都适用升级时只换程序目录、不动数据目录是私服维护里性价比最高的习惯。3.2 首次启动与 admin 密码从端口 8081 到离开默认状态启动走 bin/nexus 脚本它是守护进程方式不是前台运行su - nexus -s /bin/bash /opt/nexus/bin/nexus start sleep 20 tail -n 50 /data/nexus-work/nexus3/log/nexus.log cat /data/nexus-work/nexus3/admin.passwordstart 返回后脚本只表示 JVM 已拉起真正要看的是日志里出现 “Started Sonatype Nexus OSS” 才算起来。首次启动会生成 admin.password 文件里面是初始管理密码登录管理界面后系统强制要求修改改完这个文件会被删除。端口默认 8081日志路径取决于你前面软链接指向的位置别记错成程序目录里那份。起来后先用 API 探活curl -s http://127.0.0.1:8081/service/rest/v1/status curl -s -o /dev/null -w %{http_code}\n http://127.0.0.1:8081/第一条返回带版本号的 JSON 就说明服务正常第二条看 HTTP 状态码。要改端口编辑 etc/nexus.properties 里的 application-port然后 bin/nexus restart。这一步如果用 root 执行大概率直接看到那句著名的拒绝提示往下看避坑章。首次登录我一般顺手做三个动作改掉 admin 密码系统会强制但别用弱口令在 Security → Anonymous 里关掉匿名访问尤其内网私服匿名等于仓库裸奔建一个 deploy 专用账号给 CI 和命令行上传用权限只给需要的仓库。这三个动作做完私服才处于“能对外提供服务”的状态而不是“能跑就行”的黑匣子。4. 仓库配置与组件上传npm 先打包还是先 npm initMaven 代理链路一起讲清4.1 先建 blob store 再建仓库三类仓库怎么搭配管理界面里 Administration → Repository → Create repository能看到几十种格式。每个仓库创建时都要选一个 blob storeblob store 就是存储池建议按用途拆大体积的 docker 单独一个maven/npm 共用另一个这样备份和清理有边界。仓库类型就三类记住配比就不容易乱类型读写用途proxy只读 缓存代理 maven central、npmjs依赖只从这进hosted可读可写存团队自己发布的产物group聚合只读把多个仓库合成一个地址给消费者最小可用的 Maven 配比是maven-centralproxy、maven-releaseshosted、maven-snapshotshosted、maven-publicgroup 聚合前三个。npm 同理npmjsproxy、npm-internalhosted要对外统一入口就再建 npm-group。创建时仓库 Name 只允许字母、数字和横线别用下划线命名里带上格式前缀比如 maven-releases、npm-internal运维扫一眼就知道是什么。这是最常规的搭法我在所有新环境都这么起。4.2 npm 上传先 npm init 确定版本再 npm pack 验证最后 npm publish有个高频问题上传 npm 组件到 Nexus是先打包还是先 npm init答案是必须先 npm init。因为 Nexus 的 npm hosted 仓库区分版本靠的是包内 package.json 的 name 和 version 字段不是 tgz 文件名npm pack 只是把当前目录打成压缩包里面如果没有合法 package.jsonpack 和 publish 都会失败。所以“区分版本”这件事发生在 package.json 里而不是文件命名上。npm config set registry http://127.0.0.1:8081/repository/npm-internal/ npm login --registryhttp://127.0.0.1:8081/repository/npm-internal/ npm init npm pack npm publish --registryhttp://127.0.0.1:8081/repository/npm-internal/ npm view my-pkg versions --registryhttp://127.0.0.1:8081/repository/npm-internal/命令顺序本身就是答案npm init 生成 package.json把 version 改成要发布的版本npm pack 本地打一次 tgz顺手检查 files 字段有没有把多余文件带进去npm publish 才真正上传。注意 publish 必须指向 hosted 仓库npm-internal指向 group 或 proxy 会被拒绝登录账号建议单独建 deploy 用户别拿 admin 到处跑。发布后同一个 version 不能重复 publish要发新版就在 package.json 里递增 version——这才是很多人在 Nexus 上“版本分不清”的真正原因不是打包顺序问题是 version 没递增。4.3 Maven 侧配置一个 mirror 走天下distributionManagement 管上传消费者侧只需在 settings.xml 配一个 mirror把中央仓库流量全部导到 maven-publicmirror idnexus-public/id mirrorOf*/mirrorOf urlhttp://127.0.0.1:8081/repository/maven-public//url /mirrormirrorOf 用 * 表示所有仓库都走 Nexus这样即使项目里写了中央仓库地址也不会直连外网。上传构建产物则要在项目 pom.xml 里配 distributionManagement指向 hosted 仓库distributionManagement repository idnexus-releases/id urlhttp://127.0.0.1:8081/repository/maven-releases//url /repository /distributionManagement注意两点settings.xml 里必须有同 id 的 server 段提供账号密码否则 deploy 会 401maven-releases 仓库默认 Deployment policy 是 Disable redeploy开发期想反复传同版本要在仓库设置里临时改成 Allow redeploy上线前改回来。snapshot 版本要另配 maven-snapshots 仓库不要在 releases 里传 SNAPSHOT。配完可以用 mvn dependency:get -Dartifact... 验证拉取链路通不通这一步能筛掉八成“配了但没生效”的问题。5. 避坑清单3.24 在 Unix 上翻车最多的 5 类问题5.1 装好起不来root 拒绝和 JDK 版本两个拦路虎现象root 用户执行 bin/nexus start控制台直接提示 Nexus Repository Manager cannot be run as root进程没起来。原因官方硬性安全限制不允许 root 运行防的是数据目录和配置被提权滥用。解决按第 3 章建 nexus 用户chown 属主后用 su - nexus 启动如果一定要 root 跑改脚本里的 run_as_root 参数但生产环境我极度不建议这是给自己埋雷。连带问题也常见解压用 root、运行用 nexus启动到一半报 Permission denied 写日志解决就是 chown -R nexus:nexus 把程序目录和数据目录一次性改到位别只改一个。现象日志里报 UnsupportedClassVersionError或者 wrapper 直接拒绝说当前 JDK 不被支持。原因3.24 官方支持 JDK 8机器默认的 java 是 11 或 17类文件版本不匹配。解决装 OpenJDK 8启动前显式 export JAVA_HOME/usr/lib/jvm/java-8-openjdk-amd64 再 start不要只改 PATH 不改 JAVA_HOMEnexus 脚本优先读 JAVA_HOME。排查时日志位置记住两处程序目录里的 sonatype-work/nexus3/log/nexus.log 是主日志启动早期的问题去 etc 目录看 wrapper 相关的输出。5.2 跑起来后出问题OrientDB 损坏与磁盘写满现象强制 kill -9 或断电后再启动日志里出现 OrientDB 相关的 record was not found / database is closed 之类错误管理界面一直转圈进不去。原因3.24 的元数据存在 OrientDB 里强制终止时正在写入的页没落盘库文件坏了一处。解决如果没有备份先把 sonatype-work/nexus3 整个目录留好别急着重装覆盖日常正确停止方式是 bin/nexus stop等日志出现 Shutdown complete 再动数据数据盘预留余量磁盘写满时 OrientDB 同样会花我见过写完 blob 后元数据对不上、仓库里一堆无效资产的案例。顺手检查 inode 用 df -i比 df -h 更能提前暴露小文件爆炸的风险。5.3 访问异常反代 502 和上游网关卡下载现象用 nginx 做反向代理后内网访问私服首页白屏、API 502但本机 curl 8081 正常。原因反代没把 Host 头传给 Nexus3.x 对 Host 头校验很敏感。解决nginx 里补上 Host 头这是最常被漏掉的一行location / { proxy_pass http://127.0.0.1:8081; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; }现象maven-central 这类 proxy 仓库拉取一直超时或 404本机能上网但 Nexus 出不去。原因公司访问外网依赖统一出网网关HTTP ProxyNexus 默认不读系统代理。解决在管理后台 Administration → System → HTTP/HTTPS Proxy 里配好网关地址和端口回到仓库设置点 Test Connection配错的典型表现是 Central 的 Last Attempt 一直带着 connect timed out 字样。6. 验证与升级动手前先做一次体检留着后悔药6.1 用 REST API 做一次健康体检3.24 的管理 API 路径和 3.x 后续版本基本一致下面两条命令够日常巡检用curl -s -u admin:密码 http://127.0.0.1:8081/service/rest/v1/status curl -s -u admin:密码 http://127.0.0.1:8081/service/rest/v1/repositoriesstatus 返回 JSON 里能看到版本和初始状态repositories 列出所有仓库确认 group 里的成员有没有被误删。发布完组件后再用 /service/rest/v1/search?repository某个仓库名 查一下资产在不在确认 name 和 version 都入库了再通知团队用。这段我每次升级前都会跑一遍配合磁盘 df -h 和日志里有没有 ERROR基本能判断私服能不能扛下一次重启。6.2 备份与升级3.24 的后悔药升级前最稳的备份是冷备停机状态下直接把整个数据目录打包/opt/nexus/bin/nexus stop tar -czf /data/backup/nexus-data-$(date %F).tar.gz /data/nexus-work/nexus3 /opt/nexus/bin/nexus start冷备包含 OrientDB、blob 和 keystore恢复时把目录原样放回去即可。升级到更新的 3.x 时我一般的做法是备份 → 解压新版程序目录 → 把新程序的 sonatype-work 软链接指到旧数据目录 → 启动新版让它自己做数据迁移。3.24 到相邻版本通常平滑但跨大版本前一定要看官方 release notes尤其注意 JDK 要求和数据格式变化别让“升级”变成“重装”。我做私服升级最大的教训是备份这件事永远比自信更可靠。有一次我跳过冷备直接升迁移到一半磁盘不够回滚又赶上周五晚上整组人盯着日志过周末。从那以后凡是动 Nexus 数据目录的操作我手里一定先有一份能落地的备份版本号、路径、时间都写清楚。希望帮到你。本文还有配套的精品资源点击获取
