Jenkins Pipeline 构建后推送到Nexus制品库 jenkins 如何连接Nexus？企业级实战 --上 Nexus部署

Nexus制品库

Nexus Repository Manager（通常简称为 Nexus）是一款由 Sonatype 公司开发的强大仓库管理器。你可以把它想象成一个公司内部的"软件图书馆"或"应用商店"。

核心价值 ：它用于存储、管理和分发软件开发过程中所需的各类制品（或称构件），如 JAR 包、npm 模块、Docker 镜像等。
主要作用
1. 搭建私服：作为团队内部的统一依赖源。
2. 加速构建：代理并缓存来自互联网公共仓库（如 Maven Central）的依赖，避免重复下载，显著提升项目构建速度。
3. 制品共享：托管团队内部开发的私有组件，方便在不同项目间共享和复用。
4. 权限控制：提供细粒度的用户权限管理，确保制品的安全性。

️ Nexus 的核心概念

在使用 Nexus 前，理解以下三种仓库类型至关重要：

Hosted（宿主仓库）
- 定义：用于存放团队内部自己开发的、私有的制品。
- 用途：发布项目的正式版本（Release）或开发中的快照版本（Snapshot）。
Proxy（代理仓库）
- 定义：作为远程公共仓库的"代理"或"缓存"。
- 用途：当项目需要某个依赖时，Nexus 会先从自己的缓存中查找；如果找不到，再去配置的远程仓库（如 Maven Central）下载，并缓存到本地，供后续使用。这可以节省带宽并提高下载稳定性。
Group（仓库组）
- 定义：一个逻辑上的"聚合"仓库，它将多个 Hosted 和 Proxy 仓库组合在一起。
- 用途：为开发者提供一个统一的访问入口。开发者只需在项目中配置一个 Group 仓库的地址，就能同时访问到内部私有制品和外部公共依赖，简化了配置。

jenkins连接Nexus制品库

制品库规划服务器ip

ini 复制代码

172.20.10.6

🏗️ 第一部分：企业级 Nexus 部署 (Docker)

在企业环境中，我们不仅要"跑起来"，还要考虑数据持久化 、资源限制 和网络配置。

1. 环境准备与目录规划

为了保证数据不丢失且易于备份，我们需要将 Nexus 的数据目录挂载到宿主机。

bash 复制代码

[root@localhost ~]# mkdir -p /opt/nexus-data
# 赋予权限 (Nexus 容器内默认用户 UID 为 200)
[root@localhost ~]# chown -R 200:200 /opt/nexus-data
[root@localhost ~]# chmod -R 770 /opt/nexus-data

2. 启动容器 (生产参数详解)

我们使用 docker run 命令启动，并注入关键的 JVM 参数以适配企业级内存需求。

bash 复制代码

[root@localhost ~]# docker run -d --name nexus3 --restart=always -p 8081:8081 -p 8082:8082 -p 8083:8083 -v /opt/nexus-data:/nexus-data -e NEXUS_SECURITY_RANDOMPASSWORD=false -e INSTALL4J_ADD_VM_PARAMS="-Xms1g -Xmx1g -XX:MaxDirectMemorySize=3g -Djava.util.prefs.userRoot=/nexus-data" sonatype/nexus3:latest


[root@localhost ~]# docker ps 
CONTAINER ID   IMAGE                    COMMAND                  CREATED         STATUS         PORTS                                                           NAMES
62790c8039fa   sonatype/nexus3:latest   "/opt/sonatype/nexus..."   3 minutes ago   Up 2 minutes   0.0.0.0:8081-8083->8081-8083/tcp, :::8081-8083->8081-8083/tcp   nexus3

关键参数解读：

端口映射:
- 8081: Web 管理界面和 Maven/PyPI 等 HTTP 服务。
- 8082: 通常用于 Docker Registry 的 HTTP 访问（需配置）。
- 8083: 通常用于 Docker Registry 的 HTTPS 访问或 Raw 仓库。
-e NEXUS_SECURITY_RANDOMPASSWORD=false : 禁用随机生成的初始密码，直接使用默认密码 admin123（首次登录后务必修改）。
-e INSTALL4J_ADD_VM_PARAMS : 企业级关键点。默认 Nexus 内存较小，企业环境建议至少分配 2GB-4GB 堆内存，防止构建高峰期 OOM (内存溢出)。
-v: 数据持久化，确保容器删除后制品不丢失。

3. 初始化与安全加固

登录：访问 http://<IP>:8081，账号 admin，密码 admin123。
配置 Blob Store (存储策略):
- 企业级建议：将热数据 （最新快照）和冷数据（历史版本）分离。
- 在 System > Blob Stores 中，可以配置基于 S3 的存储或文件存储。
清理策略 (Cleanup Policies):
- 配置 System > Cleanup Policies，例如：自动删除超过 90 天未被下载的 maven-snapshots，节省磁盘空间。

🔗 第二部分：Jenkins 与 Nexus 的适配配置

jenkins安装插件

