企业官网建设流程全解析

简介：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 个参数，否则后面一定会回来补课。

确认环境一般是这几条命令：

java -version df -h /data nproc

第一条看 JDK 是不是 8；第二条确认数据盘有空间，别让同事把私服装在系统盘，一个 docker 镜像仓库把 inode 吃光，整台机器跟着卡；第三条看核数，2C 的小机器建议把堆压到 1024m，4C 以上再考虑用默认值。常见误用是把 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.password

start 返回后脚本只表示 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 init，Maven 代理链路一起讲清

4.1 先建 blob store 再建仓库：三类仓库怎么搭配

管理界面里 Administration → Repository → Create repository，能看到几十种格式。每个仓库创建时都要选一个 blob store，blob store 就是存储池，建议按用途拆：大体积的 docker 单独一个，maven/npm 共用另一个，这样备份和清理有边界。仓库类型就三类，记住配比就不容易乱：

最小可用的 Maven 配比是：maven-central（proxy）、maven-releases（hosted）、maven-snapshots（hosted）、maven-public（group 聚合前三个）。npm 同理：npmjs（proxy）、npm-internal（hosted），要对外统一入口就再建 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.json，pack 和 publish 都会失败。所以“区分版本”这件事发生在 package.json 里，而不是文件命名上。

npm config set registry http://127.0.0.1:8081/repository/npm-internal/ npm login --registry=http://127.0.0.1:8081/repository/npm-internal/ npm init npm pack npm publish --registry=http://127.0.0.1:8081/repository/npm-internal/ npm view my-pkg versions --registry=http://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-public：

<mirror> <id>nexus-public</id> <mirrorOf>*</mirrorOf> <url>http://127.0.0.1:8081/repository/maven-public/</url> </mirror>

mirrorOf 用 * 表示所有仓库都走 Nexus，这样即使项目里写了中央仓库地址也不会直连外网。上传构建产物则要在项目 pom.xml 里配 distributionManagement，指向 hosted 仓库：

<distributionManagement> <repository> <id>nexus-releases</id> <url>http://127.0.0.1:8081/repository/maven-releases/</url> </repository> </distributionManagement>

注意两点：settings.xml 里必须有同 id 的 server 段提供账号密码，否则 deploy 会 401；maven-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_HOME，nexus 脚本优先读 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 头传给 Nexus，3.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 Proxy），Nexus 默认不读系统代理。解决：在管理后台 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/repositories

status 返回 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 数据目录的操作，我手里一定先有一份能落地的备份，版本号、路径、时间都写清楚。希望帮到你。

本文还有配套的精品资源，点击获取