安装路径：Jenkins 管理 -> 插件管理 -> 可选插件 -> 搜索 "Nexus Artifact Uploader" -> 安装。

ini 复制代码

Nexus Artifact Uploader  #支持上传任意类型的文件到 Nexus 的 Raw、Maven 等类型的仓库。
Pipeline Utility Steps #通用工具库 (专注于数据/文件操作)

集成的核心在于权限隔离 和凭证管理 。不要使用 admin 账号进行构建部署

创建自定义角色

在"Roles"页面，点击右上角的 "Create role"（创建角色）。
在弹出的表单中：
- Role ID : 输入一个唯一标识，例如 dev-deployer。
- Role Name : 输入一个易读的名称，例如 Developer Deployer Role。
- Role Type : 保持默认的 "Nexus role"。
- Description : 可选，填写角色用途，例如"允许开发者上传和浏览仓库"。

添加权限（关键步骤）

在 "Privileges"（权限）区域，你会看到两个列表：
- Available（左侧）：所有可用的权限。
- Granted（右侧）：当前角色拥有的权限。
在左侧的"Available"列表中，使用 Filter （过滤器）搜索框，输入 nx-repository-view，系统会筛选出所有以该前缀开头的权限。
你需要找到并添加以下两类权限：
- nx-repository-view-\* ：这是"浏览/读取"权限。你需要为每个你希望用户能访问的仓库格式（如 maven2, npm, docker）和仓库类型（如 hosted, proxy, group）添加对应的权限。
  - 例如，如果你希望用户能浏览所有 Maven 仓库，就添加 nx-repository-view-maven2-*-read 和 nx-repository-view-maven2-*-browse。
  - 如果你希望用户能浏览所有仓库，可以添加 nx-repository-view-*-*-read 和 nx-repository-view-*-*-browse（*代表通配符）。
在 Nexus 3 中，控制"上传"动作的核心权限实际上是 nx-repository-view-\*-\*-edit 或 nx-repository-view-\*-\*-add。
- nx-repository-view-[格式]-[仓库名]-add: 允许向仓库中添加新组件（上传新文件）。
- nx-repository-view-[格式]-[仓库名]-edit: 允许编辑仓库中的组件（通常包含覆盖上传）。
选中你需要的权限，点击中间的 右箭头 >，将它们移动到右侧的"Granted"列表中。

Nexus 端：创建专用部署用户

进入 Security > Users，创建用户 jenkins-deployer。
设置密码（例如：SecurePass123!）。
权限分配：
- 不要给 nx-admin 权限。
- 仅授予 nx-repository-view-* (读取/浏览) 和 (上传/部署) 相关的角色权限。
  
  以下是完整的填写指南：

这是用户登录和身份识别的基础信息。

ID :
- 填写建议 : 输入一个唯一的英文用户名，例如 admin02 或 zhangsan。
- 注意: 只能使用字母、数字或下划线，不能用中文。这是用户登录时输入的账号。
First name :
- 填写建议 : 输入用户的名字，例如 San。
Last name :
- 填写建议 : 输入用户的姓氏，例如 Zhang。
Email :
- 填写建议 : 输入一个有效的邮箱地址，例如 zhangsan@company.com。
- 注意: 虽然不一定强制验证，但建议填写真实的，用于找回密码或接收通知。
Password :
- 填写建议: 设置一个强密码（通常要求 6 位以上，包含字母和数字）。
Confirm password :
- 填写建议: 再次输入上面的密码，确保一致。
Status :
- 填写建议 : 选择 Active。
- 注意 : 如果选 Disabled，用户创建后无法登录。

第二部分：角色权限

这是最关键的一步，决定了用户能干什么。

Available (左侧列表) : 系统里现有的角色。
- nx-admin: 超级管理员。拥有系统的所有权限，可以做任何操作。
- nx-anonymous: 匿名用户。通常权限非常低，只能下载公共包，不能管理。
- Developer Deployer Role: 自定义角色。权限更加灵活
Granted (右侧列表): 用户实际拥有的角色。

操作步骤：

在左侧列表中，点击选中 nx-admin。
点击中间的 右箭头按钮 >。
确保 nx-admin 出现在右侧的框里。

全部确认无误后，点击底部的按钮即可完成创建。

Nexus创建仓库

在 Nexus Repository Manager 3 中创建 Hosted（宿主） 类型的仓库，通常是为了存储团队内部开发的私有构件（如自研的 Jar 包、npm 包等）。

以下是基于 Nexus 3 界面的标准创建流程，我将其整理为清晰的步骤：

🚀 核心步骤：创建 Hosted 仓库

1. 进入创建页面

登录 Nexus 管理界面（默认通常是 http://你的IP:8081）。
点击左侧菜单栏的 Administration（齿轮图标）。
在 Repository 栏目下，点击 Repositories。
点击页面上方的 Create repository 按钮。

2. 选择仓库格式 (Recipe)

在弹出的列表中，你需要选择具体的技术格式。

如果你要存 Java 包，选择 maven2 (hosted)。
如果你要存前端包，选择 npm (hosted) 。这里需要注意raw与npm的仓库类型有啥区别？实际企业中会创建什么类型的仓库，怎么选择

简单来说：npm 是给代码依赖用的，raw 是给文件存储用的。

📦 核心区别：npm 与 raw

特性	npm (Hosted)	raw (Hosted)
本质	包管理器	通用文件服务器
存储内容	必须是符合 npm 规范的包 (`.tgz`)，包含 `package.json`。	任意文件 (`.zip`, `.jar`, `.exe`, `.tar.gz`, `.iso`)。
目录结构	强制遵循 npm 规范 (`/package-name/-/package-version.tgz`)。	自定义。你可以随意定义文件夹层级 (如 `/project/v1/app.zip`)。
访问方式	需通过 `npm install` 命令或 npm 客户端工具访问。	直接通过 HTTP URL 下载 (如 `curl` 或 `wget`)。
适用场景	前端组件库、Node.js 后端依赖、私有 npm 包。	前端构建产物(部署包)、后端 Jar 包、Docker 镜像备份、二进制大文件。

🏢 实际企业中会创建什么类型的仓库？

在一个标准的企业级 DevOps 流程中，Nexus 通常会同时存在这三种类型的仓库，各司其职：

1. npm 类型仓库（用于开发阶段）

用途：存放公司内部开发的 UI 组件库 或 公共 JS 工具包。
场景：前端程序员写代码时，执行 npm install @my-company/ui-kit，就是从这里的 npm (proxy/group) 仓库拉取依赖。
为什么不用它存部署包？ 因为 npm 仓库对文件结构有严格校验（你之前遇到的 400 错误就是因为 zip 不符合 npm 规范），且难以通过简单的 URL 直接下载给 Ansible 使用。

2. raw 类型仓库（用于交付/部署阶段）⭐

用途：存放 前端构建后的静态资源包 （如 dist.zip）、后端编译好的二进制文件。
场景
- Jenkins 打包完成后，上传 web-app-v1.0.zip 到 raw 仓库。
- Ansible 脚本通过 get_url 模块，直接下载这个 zip 包到生产服务器并解压。
优势
- 完全兼容：支持 zip、tar.gz 等所有格式。
- URL 友好：上传后 Nexus 会提供一个直接的下载链接，Ansible 极易消费。
- 结构灵活 ：你可以按 /项目名称/环境/版本号/ 来组织文件。

3. maven2 类型仓库（Java 生态专用）

用途：存放 Java 的 jar 包、war 包。
场景：Maven/Gradle 构建工具自动上传和下载依赖。

🛠️ 怎么选择？（决策指南）

决策逻辑如下：

你是要给程序员 npm install 用的吗？
- 是 -> 选 npm。
- 否 -> 往下看。
你是要存编译好的产物（zip, jar, tar.gz）给服务器部署用的吗？
- 是 -> 选 raw。
你是 Java 项目且用 Maven/Gradle 管理吗？
- 是 -> 选 maven2。

其他如 docker (hosted), nuget (hosted) 等依此类推。

创建保存java的jar包仓库

创建保存前端的代码包仓库

刚刚创建的仓库

3. 填写关键配置

这是最关键的一步，决定了仓库的行为。请参考下表进行配置：

配置项	建议值/说明	作用
Name	自定义名称例如：`maven-releases` 或 `maven-snapshots`	仓库的唯一标识，建议见名知意。
Version Policy	Release 或 Snapshot	Release ：用于存储正式版本（如 1.0.0）。 Snapshot：用于存储开发中的快照版本（如 1.0.0-SNAPSHOT）。
Deployment Policy	Allow redeploy 或 Disable redeploy	Allow redeploy ：允许覆盖上传（通常用于 Snapshot 仓库）。 Disable redeploy：禁止覆盖（通常用于 Release 仓库，防止正式版被篡改）。
Blob store	default (或自定义)	文件实际存储的位置，一般保持默认即可。
Strict Content Type Validation	勾选 (默认)	严格校验上传文件的类型，建议保持勾选以保证仓库纯净。

4. 保存

确认信息无误后，点击底部的 Create repository 按钮即可完成创建。

💡 最佳实践：Release 与 Snapshot 分离

在实际工作中，我们通常会创建两个 Hosted 仓库来配合使用，以保持依赖管理的规范性：

私有正式版仓库 (Hosted - Release)
- 名称示例 ：maven-releases
- Version Policy ：Release
- Deployment Policy ：Disable redeploy (禁止覆盖)
- 用途：存放正式发布的、稳定的内部库。一旦发布，不允许随意修改，保证生产环境的稳定性。
私有快照版仓库 (Hosted - Snapshot)
- 名称示例 ：maven-snapshots
- Version Policy ：Snapshot
- Deployment Policy ：Allow redeploy (允许覆盖)
- 用途：存放开发过程中频繁更新的内部库。允许重复上传同一个版本号（如 1.0.0-SNAPSHOT），方便团队成员获取最新代码。

接下文jenkins master-slave架构连接Nexus