Nexus Repository OSS 3: администратор с нуля до эксперта в DevOps

Старт: установка Nexus 3.x, Docker/Proxmox, systemd, первый вход

Nexus Repository 3 (далее Nexus) — репозиторий артефактов, который обычно становится центральной точкой DevOps-ландшафта: проксирует публичные репозитории, хранит собственные артефакты, ускоряет сборки, повышает воспроизводимость и контролируемость поставки.

В этом уроке вы развернёте Nexus 3.x на Ubuntu тремя способами (Docker, systemd на хосте, Proxmox), сделаете первый вход и выполните минимальный post-install чеклист, чтобы инстанс был пригоден для дальнейших модулей (UI, репозитории, security, интеграции CI/CD).

!Наглядно показывает, чем отличаются Docker, systemd на хосте и VM в Proxmox

Что считается готовым результатом

К концу урока у вас должно быть:

Рабочий Nexus 3.x, доступный по HTTP на http://<host>:8081.

Понимание, где лежат данные Nexus (blob store и конфигурация) и как их бэкапить на базовом уровне.

Умение находить стартовый пароль администратора и делать первичную настройку.

Базовые навыки диагностики запуска (логи, статус сервиса, порты).

Предварительные требования

Хост и ресурсы

Минимальный старт для учебного стенда:

Ubuntu Server 22.04 LTS или 24.04 LTS.

CPU: 2 vCPU.

RAM: 4–8 GB (лучше 8 GB, чтобы дальше комфортно работать с несколькими форматами репозиториев).

Диск: от 40 GB (в реальности быстро растёт из-за кэша proxy-репозиториев).

Сеть и порты

Входящий доступ к TCP/8081 (или только с вашей сети/VPN).

DNS-имя желательно сразу (например, nexus.dev.local), чтобы позже корректно настраивать Base URL и reverse proxy.

Откуда брать дистрибутив

Используйте официальные источники:

Страница загрузки Nexus Repository: Sonatype Download

Документация Nexus Repository Manager 3: Sonatype Help: Nexus Repository Manager 3

Docker-образ (официальный в Docker Hub): sonatype/nexus3 on Docker Hub

Куда ставить: быстрое сравнение подходов

Docker (быстро и удобно)

Подходит, если:

Нужен быстрый старт.

Вы уже живёте в контейнерах.

Вы хотите одинаково развернуть dev/test стенды.

Риски/нюансы:

Важно правильно смонтировать /nexus-data (иначе потеряете данные при пересоздании контейнера).

Обновления делаются через смену image tag и контроль миграций данных.

systemd на хосте (часто выбирают для продакшена без Kubernetes)

Подходит, если:

Нужен простой и прозрачный сервис под управлением systemd.

Хотите проще контролировать JVM-параметры, лимиты файловых дескрипторов, взаимодействие с диском.

Proxmox (как платформа виртуализации)

Подходит, если:

В компании стандарт — Proxmox.

Нужны снапшоты VM, миграция по нодам, изоляция.

Рекомендация:

Для Nexus чаще выбирают VM (QEMU/KVM), а не LXC, чтобы избежать нюансов с systemd, лимитами, файловой системой и nesting.

Вариант A: установка Nexus в Docker

Установка Docker на Ubuntu

Если Docker ещё не установлен, используйте официальный репозиторий Docker:

Инструкция установки Docker Engine: Install Docker Engine on Ubuntu

После установки проверьте:

Запуск контейнера Nexus

Минимальный вариант с volume и пробросом порта:

Пояснения:

-p 8081:8081 публикует веб-интерфейс.

-v nexus-data:/nexus-data сохраняет данные вне контейнера.

--restart unless-stopped переживает перезагрузку.

Проверка, что контейнер жив:

Альтернатива: docker-compose

Если вы предпочитаете compose:

Запуск:

Где стартовый пароль в Docker

Стартовый пароль admin лежит внутри данных:

Сохраните его, но не храните в открытом виде в чатах/тикетах.

Вариант B: установка Nexus на Ubuntu как systemd service

Этот вариант полезен, если вы хотите максимально «классический» Linux-сервис.

Подготовка пользователя и директорий

Создаём отдельного пользователя без shell-доступа:

Создаём каталоги:

Скачивание и распаковка Nexus

Скачайте tar.gz с официальной страницы загрузки: Sonatype Download

Дальше общий шаблон команд (подставьте актуальное имя файла):

Важно:

Не распаковывайте Nexus в домашнюю директорию администратора.

Данные Nexus должны лежать отдельно от бинарников.

Настройка каталога данных (sonatype-work)

По умолчанию Nexus создаёт work directory (часто это /opt/sonatype-work/nexus3). Убедимся, что права корректные:

Настройка запуска от пользователя nexus

Откройте файл nexus.rc и задайте пользователя:

Проверьте, что строка стала:

systemd unit

Создайте юнит /etc/systemd/system/nexus.service:

Примените и запустите:

Проверка порта:

Где стартовый пароль при systemd-установке

Обычно файл пароля создаётся в work directory:

Если путь отличается, ищите в логах стартовую подсказку или проверьте наличие каталога nexus3 внутри sonatype-work.

Где смотреть логи

Варианты зависят от дистрибутива и настроек:

systemd:

Логи приложения (часто лежат внутри work directory, например .../log/):

Вариант C: развёртывание в Proxmox

В Proxmox вы обычно выбираете один из двух путей:

VM (KVM) + установка Nexus как в варианте A (Docker) или B (systemd).

LXC-контейнер + Docker/systemd (требует аккуратной настройки, не лучший старт для обучения).

Рекомендованный путь: VM Ubuntu

Минимальный план:

Создайте VM в Proxmox:

1. 2–4 vCPU. 2. 8 GB RAM. 3. Диск 60+ GB (лучше thin только если понимаете последствия переполнения storage). 4. Сетевой адаптер VirtIO.

Установите Ubuntu Server.

Дальше следуйте варианту A (Docker) или B (systemd).

Плюсы VM в контексте Nexus:

Предсказуемые лимиты ресурсов.

Проще обслуживать обновления ядра/дисковой подсистемы.

Снапшоты для лабораторных работ (но не подменяйте ими бэкапы).

Первый вход в UI и первичная инициализация

Открываем веб-интерфейс

Откройте в браузере:

http://<IP_или_DNS>:8081

При первом старте Nexus может инициализироваться несколько минут.

!Помогает узнать экран первого логина

Вход под admin

Username: admin

Password: значение из admin.password (см. ваш вариант установки)

После входа мастер первичной настройки обычно попросит:

Сменить пароль admin.

Выбрать режим анонимного доступа (Enable anonymous access).

Рекомендация для стенда:

Анонимный доступ отключайте, чтобы сразу привыкать к корректной модели доступа.

Базовый post-install чеклист (минимум)

Сделайте сразу, пока инстанс «чистый»:

Смените пароль admin на сильный и сохраните в секрет-хранилище.

Проверьте, что вы понимаете где лежат данные:

1. Docker: /nexus-data (volume). 2. systemd: обычно /opt/sonatype-work/nexus3.

Проверьте свободное место на диске:

Проверьте, что служба стартует после перезагрузки:

1. Docker: --restart unless-stopped. 2. systemd: systemctl is-enabled nexus.

Зафиксируйте текущую версию Nexus (понадобится при апгрейдах и разборе инцидентов):

1. В UI на странице System или в футере. 2. Через логи старта.

Важные замечания для дальнейших модулей

Про данные: почему так важно разделять бинарники и storage

Nexus хранит артефакты и метаданные в своём каталоге данных (work directory). Потеря этого каталога равна потере:

Загруженных артефактов.

Кэша proxy-репозиториев.

Конфигурации репозиториев, пользователей, ролей (в зависимости от версии и настроек).

Поэтому:

В Docker всегда используйте volume или bind mount.

На хосте держите данные на отдельном диске или разделе, если ожидается рост.

Про Base URL и reverse proxy

Позже, когда появятся Docker registry, NuGet, npm и другие форматы, вам почти наверняка понадобится стабильный URL и TLS.

На этом уроке достаточно:

Рабочего HTTP-доступа.

Понимания, что «правильный» production-вариант часто выглядит так: https://nexus.company.tld через reverse proxy, который терминирует TLS.

В модуле по безопасности вы настроите TLS и интеграции (LDAP/SSO) более полно.

Быстрая диагностика типовых проблем старта

Долгая инициализация и «не открывается UI»

Проверьте последовательно:

Процесс и порт:

Логи:

1. Docker:

2. systemd:

Диск и права на каталог данных:

Нехватка памяти

Симптомы:

Java-процесс падает.

В логах видно ошибки выделения памяти.

Что делать на старте:

Дайте VM/хосту больше RAM.

Уберите лишние сервисы с этой машины.

Тонкую настройку JVM и производительности вы будете делать в модуле мониторинга и high-load.

Домашний проект по уроку

Сделайте один вариант развёртывания (Docker или systemd), а затем оформите результат как небольшой артефакт для команды:

Создайте файл README.md (локально у себя) с разделами:

1. Как развернуть Nexus (команды установки). 2. Где лежат данные. 3. Как получить стартовый пароль. 4. Как посмотреть логи. 5. Как проверить доступность (curl/браузер).

Зафиксируйте параметры окружения:

1. Ubuntu версия. 2. Nexus версия. 3. CPU/RAM/Disk.

Подготовьте план безопасного хранения admin-пароля (например, в Vault/Bitwarden/Keepass) и запрет на передачу пароля в открытых каналах.

В следующих уроках вы начнёте работать с UI (Dashboard, Repositories, Tasks, Security), поэтому важно, чтобы инстанс был стабильным и воспроизводимо разворачиваемым.

Администрирование UI: Dashboard, Repositories, Tasks, Security, базовые операции

В предыдущем уроке вы развернули Nexus Repository 3.x на Ubuntu (Docker или systemd) и сделали первый вход под admin. Теперь вы систематизируете работу с админским UI: где смотреть состояние системы, как управлять репозиториями на базовом уровне, как устроены планировщик задач и модель доступа.

Цель урока — чтобы вы уверенно ориентировались в интерфейсе и выполняли типовые админские операции без «клика наугад», понимая, что именно меняется и где это потом диагностировать.

!Карта основных зон UI, чтобы быстрее ориентироваться

Что считается готовым результатом

К концу урока у вас должно получиться:

Быстро находить в UI разделы Dashboard, Repositories, Tasks, Security и понимать их назначение.

Выполнить базовые операции администратора: проверить состояние, включить/выключить репозиторий, запустить задачу вручную, создать пользователя и выдать ему доступ через роль.

Уметь подтвердить изменения не только «глазами в UI», но и через логи/REST (минимально).

Коротко о терминах (чтобы дальше не путаться)

Repository — логическая точка доступа для клиентов (Maven, npm, NuGet, Docker и т.д.).

Hosted — репозиторий, куда вы загружаете свои артефакты.

Proxy — репозиторий, который проксирует внешний источник (кэширует).

Group — репозиторий-агрегатор, который объединяет несколько hosted/proxy в один URL.

Blob store — место хранения бинарных данных (файлов артефактов) на диске/в S3 (в дальнейшем).

Component — «пакет/артефакт» как единица (например, Maven artifact с версией).

Asset — конкретный файл внутри component (например, .jar, .pom, .tgz).

Task — плановая операция обслуживания (reindex/rebuild/cleanup/repair и т.п.).

Privilege / Role / User — базовая модель доступа: привилегии назначаются ролям, роли выдаются пользователям.

Официальная документация для справки: Nexus Repository Manager 3

Навигация по UI: как устроен «путь администратора»

Типовой паттерн работы:

Пользовательский UI (Browse/Search) — проверяем, как «видят» репозитории клиенты.

Админский UI (Administration) — вносим изменения: репозитории, задачи, безопасность, системные настройки.

Практическая привычка:

Любое изменение в админке фиксируйте в двух местах.

1. В UI (что вы поменяли). 2. В наблюдаемости (логи/задачи/события), чтобы понимать, как это проявляется при инцидентах.

Если вы не видите нужный раздел в админке, чаще всего причина одна из двух:

Вы вошли не тем пользователем.

У вашего пользователя нет роли/привилегий на этот раздел.

Dashboard: что смотреть в первую очередь

Dashboard — это «панель приборов», где вы быстро отвечаете на вопросы: сервис жив? чем занят? достаточно ли ресурсов? что пошло не так?

Что полезно проверять каждый раз после изменений или обновлений:

Доступность UI и время отклика.

Системная информация (версия Nexus, Uptime).

Состояние хранилища (если отображается) и косвенные признаки проблем с диском.

Активность фоновых работ (особенно после изменения репозиториев/политик).

Практика: быстрый health-check без UI

Даже если UI «подвисает», REST-статус часто помогает понять, жив ли процесс.

Выполните запрос статуса.

Выполните расширенную проверку.

Если jq не установлен:

Что это вам даёт в продакшене:

Понятный сигнал для мониторинга (HTTP-код, JSON-ответ).

Возможность автоматизировать проверки в CI/CD или в systemd health-check.

Repositories: как читать список репозиториев и не допускать типовых ошибок

В разделе Repositories вы:

Создаёте репозитории (hosted/proxy/group).

Включаете/выключаете репозиторий.

Управляете параметрами хранения (blob store), политиками очистки (cleanup), ограничениями доступа.

Получаете URL, который потом используют CI/CD и разработчики.

!Как выглядит список репозиториев и ключевые параметры

Как безопасно воспринимать параметры репозитория

Ключевые настройки, которые почти всегда важны:

Name — участвует в URL; менять на работающем проде опасно, так как сломает клиентов.

Format — формат репозитория (maven2, npm, nuget, docker, raw). Формат определяет протокол и поведение.

Type — hosted/proxy/group.

Online — «включён/выключен». В offline репозиторий не обслуживает клиентов.

Blob store — где физически лежат бинарные данные.

Что обычно нельзя «просто поменять» без последствий:

Format.

Type.

Name.

Если вам нужно «переименовать» репозиторий в проде, чаще всего делается миграция: создаётся новый repo, настраиваются клиенты, выполняется перенос артефактов, затем старый выводится из эксплуатации.

Практика: включить/выключить репозиторий и проверить эффект

Откройте Administration → Repositories.

Выберите любой тестовый репозиторий (для учебного стенда подойдёт встроенный proxy).

Переключите его в состояние offline (обычно это переключатель Online).

Проверьте, что клиентский доступ ломается.

Пример проверки HTTP-ответа URL репозитория (подставьте URL из UI):

Верните репозиторий в online.

Повторите curl -I и сравните поведение.

Что вы тренируете:

Контролируемое отключение источника при инциденте (например, внешний proxy «тянет» мусор).

Понимание, что UI-переключатель влияет на доступность для клиентов.

Практика: создать один raw hosted репозиторий для админских нужд

Хотя форматы Maven/npm/NuGet/Docker мы будем детально настраивать в следующих модулях, raw полезен уже сейчас как «технический репозиторий» для:

хранения внутренних скриптов,

хранения артефактов диагностики,

временного обмена файлами между CI и админами.

Шаги:

Administration → Repositories → Create repository.

Выберите формат raw.

Выберите тип hosted.

Задайте имя, например raw-infra.

Проверьте, что репозиторий создан и отображается в списке.

Проверка URL (пример):

Важно:

В проде raw-репозитории часто требуют строгих прав, потому что туда легко «залить что угодно».

Tasks: планировщик обслуживания и «кнопки, которые чинят и ломают»

Раздел Tasks — один из важнейших для администратора, потому что здесь живут:

регулярные уборки (cleanup),

перестройки индексов/browse-данных,

repair-операции,

служебные задачи, которые могут быть тяжёлыми для диска/CPU.

Задача в Nexus — это сущность с параметрами:

тип задачи (что делаем),

расписание,

контекст (какой репозиторий/что чистим),

возможность запуска вручную,

журнал выполнения (успех/ошибка).

!Как выглядит управление задачами и где смотреть результат

Практика: запустить задачу вручную и найти лог

Откройте Administration → Tasks.

Найдите задачу, связанную с rebuild/reindex/browse (названия могут отличаться по версии, но смысл один).

Запустите её вручную.

Дождитесь завершения.

Откройте детали выполнения и найдите лог.

Что фиксировать администратору:

Время старта/завершения.

Ошибки (особенно связанные с диском, правами, blob store).

Влияние на нагрузку (в проде важны окна обслуживания).

Практика: понять «опасные» классы задач

Без привязки к конкретным названиям (они могут отличаться), классифицируйте задачи так:

Низкий риск: сбор метрик/обновление лёгких данных.

Средний риск: rebuild/reindex/browse, cleanup (может быть тяжело при большом объёме).

Высокий риск: repair/reconcile/compact/операции, затрагивающие базы/хранилища (выполняются осознанно, часто после бэкапа).

Практическое правило:

Любую repair-задачу сначала выполняйте на стенде или в окно обслуживания и обязательно проверяйте свободное место на диске.

Security: пользователи, роли, привилегии и базовая гигиена доступа

Раздел Security — это то, что отделяет «у нас просто сервис» от управляемой enterprise-инфраструктуры.

Модель доступа в двух предложениях

Privilege описывает действие (например, читать репозиторий, пушить в hosted, администрировать).

Role — набор привилегий; User получает доступ через назначенные роли.

!Наглядная модель User → Role → Privilege

Практика: создать пользователя для CI и дать минимальные права

Сценарий: вам нужен пользователь ci-bot, который может только скачивать из group-репозитория (read-only).

Создайте пользователя.

- Administration → Security → Users → Create local user. - Username: ci-bot. - Email: технический (или пустой, если политика позволяет). - Status: active.

Создайте роль.

- Administration → Security → Roles → Create role. - Role ID: nx-ci-readonly. - Description: Read-only access for CI.

Назначьте роли/привилегии.

- Вариант A (предпочтительнее для начала): добавьте встроенные роли/привилегии чтения, если они подходят. - Вариант B (точнее): выдайте привилегии чтения только на конкретные репозитории.

Привяжите роль к пользователю ci-bot.

Проверьте.

1. Выйдите из admin. 2. Зайдите под ci-bot. 3. Убедитесь, что разделы администрирования недоступны, но скачивание из нужного репозитория возможно.

Практический смысл:

Вы не используете admin в CI.

Вы не даёте лишних прав (принцип минимально необходимых привилегий).

Практика: выключить anonymous access (если включали ранее)

В учебном стенде часто включают anonymous ради скорости, но в реальной эксплуатации это обычно приводит к:

неконтролируемым скачиваниям,

сложной атрибуции действий,

ошибкам в настройке клиентов (которые «и так работает» без логина).

Действия:

Найдите настройку anonymous access в Security.

Отключите anonymous.

Проверьте, что без логина клиент не скачивает.

Базовые операции администратора, которые стоит сделать сразу

Проверить версию Nexus и зафиксировать в документации

Вам нужно понимать версию для:

планирования апгрейдов,

сопоставления багов/поведения,

коммуникации с командой.

Где искать:

В UI (обычно в системной информации/футере/странице about).

В логах старта.

Настроить базовые системные параметры (минимальный набор)

В разделе Administration → System (названия подпунктов могут отличаться по версии) обычно настраиваются:

Base URL (важно для корректных ссылок, токенов и некоторых интеграций).

Email Server (для уведомлений, если используется).

API/токены (в зависимости от корпоративной политики).

Рекомендация для дальнейших модулей:

Если у вас есть DNS-имя (например, nexus.dev.local), используйте его как базовый адрес уже сейчас.

Где смотреть логи, когда «в UI ничего не понятно»

Для Docker:

Для systemd:

Если вы запускаете тяжёлую задачу или меняете репозитории, лог — первое место, куда вы идёте при ошибке.

Типовые проблемы UI и быстрые решения

Не вижу Administration/Repositories/Tasks/Security.

1. Проверьте, что вы вошли под нужным пользователем. 2. Проверьте роли пользователя.

UI открывается, но операции «думают» очень долго.

- Часто это диск, высокая нагрузка или нехватка RAM. - Проверьте логи, df -h, системные метрики.

После отключения anonymous у всех «сломалось».

- Это ожидаемо, если клиенты не настроены на auth. - Решение: создать корректных пользователей/токены и прописать настройки в CI.

Домашний проект по уроку

Подготовьте «админский чеклист навигации и доступа» для вашей команды.

Сделайте документ UI-Admin-Cheatsheet.md со следующей структурой:

Как проверить, что Nexus жив.

1. Через UI (что смотреть на Dashboard). 2. Через REST (/service/rest/v1/status и /service/rest/v1/status/check).

Где в UI управлять репозиториями.

1. Как найти URL репозитория. 2. Как быстро перевести репозиторий offline/online.

Где в UI запускать Tasks.

1. Как запускать вручную. 2. Где смотреть результат и лог.

Как устроена Security-модель.

1. User → Role → Privilege. 2. Почему нельзя использовать admin в CI.

Практический результат.

1. Создан пользователь ci-bot. 2. Создана роль nx-ci-readonly. 3. Отключён anonymous (если был включён).

Этот документ вы будете дополнять в следующих модулях, когда появятся Maven/npm/NuGet/Docker-репозитории, интеграции CI/CD и продвинутая безопасность (LDAP/SSO/TLS).

Репозитории hosted/proxy/group: Maven, npm, NuGet, Docker, raw

В прошлых уроках вы развернули Nexus Repository 3.x и освоили базовую навигацию по UI: Dashboard, Repositories, Tasks, Security. Теперь вы переходите к самой «прикладной» части: проектированию и созданию репозиториев разных форматов и типов.

В этом уроке вы научитесь создавать связки hosted/proxy/group для основных форматов: Maven, npm, NuGet, Docker, raw. Это базовый навык администратора Nexus: правильно спроектированная структура репозиториев уменьшает количество инцидентов, упрощает настройку CI/CD и ускоряет сборки за счёт кэширования.

!Схема, показывающая роль hosted/proxy/group как единого дизайна

Что считается готовым результатом

К концу урока у вас должно быть:

Понимание, чем отличаются hosted, proxy, group и почему в продакшене почти всегда дают клиентам именно group.

Созданные репозитории для форматов maven2, npm, nuget, docker, raw.

Проверка работы каждого формата через соответствующий клиент или curl.

Понимание ключевых настроек репозитория, которые нельзя менять «на горячую» без миграции.

Базовая модель: format + type + policy

В Nexus репозиторий описывается тремя ключевыми характеристиками.

Format: протокол/поведение клиента (например, maven2, npm, nuget, docker, raw).

Type:

- hosted: вы публикуете артефакты внутрь Nexus. - proxy: Nexus кэширует внешний источник. - group: единый endpoint, который объединяет несколько hosted/proxy.

Policy (чаще всего обсуждается для Maven, но идея важна в целом):

- Release: неизменяемые версии. - Snapshot: изменяемые версии.

Практическое правило админа:

Для сборок и разработчиков старайтесь давать один URL на формат, обычно это group.

Внутри group располагайте репозитории в осознанном порядке: обычно сначала hosted (ваши артефакты), затем proxy (внешние зависимости).

Нейминг и «эталонная» структура

Один из самых частых источников хаоса в Nexus — случайные имена репозиториев. Выберите понятный шаблон и придерживайтесь его.

Рекомендуемый шаблон имён:

maven-central (proxy)

maven-releases (hosted)

maven-snapshots (hosted)

maven-public (group)

npm-proxy (proxy)

npm-hosted (hosted)

npm-group (group)

nuget-org (proxy)

nuget-hosted (hosted)

nuget-group (group)

docker-hub (proxy)

docker-hosted (hosted)

docker-group (group)

raw-infra (hosted)

Важно про стабильность:

Имя репозитория участвует в URL вида http://<HOST>:8081/repository/<repo-name>/.

Переименование репозитория в продакшене почти всегда означает миграцию клиентов и данных.

!Пример того, как читать список репозиториев и отличать format/type

Общий алгоритм создания репозиториев в UI

Независимо от формата шаги одинаковые.

Откройте Administration → Repositories.

Нажмите Create repository.

Выберите формат и тип.

Заполните ключевые настройки:

- Name - Online - Blob store (на старте можно оставить default) - Для proxy: Remote storage (URL внешнего источника) - Для group: список членов группы

Сохраните и скопируйте URL репозитория.

Диагностика после создания:

Проверьте доступность URL:

Если отключён anonymous, используйте Basic Auth:

Maven (format: maven2)

Что обычно делают в проде

Стандартная «enterprise» структура Maven в Nexus:

maven-central (proxy на Maven Central)

maven-releases (hosted для ваших релизов)

maven-snapshots (hosted для ваших снапшотов)

maven-public (group: releases + snapshots + central)

Зачем так:

Proxy даёт кэш и контроль внешних зависимостей.

Hosted фиксирует ваши артефакты как единый источник.

Group даёт один endpoint для settings.xml.

Практика: создать Maven proxy на Maven Central

Administration → Repositories → Create repository.

Выберите maven2 (proxy).

Настройки:

- Name: maven-central - Remote storage: https://repo1.maven.org/maven2/ - Online: включено

Сохраните.

Проверка, что endpoint отвечает:

Практика: создать Maven hosted releases и snapshots

Создайте maven2 (hosted):

- Name: maven-releases - Version policy: Release

Создайте второй maven2 (hosted):

- Name: maven-snapshots - Version policy: Snapshot

Практика: создать Maven group для клиентов

Создайте maven2 (group).

Name: maven-public.

Добавьте members в порядке:

- maven-releases - maven-snapshots - maven-central

Сохраните.

Проверка:

Подключение Maven клиента через settings.xml

Обычно команда хочет один URL. Для Maven это group.

Пример минимального ~/.m2/settings.xml:

Замечания:

mirrorOf со значением * говорит Maven, что все запросы идут через Nexus.

Для публикации в maven-releases и maven-snapshots обычно делают отдельные server записи и настраивают distributionManagement в pom.xml или в корпоративных parent POM.

Документация Maven по settings.xml: Apache Maven Settings Reference

npm (format: npm)

Что обычно делают в проде

Типовая структура:

npm-proxy (proxy на публичный registry)

npm-hosted (hosted для внутренних пакетов)

npm-group (group для клиентов)

Публичный registry по умолчанию: https://registry.npmjs.org/.

Практика: создать npm proxy

Create repository → npm (proxy).

Name: npm-proxy.

Remote storage: https://registry.npmjs.org/.

Сохраните.

Проверка:

Практика: создать npm hosted

Create repository → npm (hosted).

Name: npm-hosted.

Сохраните.

Практика: создать npm group

Create repository → npm (group).

Name: npm-group.

Members в порядке:

- npm-hosted - npm-proxy

Сохраните.

Подключение npm клиента через .npmrc

На машине разработчика или в CI задайте registry на group:

Если anonymous отключён, понадобится аутентификация. Варианты зависят от политики:

Basic Auth через npm login в ваш registry.

Токены, если вы так организуете доступ.

Полезная справка по конфигу npm: npm config

NuGet (format: nuget)

Что обычно делают в проде

Типовая структура:

nuget-org (proxy на https://api.nuget.org/v3/index.json)

nuget-hosted (hosted для внутренних пакетов)

nuget-group (group для клиентов)

Практика: создать NuGet proxy

Create repository → nuget (proxy).

Name: nuget-org.

Remote storage: https://api.nuget.org/v3/index.json.

Сохраните.

Практика: создать NuGet hosted и group

Создайте nuget (hosted):

- Name: nuget-hosted

Создайте nuget (group):

- Name: nuget-group - Members: - nuget-hosted - nuget-org

Подключение dotnet/NuGet клиента

Через dotnet удобно подключать source на group.

Добавить источник:

Пояснение:

--store-password-in-clear-text часто нужен на Linux, потому что безопасное хранилище может быть недоступно в headless окружениях.

В проде лучше использовать секреты CI и по возможности более безопасные механизмы хранения.

Посмотреть источники:

Документация по источникам NuGet: dotnet nuget add source

Docker (format: docker)

Docker в Nexus требует чуть больше внимания, чем Maven/npm/NuGet, потому что появляется:

отдельный порт для Docker endpoint,

аутентификация через Docker token flow,

частая необходимость TLS и reverse proxy (полноценно вы сделаете это в модуле по безопасности).

Важный нюанс перед началом

Для работы Docker-аутентификации в Nexus обычно включают realm:

Administration → Security → Realms → активировать Docker Bearer Token Realm.

Если realm не включён, типичный симптом:

docker login или docker pull возвращает ошибки авторизации, хотя логин/пароль верные.

Практика: создать docker hosted

Убедитесь, что включён Docker Bearer Token Realm.

Create repository → docker (hosted).

Name: docker-hosted.

В настройках HTTP:

- включите HTTP (для стенда) - задайте порт, например 8082

Сохраните.

Проверка, что endpoint отвечает:

Ожидаемое поведение:

чаще всего это будет 401 Unauthorized, и это нормально: Docker Registry API требует auth, но сам факт ответа означает, что endpoint жив.

Практика: создать docker proxy на Docker Hub

Create repository → docker (proxy).

Name: docker-hub.

Remote storage: https://registry-1.docker.io.

В настройках HTTP:

- задайте порт, например 8083

Сохраните.

Практика: создать docker group

Create repository → docker (group).

Name: docker-group.

Members:

- docker-hosted - docker-hub

В настройках HTTP:

- задайте порт, например 8084

Сохраните.

Проверка:

Проверка через Docker CLI

Логин:

Pull через proxy (через group):

Push во внутренний hosted (через group, если так настроено правами и порядком):

Замечания:

В реальном продакшене обычно делают https://nexus.company.tld и нормальный сертификат, иначе разработчики сталкиваются с insecure registry настройками.

Тему TLS и reverse proxy вы углубите в модуле по безопасности.

Документация Docker по логину: docker login

raw (format: raw)

Зачем нужен raw

raw — универсальный формат для произвольных файлов. Его удобно использовать для:

внутренних утилит и скриптов,

артефактов инфраструктуры,

временных бинарников между CI и эксплуатацией,

конфигурационных шаблонов.

Плюс raw в том, что он прост: вы контролируете путь и имя файла как часть URL.

Практика: создать raw hosted

Create repository → raw (hosted).

Name: raw-infra.

Сохраните.

Практика: загрузка и скачивание файла через curl

Создадим тестовый файл:

Загрузка:

Скачивание:

Если anonymous отключён и на чтение требуются права:

Порядок репозиториев в group и приоритет разрешения

Group репозиторий отвечает на вопрос: «куда Nexus пойдёт искать артефакт». Общая логика такая:

Nexus проверяет членов group по порядку.

Как только артефакт найден, ответ возвращается клиенту.

Практический вывод:

Ставьте hosted выше proxy, чтобы ваши внутренние пакеты имели приоритет над внешними.

Если вы хотите жёстко запретить некоторые внешние источники, используйте routing rules и настройки безопасности позже, но базовый порядок тоже важен.

Минимальная проверка прав доступа для клиентов

Вы уже создавали пользователя ci-bot и роль в прошлом уроке. Теперь логично расширить подход:

один пользователь для CI с минимальными правами,

раздельные права на read и write,

write только на hosted, read на group.

Быстрая проверка без UI:

Проверить, что read работает:

Проверить, что write запрещён там, где не должен:

Ожидаемое поведение зависит от того, какие привилегии вы выдали роли.

Типовые ошибки и быстрые способы диагностики

Клиенты получают 401 Unauthorized

Частые причины:

anonymous отключён, но клиент не передаёт credentials.

неправильная роль/привилегии на репозиторий.

для Docker не включён Docker Bearer Token Realm.

Что сделать:

Проверьте под пользователем ci-bot доступ к URL через curl -u.

Откройте логи Nexus:

или

Клиенты получают 404 Not Found

Частые причины:

неверный URL (ошибка в имени репозитория).

для NuGet забыли index.json в конце.

для Docker обращаются не на /v2/ endpoint или не на тот порт.

Proxy не скачивает из внешнего источника

Частые причины:

нет выхода в интернет (DNS, firewall).

корпоративный proxy не настроен.

Быстрая проверка с хоста Nexus:

Домашний проект по уроку

Сделайте «минимально полезную» структуру репозиториев под реальную команду и оформите это как результат, который можно передать в эксплуатацию.

Требования к результату:

Создайте репозитории:

- Maven: maven-central (proxy), maven-releases (hosted), maven-snapshots (hosted), maven-public (group) - npm: npm-proxy (proxy), npm-hosted (hosted), npm-group (group) - NuGet: nuget-org (proxy), nuget-hosted (hosted), nuget-group (group) - Docker: docker-hosted, docker-hub, docker-group (с разными портами) - raw: raw-infra

Подготовьте файл Repository-Catalog.md со структурой:

- список репозиториев и их назначение - URL каждого репозитория - какие клиенты должны использовать hosted, а какие group - какие учётные данные используются в CI (без паролей, только ссылки на секрет-хранилище)

Подтвердите работоспособность:

- Maven: запрос к maven-public - npm: npm config get registry и установка любой зависимости через group - NuGet: dotnet nuget list source и restore через group - Docker: curl -I http://<HOST>:<PORT>/v2/ и хотя бы один docker pull через group - raw: upload и download файла через curl

В следующем модуле вы начнёте управлять артефактами глубже: загрузка/выгрузка, cleanup policies, routing rules и более строгие практики эксплуатации.

Артефакты и политики: upload/download, cleanup, routing rules, форматы

После того как вы развернули Nexus Repository OSS 3.x, освоили UI и создали базовые связки репозиториев hosted/proxy/group для Maven, npm, NuGet, Docker и raw, следующий шаг администратора DevOps-уровня — управлять жизненным циклом артефактов.

В этом уроке вы разберёте:

как артефакты представлены в Nexus (component и asset) и как это связано с форматами;

как правильно делать upload/download в зависимости от формата;

как включать и безопасно применять cleanup policies;

как использовать routing rules для контроля того, что можно (и нельзя) брать из proxy-репозиториев.

!Общая картина: как запросы клиентов превращаются в артефакты в blob store и где применяются политики

Что считается готовым результатом

Вы умеете отличать component и asset и находить их в UI и через REST API.

Вы можете выполнить upload и download для каждого формата правильным способом, не ломая метаданные.

Вы настроили как минимум одну cleanup policy, привязали её к репозиториям и запустили задачу очистки.

Вы создали routing rule и применили её к proxy-репозиторию, проверив эффект на практике.

Термины, которые понадобятся в этом уроке

Component — логическая единица пакета в репозитории (например, Maven координаты плюс версия).

Asset — конкретный файл внутри component (например, .jar, .pom, manifest, слой Docker).

Metadata — служебные индексы/описания формата (например, maven-metadata.xml, NuGet index, npm package metadata).

Cleanup policy — правило отбора артефактов к удалению.

Routing rule — правило разрешения или запрета путей, применяемое к запросам в proxy/group.

Если вам нужно освежить базу по репозиториям, вернитесь к предыдущему уроку про hosted/proxy/group.

Как Nexus хранит артефакты и почему это важно для админа

На уровне хранения у Nexus есть два ключевых слоя:

Blob store хранит бинарные данные (файлы).

База метаданных хранит структуру репозиториев, компоненты, ассеты, связи и служебные индексы.

Практический вывод:

Удаление артефакта — это не просто удаление файла, это изменение метаданных и часто фоновые операции.

Cleanup надо делать осознанно, чтобы не удалить нужные версии и не сломать воспроизводимость сборок.

Browse и поиск: быстрый способ понять, что реально лежит в репозитории

В UI обычно есть два «режима» просмотра:

просмотр по дереву репозитория в Browse;

просмотр по компонентам и поиск по координатам.

Практика в UI:

Откройте пользовательскую часть UI (обычно раздел Browse).

Выберите репозиторий maven-public или npm-group.

Найдите любой артефакт, который был скачан через proxy.

Проверьте, как он представлен: в Maven вы увидите группировку по groupId/artifactId/version, в npm — по имени пакета.

Зачем это администратору:

вы видите, что прокси реально закэшировал;

вы можете подтвердить последствия cleanup и routing rules без догадок.

REST API: инвентаризация компонентов и ассетов

Даже если вы предпочитаете UI, REST API полезен для автоматизации и диагностики.

Минимальные зависимости на вашей админ-машине:

Список репозиториев через REST

Список components в конкретном репозитории

Пример для maven-central (proxy) или maven-public (group может не всегда возвращать то, что ожидаете, удобнее опрашивать конкретный hosted/proxy):

Если continuationToken не null, значит есть следующая страница. Запрос следующей страницы выглядит так:

Список assets и скачивание конкретного файла

Получите один asset и его downloadUrl.

Скачайте этот URL.

Практический смысл:

вы можете писать проверки целостности кэша;

вы можете строить отчёты по «что реально скачивают».

Официальная справка по общим возможностям Nexus Repository Manager 3: Nexus Repository Manager 3

Upload и download: правильный способ зависит от формата

Главное правило:

Для форматных репозиториев используйте «родной» клиент (Maven, npm, dotnet/NuGet, Docker).

UI и curl --upload-file используйте только там, где это корректно для формата (raw) или для разовых ручных операций.

raw: upload и download через curl

raw — идеальный формат для тренировок upload/download и проверки прав.

Создайте файл.

Загрузите в raw-infra.

Скачайте.

Проверьте HTTP-метаданные.

Maven: публикация только через Maven (deploy)

Для Maven публикация должна происходить через mvn deploy, чтобы корректно сформировались метаданные и структура.

Минимальная идея настройки:

download идёт через maven-public (group);

publish идёт в maven-releases или maven-snapshots (hosted).

Типовая ошибка:

загрузить .jar через UI или raw-путём и ожидать, что Maven увидит его как артефакт.

npm: публикация через npm CLI

Смысл аналогичный Maven:

download через npm-group;

publish во внутренний npm-hosted.

Для админа важно помнить:

npm активно использует метаданные registry;

ручная загрузка файлов не равна корректной публикации пакета.

NuGet: публикация через dotnet/nuget push

Для NuGet hosted репозитория используются команды dotnet nuget push или nuget push.

Типовой паттерн:

restore через nuget-group;

push в nuget-hosted.

Docker: publish через Docker push, проверка через /v2/

Для Docker вы обычно:

проверяете доступность endpoint через curl -I http://<HOST>:<PORT>/v2/;

делаете docker login и затем docker push/docker pull.

Если при корректных кредах Docker не логинится, первым делом проверьте realm:

Docker Bearer Token Realm должен быть активирован.

Cleanup policies: как удалять безопасно и предсказуемо

Cleanup policy в Nexus — это «условие отбора», какие компоненты можно удалить. Само удаление выполняется отдельной задачей (task), которую вы планируете и запускаете.

Зачем cleanup вообще нужен

Без cleanup Nexus в продакшене почти всегда приходит к одному из сценариев:

заканчивается диск из-за кэша proxy-репозиториев;

растёт время обслуживания и фоновых задач;

пользователи теряют доверие к Nexus из-за деградации производительности.

Риск cleanup: как не сломать сборки

Cleanup ломает сборки тогда, когда удалённая версия ещё нужна.

Практика безопасного внедрения:

Начните с proxy-репозиториев (кэш легче восстановить).

Для hosted держите ретеншн минимум на период, когда релизы ещё реально пересобирают.

Любой cleanup сначала применяйте на стенде или на тестовом репозитории.

Перед агрессивным cleanup зафиксируйте «критичные версии» (например, используемые продом и LTS-ветками).

Практика: создать cleanup policy и привязать к репозиторию

Действия в UI (названия пунктов могут немного отличаться по версии):

Откройте Administration → Repository или Repositories → Cleanup Policies.

Нажмите Create cleanup policy.

Создайте политику для proxy-кэша.

Сохраните политику.

Откройте настройки репозитория maven-central.

В поле cleanup policy выберите созданную политику.

Сохраните.

Практика: запустить задачу cleanup

Откройте Administration → Tasks.

Найдите задачу вида Cleanup repositories using their associated policies.

Запустите вручную.

Откройте результат выполнения и зафиксируйте время и итог.

Как проверить эффект cleanup

Проверка должна быть в двух плоскостях:

функциональная (клиенты продолжают скачивать нужное);

фактическая (артефакты реально удалились).

Минимальный практический план:

До cleanup найдите конкретный компонент в Browse.

Запустите cleanup.

Проверьте, что компонент исчез.

Попробуйте повторно скачать артефакт через proxy и убедитесь, что он подтягивается заново.

Рекомендованные стратегии ретеншна по форматам

Таблица ниже — стартовая точка для обсуждения с командой, а не универсальная истина.

| Формат | Где чаще всего нужен cleanup | Что обычно чистят агрессивнее | Что чистят аккуратно | |---|---|---|---| | maven2 | proxy кэш и snapshots hosted | snapshots старше N дней | releases hosted | | npm | proxy кэш и внутренние prerelease | старые prerelease версии | теги, используемые продом | | nuget | proxy кэш и CI-пакеты | CI-пакеты по возрасту | пакеты, на которые есть зависимости в проде | | docker | proxy кэш, старые теги | непереиспользуемые теги | базовые образы и pinned версии | | raw | технические артефакты | временные файлы CI | аудиторские артефакты, если требуются |

Routing rules: контроль того, что можно скачивать из proxy

Routing rules — это способ ограничить, какие пути разрешены или запрещены при обращении к proxy (а иногда и в контексте group). На практике это используется для:

блокировки нежелательных групп/пакетов;

предотвращения подмены внутренних артефактов внешними;

снижения риска supply chain атак через случайные зависимости.

!Понимание, где именно применяется routing rule и как она влияет на запрос

Практика: создать routing rule и применить к proxy-репозиторию

Пример сценария: вы хотите запретить скачивание части namespace из Maven Central.

Откройте Administration → Routing Rules.

Создайте правило deny-bad-maven.

Выберите тип правила Block.

Добавьте matchers путей (пример идеи): запрет com/badcompany/ и всё внутри.

Сохраните правило.

Откройте репозиторий maven-central (proxy).

Примените routing rule deny-bad-maven.

Сохраните.

Проверка идеи через прямой URL:

Ожидаемое поведение зависит от реализации и версии Nexus, но смысл проверки один:

запрос должен перестать ходить во внешний источник по запрещённому пути.

Практическое правило про routing rules и group

routing rules не заменяют корректный порядок репозиториев в group;

routing rules не заменяют модель доступа и контроль прав;

routing rules удобны как «политика на прокси», когда нужно быстро и централизованно ограничить внешние зависимости.

Удаление артефактов: ручное и автоматизированное

Удаление артефактов бывает двух типов:

ручное точечное удаление (инцидент, ошибочная публикация, компрометация);

плановая политика (cleanup).

Практика: удалить component через REST API

Это полезно, когда вы автоматизируете реакции на инциденты.

Найдите component.

Удалите component по id.

Проверьте, что компонент исчез из выдачи.

Важный админский вывод:

удаление в UI и удаление через REST должны давать одинаково объяснимый результат, который можно подтвердить.

Типовые ошибки и диагностика

Cleanup не удаляет ничего

Частые причины:

cleanup policy создана, но не привязана к репозиторию;

task cleanup не запускался;

условия policy не матчятся на артефакты.

Минимальная диагностика:

Затем проверьте UI-логи выполнения нужной задачи.

После cleanup сломались сборки

Частые причины:

удалили snapshots, которые ещё используются;

удалили release, который не дублируется в другом месте;

сборка не зафиксировала версии и тянет «последнее».

Практическая реакция админа:

временно ослабить cleanup;

восстановить артефакт из внешнего источника (для proxy) или из бэкапа (для hosted);

зафиксировать проблему в правилах публикации и ретеншна.

Routing rule не даёт ожидаемого эффекта

Частые причины:

правило создано, но не применено к репозиторию;

matcher не соответствует реальному пути в формате;

вы проверяете через group, а ограничение ожидаете в proxy (и наоборот).

Практика проверки:

проверяйте прямой URL proxy-репозитория;

смотрите логи запросов и задачи, связанные с проксированием.

Практическая часть: мини-лабораторная на один вечер

Сделайте набор действий в одном окружении, чтобы «руки запомнили» жизненный цикл артефакта.

Через curl загрузите 3 файла в raw-infra в разные пути.

Скачайте их обратно и проверьте HTTP-заголовки.

Создайте cleanup policy, которая удаляет часть этих файлов по выбранному вами критерию.

Привяжите cleanup policy к raw-infra.

Запустите cleanup task вручную.

Подтвердите удаление через UI Browse и через REST assets.

Создайте routing rule, которая запрещает один из путей, и примените её к proxy-репозиторию.

Видео-скрипт урока

Вступление: зачем администратору управлять жизненным циклом артефактов и почему «просто хранить» недостаточно.

Пояснение component и asset на примере Maven и raw.

Демонстрация UI: Browse, поиск, где видно состав артефакта.

Демонстрация REST API: repositories, components, assets, continuationToken.

Практика upload/download для raw через curl.

Объяснение, почему для Maven/npm/NuGet/Docker нужен нативный клиент.

Демонстрация cleanup policy: создание, привязка, запуск task, проверка результата.

Демонстрация routing rule: создание deny-правила, применение к proxy, проверка curl.

Завершение: чеклист безопасного внедрения cleanup и routing rules в прод.

Домашний проект по уроку

Подготовьте артефакт для команды эксплуатации: документ и набор команд, которые можно применять в реальной работе.

Требования к результату:

Создайте файл Artifact-Lifecycle-Runbook.md.

Добавьте раздел Инвентаризация с командами REST API для списка репозиториев, components и assets.

Добавьте раздел Upload/Download с примерами для raw-infra и пояснением, какие форматы нельзя публиковать через curl.

Добавьте раздел Cleanup.

Добавьте раздел Routing rules.

Приложите скриншоты или текстовые подтверждения.

!Что именно нужно показать в отчёте по домашнему проекту

Безопасность и enterprise: RBAC, LDAP/SSO, SSL, Nexus IQ, аудит

После того как вы развернули Nexus Repository 3.x, разобрались с UI, создали репозитории hosted/proxy/group и настроили жизненный цикл артефактов (cleanup policies, routing rules), вы подошли к теме, которая отличает рабочий стенд от production-ready сервиса: безопасность.

В этом уроке вы системно выстроите безопасность Nexus как enterprise-компонента:

RBAC: роли, привилегии, сервисные аккаунты, принцип минимальных прав

LDAP и SSO: централизованная идентификация, маппинг групп на роли

SSL/TLS: защищённый доступ, reverse proxy, особенности Docker registry

Nexus IQ: контроль уязвимостей и policy enforcement (как часть supply chain security)

Аудит: что логировать, где смотреть, как доказать кто и что сделал

!Общая архитектура: где встраиваются RBAC, LDAP/SSO, TLS, IQ и аудит

Результат, который считается готовым

К концу урока у вас должно получиться:

Спроектировать модель доступа: отдельные пользователи для CI, отдельные роли на read и write, отказ от admin в автоматизации.

Подключить LDAP (учебно или в вашей инфраструктуре), выполнить маппинг групп на роли и проверить логин.

Настроить TLS через reverse proxy (рекомендуемый путь) и проверить корректность Base URL.

Понимать, что даёт Nexus IQ, как он интегрируется с Nexus Repository и CI/CD, и где граница OSS/Pro.

Собрать минимальный аудит-рунбук: какие логи смотреть, как найти автора изменения и источник проблем с доступом.

Минимальная модель угроз для Nexus

Nexus обычно становится центральной точкой цепочки поставки артефактов. Это означает, что компрометация Nexus или неверная настройка доступа приводит к последствиям уровня организации, а не одного проекта.

Типовые риски:

Утечка артефактов (внутренние пакеты, контейнеры, бинарники, конфиги)

Подмена артефактов (supply chain атаки через публикацию вредоносных версий)

Деградация сервиса из-за злоупотребления правами (массовые удаления, агрессивные task, отключение репозиториев)

Утечка учётных данных (пароли в CI-логах, токены в репозиториях)

Практический вывод:

Аутентификация должна быть централизованной.

Авторизация должна быть минимальной и управляемой.

Транспорт должен быть защищён TLS.

Должен быть аудит действий и событий.

Официальная документация Nexus Repository Manager 3: Nexus Repository Manager 3 Documentation

RBAC в Nexus: Users, Roles, Privileges, Realms

Как устроена авторизация

В Nexus логика доступа строится так:

Privilege описывает право на действие или ресурс (например, чтение конкретного репозитория).

Role агрегирует привилегии.

User получает доступ через назначенные роли.

Отдельно существуют Realms: они определяют, какие механизмы аутентификации активны (например, Docker token realm, LDAP realm и другие).

Связь с предыдущими уроками:

Вы уже создавали ci-bot и роль nx-ci-readonly.

Здесь вы доведёте это до production-паттерна: разнесёте read и write, минимизируете поверхность доступа, введёте соглашения по неймингу и управлению секретами.

Рекомендованный паттерн ролей для enterprise

Ниже пример стартовой схемы. Она не единственная, но хорошо масштабируется.

| Категория | Пример роли | Что даёт | Кому выдавать | |---|---|---|---| | Read-only (общий) | nx-repo-*-read | чтение group (и при необходимости proxy) | разработчики, CI restore/pull | | Publisher (ограниченный) | nx-repo-*-publish | публикация только в hosted | CI release jobs, package maintainers | | Admin (ограниченный) | nx-admin-limited | доступ к задачам, репозиториям, но не ко всему | команда эксплуатации | | Full admin | встроенный nx-admin | полный контроль | 1–2 человека, break-glass |

Практическое правило:

Клиенты почти всегда должны ходить в group.

Публикация почти всегда должна идти в hosted.

Роль publish не должна давать доступ к админским разделам.

Практика: создать два сервисных пользователя для CI

Сценарий: вы хотите разделить чтение и публикацию.

Создайте пользователей:

1. ci-reader для скачивания (Maven/NuGet/npm/Docker pull). 2. ci-publisher для публикации (Maven deploy, nuget push, npm publish, docker push).

Создайте роли:

1. nx-ci-read. 2. nx-ci-publish.

Привяжите привилегии так, чтобы:

1. nx-ci-read имела доступ только на чтение к нужным group. 2. nx-ci-publish имела write только на hosted (и при необходимости read на group).

Проверьте через curl, что ci-reader не может upload в raw-infra.

Пример проверки запрета upload:

Ожидаемо для корректной RBAC-модели:

Сервер возвращает 401 или 403.

В логах видно отказ по авторизации.

Практика: включить только нужные Realms

В зависимости от ваших репозиториев и протоколов вам нужны разные realms.

Пример обязательного из предыдущего урока:

Docker Bearer Token Realm для корректного docker login.

Рекомендация:

Включайте только то, что реально используете.

Любой включённый realm увеличивает сложность диагностики и поверхность атаки.

LDAP: централизованная аутентификация и группы

LDAP (и особенно AD) — стандартный способ централизованно управлять пользователями и группами.

Что вы получаете:

Единые учётные данные (увольнения и смена паролей происходят централизованно)

Возможность маппить LDAP-группы на роли Nexus

Снижение риска “локальных” аккаунтов, забытых после ухода сотрудников

Рекомендованный подход

Локальные пользователи:

1. Оставить только admin как break-glass. 2. Сервисных пользователей для CI держать локально или тоже увести в LDAP, зависит от политики.

Пользователей людей аутентифицировать через LDAP.

Авторизацию делать через роли Nexus, назначаемые по LDAP-группам.

Практика: поднять учебный LDAP в Docker (опционально)

Если у вас нет готового LDAP, вы можете развернуть тестовый. Это только для лаборатории.

Дальше вы сможете создать пользователей и группы в UI phpLDAPadmin и проверить интеграцию Nexus.

Практика: подключить LDAP в Nexus

Путь в UI зависит от версии, но логика одинаковая:

Откройте настройки LDAP в разделе Security.

Добавьте LDAP server.

Укажите параметры:

- Host: ldap://<LDAP_HOST>:389 или ldaps://...:636 - Base DN: например dc=dev,dc=local - Bind DN: например cn=admin,dc=dev,dc=local - Bind password

Настройте поиск пользователей и групп (User subtree, Group subtree).

Выполните test connection и test user mapping.

Критичные enterprise-заметки:

Если есть возможность, используйте LDAPS или LDAP с StartTLS, чтобы не передавать пароли в открытом виде.

Уточните в вашей организации схему групп и атрибутов (например, memberOf, uid, sAMAccountName).

Маппинг LDAP-групп на роли Nexus

В production удобнее всего:

создать роли Nexus nx-dev-read, nx-dev-publish, nx-ops-admin;

настроить сопоставление LDAP-групп этим ролям.

Практическая проверка:

Войти под LDAP-пользователем.

Убедиться, что в UI доступны только те разделы, которые положены.

Попробовать выполнить действие “выше прав” и получить отказ.

SSO: SAML или OIDC (обычно enterprise и чаще в Pro)

SSO означает, что Nexus доверяет внешнему Identity Provider (IdP): Keycloak, Okta, Azure AD, ADFS и т.д.

Варианты:

SAML 2.0: часто используется в корпоративных IdP.

OpenID Connect (OIDC): современный вариант на базе OAuth 2.0.

Что важно понимать администратору:

Nexus выступает как Service Provider (SAML) или Relying Party (OIDC).

IdP выдаёт identity и claims, а Nexus сопоставляет их с ролями.

Основа безопасности SSO — корректный TLS и корректный Base URL.

Практический вывод:

Если Base URL неправильный, редиректы и callback URL ломаются.

Если TLS сделан “как попало”, пользователи получают ошибки доверия и вы теряете контроль над входом.

Если вы внедряете IdP, держите под рукой документацию вашей платформы. Для Keycloak полезно начать с официального руководства: Keycloak Documentation

SSL/TLS: защищаем транспорт правильно

Почему TLS нужен всегда

Без TLS у вас возникают сразу несколько проблем:

Basic Auth (и любые токены) могут быть перехвачены.

Docker registry и некоторые клиенты ведут себя нестабильно без доверенного сертификата.

SSO почти всегда требует корректного HTTPS.

Два подхода к TLS

| Подход | Идея | Плюсы | Минусы | |---|---|---|---| | Reverse proxy (рекомендуется) | TLS терминируется на Nginx/HAProxy, внутрь Nexus можно оставить HTTP | проще сертификаты, проще WAF, проще логи | нужна настройка прокси и заголовков | | TLS внутри Nexus | Nexus сам слушает HTTPS | меньше компонентов | сложнее управлять сертификатами и интеграциями, часто неудобно в enterprise |

Далее мы сделаем recommended-путь: reverse proxy на Nginx.

Официальная документация Nginx по проксированию: Nginx ngx_http_proxy_module

Практика: self-signed сертификат для лаборатории

Для тестов можно сделать self-signed.

В production вместо этого обычно используют корпоративный PKI или Let’s Encrypt.

Документация Certbot: Certbot Documentation

Практика: Nginx reverse proxy для Nexus UI

Установите Nginx.

Создайте конфигурацию сайта, например /etc/nginx/sites-available/nexus.

Активируйте сайт.

Проверьте доступ:

В лаборатории -k отключает проверку доверия сертификату. В production -k быть не должно.

Обязательная часть: Base URL

После появления reverse proxy в Nexus должен быть корректный Base URL вида https://nexus.dev.local/. Это влияет на:

ссылки и редиректы

некоторые интеграции и токены

SSO callback URL

Проверьте Base URL в системных настройках Nexus и приведите к внешнему адресу через proxy.

Особенности Docker registry под TLS

Если вы поднимаете Docker hosted/proxy/group на отдельных портах (как в предыдущем уроке), то в enterprise чаще делают так:

внешний адрес registry.company.tld через reverse proxy

внутри прокси маршрутизирует на нужный порт Nexus Docker endpoint

Ключевые моменты:

Docker требует доверенный сертификат на имени registry.

Самоподписанный сертификат потребует установки в trust store Docker на клиентах.

Nexus IQ: уязвимости, политики и контроль supply chain

Nexus IQ Server — отдельный продукт Sonatype, который анализирует зависимости и артефакты на уязвимости и нарушения политик.

Что даёт в DevOps-практике:

отчёты по CVE и risk scoring

политика: запретить сборку при критических уязвимостях

интеграции с CI (Jenkins, GitLab CI через скрипты)

контроль компонентов, скачиваемых через репозитории

Важно про границы:

Nexus Repository OSS сам по себе не заменяет IQ.

В enterprise обычно используют связку Nexus Repository Pro плюс IQ, но архитектурно IQ может работать и как внешняя проверка в CI.

Официальная документация IQ: Nexus IQ Server Documentation

Практический сценарий интеграции с CI

CI собирает приложение.

Перед публикацией артефакта запускается policy evaluation через IQ.

Если политика нарушена, публикация блокируется.

Практический результат для эксплуатации:

вы уменьшаете вероятность, что уязвимый компонент попадёт в hosted репозиторий и будет “легализован” как внутренний.

Аудит: как понять, кто и что сделал

Аудит в Nexus для администратора — это не один файл, а совокупность источников:

логи приложения

логи запросов (кто скачивал и откуда)

логи аутентификации и авторизации

история выполнения задач (Tasks)

изменения конфигурации (в зависимости от версии и редакции)

Где искать логи

Пути зависят от способа установки.

Docker:

1. смотреть поток логов контейнера 2. внутри volume искать log/ директорию

systemd:

1. journalctl -u nexus 2. директория логов в work directory

Практика для Docker:

Практика для systemd:

Практика: найти файлы логов в work directory:

Типовые лог-сценарии, которые должен уметь разбирать админ

Пользователь жалуется: “не могу скачать пакет”

1. проверить 401 и 403 в логах 2. проверить роли и привилегии пользователя 3. проверить, не отключён ли репозиторий (online/offline)

CI жалуется: “docker login не работает”

1. проверить, включён ли Docker Bearer Token Realm 2. проверить TLS и корректность имени registry

“пропали артефакты”

1. проверить запуск cleanup task 2. проверить applied cleanup policies 3. проверить, не было ручного удаления components

Минимальный аудит-рунбук

Сделайте привычку: при любом инциденте фиксируйте одно и то же.

Время события и часовой пояс.

Кто выполнял операцию (логин).

Какой endpoint или репозиторий затронут.

Что изменилось (репозиторий offline, роль изменена, policy применена).

Где подтверждение:

1. строка(и) в логах 2. скрин UI (если нужно) 3. REST-запрос, который подтверждает состояние

Практическая часть: “поднять планку безопасности” на вашем стенде

Сделайте набор изменений в вашем Nexus из предыдущих уроков.

Отключите anonymous access, если он ещё включён.

Создайте ci-reader и ci-publisher и разнесите права.

Включите только нужные realms (Docker realm обязателен, если есть Docker repos).

Подключите LDAP (реальный или тестовый) и проверьте вход LDAP-пользователя.

Поставьте Nginx reverse proxy и включите TLS.

Убедитесь, что Base URL соответствует внешнему https://....

Соберите в один документ команды диагностики и источники логов.

Видео-скрипт урока

Вступление: почему Nexus — критическая точка supply chain.

RBAC: разница между privilege и role, почему admin нельзя в CI.

Практика: создаём ci-reader и ci-publisher, проверяем 403 на upload.

LDAP: что даёт централизованная аутентификация, показываем test mapping.

SSO: что такое SAML/OIDC, где ломается при неправильном Base URL.

TLS: делаем Nginx reverse proxy, обсуждаем Docker registry нюансы.

Nexus IQ: что это, где место в цепочке CI/CD, какие решения принимает.

Аудит: где логи, как расследовать 401/403, где смотреть последствия cleanup.

Завершение: чеклист “production minimum”.

Домашний проект по уроку

Сделайте enterprise security baseline для вашего стенда и оформите как документ, который можно отдать в эксплуатацию.

Требования:

Создайте файл Security-Baseline-Runbook.md.

Опишите модель доступа:

1. список сервисных аккаунтов (ci-reader, ci-publisher) 2. роли и их назначение 3. какие репозитории доступны на read и на write

Опишите аутентификацию:

1. локальные пользователи (кто и зачем) 2. LDAP-источник и принцип маппинга групп 3. какие realms включены и почему

Опишите TLS:

1. выбранный подход (reverse proxy) 2. где лежат сертификаты 3. как проверять доступность (curl -I)

Опишите аудит:

1. где смотреть логи (Docker/systemd) 2. какие ключевые сценарии расследования вы покрываете (401/403, docker login, удаление артефактов)

Скриншоты UI допускаются, но минимально достаточный результат должен быть воспроизводим по тексту и командам.

CI/CD и проксирование: Jenkins/GitLab, mirroring, cache, настройки клиентов

Nexus Repository в DevOps почти всегда выполняет две роли одновременно:

Источник правды для внутренних артефактов (hosted)

Корпоративный cache/mirror для внешних источников (proxy), чтобы сборки были быстрее, стабильнее и воспроизводимее

В предыдущих уроках вы:

установили Nexus и научились ориентироваться в UI

создали репозитории hosted/proxy/group для Maven, npm, NuGet, Docker, raw

настроили базовые политики артефактов: cleanup policies и routing rules

выстроили security baseline: RBAC, LDAP, TLS через reverse proxy

Теперь вы связываете Nexus с реальными пайплайнами Jenkins и GitLab CI, настраиваете клиентов (Maven, npm, NuGet, Docker) так, чтобы они ходили только в Nexus group, и разбираете, как работает mirroring и cache в прокси-репозиториях Nexus.

!Архитектура: как CI и разработчики должны ходить в Nexus

Результат, который считается готовым

К концу урока у вас должно получиться:

Подключить Maven, npm, NuGet и Docker клиенты так, чтобы они использовали group репозитории Nexus.

Настроить Jenkins Pipeline и GitLab CI для:

- скачивания зависимостей через Nexus (proxy cache) - публикации артефактов в hosted (release/publish)

Понимать ключевые настройки proxy-репозиториев: cache TTL, negative cache, remote timeout, outbound proxy.

Уметь быстро диагностировать типовые проблемы интеграций: 401/403, проблемы Docker token flow, ошибки проксирования наружу.

Термины, которые используются в уроке

Mirror — когда клиент настроен брать зависимости не из оригинального публичного источника, а из корпоративного endpoint (обычно group в Nexus).

Cache — Nexus сохраняет скачанные артефакты из внешнего источника локально (blob store), ускоряя повторные сборки.

Negative cache — Nexus кэширует факт отсутствия артефакта на внешнем источнике, чтобы не «долбить» remote при каждой сборке.

Hosted — репозиторий для ваших публикаций.

Proxy — репозиторий для проксирования внешних источников.

Group — единая точка входа для клиентов.

Service account — технический пользователь (например, ci-reader, ci-publisher) с минимально необходимыми правами.

Практический дизайн: один URL на формат

Цель эксплуатации — чтобы у команды было минимум точек конфигурации.

Рекомендуемый паттерн:

Maven: использовать maven-public для скачивания, maven-releases и maven-snapshots для публикации

npm: использовать npm-group для установки, npm-hosted для публикации

NuGet: использовать nuget-group для restore, nuget-hosted для push

Docker: использовать docker-group для pull и (опционально) для push, но чаще push направляют в docker-hosted через отдельный endpoint

Важно согласовать с security из прошлого урока:

ci-reader имеет только read доступ к group

ci-publisher имеет write доступ только к hosted (и при необходимости read к group)

admin не используется в CI

Настройка proxy cache в Nexus: что реально важно

Настройки proxy-репозиториев в UI могут отличаться по версии, но концептуально в Nexus важны одни и те же параметры.

Какие настройки proxy влияют на сборки

Remote storage — внешний источник (например, Maven Central)

Content max age и Metadata max age — TTL кэша контента и метаданных

Negative cache — как долго кэшировать отсутствие артефакта

HTTP request settings — timeouts, retries, user-agent, иногда — заголовки

Практический смысл:

слишком маленький TTL метаданных увеличит нагрузку и задержки

слишком большой TTL может мешать быстро подхватывать обновления (особенно для метаданных)

negative cache спасает внешний канал и ускоряет сборки, когда зависимости «битые» или ошибочно указаны

Практика: проверить, что proxy реально кэширует

Сценарий: убедиться, что maven-central (proxy) кэширует зависимости.

На машине с Maven выполните скачивание типовой зависимости через group (пример ниже).

В UI откройте Browse и найдите появившийся артефакт в proxy.

Повторите команду и сравните время выполнения.

Если у вас включены логи запросов, вы должны увидеть, что второй раз обращения наружу существенно меньше.

Outbound proxy для Nexus (если у вас корпоративная сеть)

Если у сервера Nexus нет прямого доступа к интернету, но доступ возможен через корпоративный HTTP proxy, настройте outbound proxy в системных настройках.

Действия в UI обычно находятся в Administration → System → HTTP.

Проверка с хоста Nexus (важно делать именно с сервера Nexus):

Если curl с сервера не ходит наружу, то и Nexus proxy не сможет кэшировать.

Maven: настройки клиента и CI

Рекомендуемая схема

Скачивание: через maven-public (group)

Публикация: в maven-releases и maven-snapshots (hosted)

Справка по settings.xml: Apache Maven Settings Reference

Практика: минимальный settings.xml для mirror

Создайте файл settings.xml в репозитории проекта (для CI это удобнее, чем править ~/.m2):

Пояснение:

mirrorOf со значением * означает, что Maven будет пытаться брать зависимости через Nexus

блок servers привязывает логины к id

переменные окружения удобно использовать в CI, чтобы не хранить пароли в репозитории

Практика: Jenkins Pipeline для Maven (restore через group)

Ниже пример, как использовать credentials в Jenkins.

Справка по withCredentials: Jenkins Credentials Binding Plugin

Замечания:

-U заставляет Maven проверять обновления снапшотов и метаданных, но не отменяет кэширование Nexus

-B включает batch mode, полезно для CI

Практика: GitLab CI для Maven

Справка по переменным GitLab CI: GitLab CI/CD Variables

Пример .gitlab-ci.yml:

Рекомендация:

NEXUS_READER_USER и NEXUS_READER_PASS задавайте как masked variables в настройках проекта/группы GitLab

npm: настройки клиента и CI

Справка по настройке registry: npm config

Практика: .npmrc для работы через Nexus group

В репозитории проекта создайте .npmrc:

Аутентификация зависит от вашей модели доступа.

Минимально-практичный вариант для CI в режиме basic auth:

выполнить npm login --registry=... в job

или хранить auth в переменных CI и генерировать .npmrc на лету

Пример генерации .npmrc в CI (basic auth):

Далее логин:

Практика: GitLab CI для npm (install через Nexus)

Замечания:

npm ci лучше воспроизводим для CI, чем npm install

если вы отключили anonymous (как рекомендовано ранее), заранее продумайте, как CI будет аутентифицироваться

NuGet: настройки клиента и CI

Справка по источникам NuGet: dotnet nuget add source

Практика: добавить source на Nexus group

Пояснение:

суффикс index.json для NuGet v3 обязателен

--store-password-in-clear-text часто нужен на Linux в headless окружении

Практика: GitLab CI для .NET restore через Nexus

Docker: pull/push через Nexus и нюансы авторизации

Справка по docker login: Docker CLI reference: docker login

Обязательное условие: Docker token flow

Для Docker репозиториев в Nexus почти всегда нужно включить realm:

Administration → Security → Realms → Docker Bearer Token Realm

Если realm не включён, типичный симптом:

docker login возвращает ошибку авторизации даже при корректном логине/пароле

Практика: health-check Docker endpoint

Проверка, что endpoint жив (часто будет 401, и это нормально):

Если у вас Docker endpoint за reverse proxy на стандартном 443, проверяйте https://registry.company.tld/v2/.

Практика: логин и pull через group

Практика: push (публикация) в hosted

Замечания:

в production лучше избегать HTTP Docker registry, используйте TLS (вы уже делали reverse proxy в уроке про безопасность)

если используется self-signed сертификат, клиентам Docker нужно добавить сертификат в trust store, иначе будет ошибка доверия

Mirroring как политика: как заставить команды ходить только через Nexus

Технически можно настроить клиентов на Nexus, но в enterprise важнее сделать это системно.

Рекомендуемая комбинация:

Maven: mirrorOf=* в корпоративном settings.xml

npm: корпоративный шаблон .npmrc и запрет прямого выхода в интернет на рабочих агентах

NuGet: NuGet.Config или команды dotnet nuget в bootstrap скрипте

Docker: либо корпоративный registry DNS, либо policy на уровне инфраструктуры

Дополнительный уровень контроля (из предыдущего урока):

routing rules на proxy (например, запрет определённых namespaces)

строгий RBAC (чтение только через group, публикация только в hosted)

Диагностика интеграций CI/CD: быстрый runbook

Ошибки 401 Unauthorized и 403 Forbidden

Проверить, что anonymous действительно отключён или включён согласно ожиданиям.

Проверить роли пользователя ci-reader и ci-publisher.

Проверить, что CI не использует admin и не «путает» учётки.

Для Docker проверить Docker Bearer Token Realm.

Минимальная проверка прав без UI:

Ошибки проксирования наружу

Проверить сетевой доступ с сервера Nexus.

Проверить outbound proxy настройки Nexus.

Проверить DNS.

Ошибки 404 Not Found

Частые причины:

неверный URL репозитория

для NuGet забыли index.json

для Docker проверяют не /v2/ или не тот порт

Где смотреть логи

Вы уже фиксировали это в прошлых уроках, здесь важно применять привычку.

Docker:

systemd:

Практика: собрать минимальный корпоративный bootstrap для CI

Сделайте один скрипт ci-bootstrap.sh, который на CI-агенте:

Проверяет доступность Nexus status endpoint.

Генерирует settings.xml для Maven.

Настраивает npm registry.

Добавляет nuget source.

Делает docker login (если нужно).

Пример каркаса:

Справка по REST status endpoint вы уже использовали в уроке про UI.

Видео-скрипт урока

Вступление: почему Nexus в CI/CD — это mirror и cache одновременно.

Дизайн: один URL на формат, почему всем выдаём group.

Proxy cache: какие настройки влияют на сборки (TTL, negative cache, timeouts).

Maven: settings.xml, mirror, servers, переменные окружения.

Jenkins: пример pipeline с withCredentials.

GitLab CI: пример .gitlab-ci.yml, переменные, masked secrets.

npm: .npmrc, registry, аутентификация.

NuGet: dotnet nuget add source, нюансы index.json.

Docker: /v2/ health-check, Docker Bearer Token Realm, pull/push в hosted.

Диагностика: 401/403, 404, проблемы выхода в интернет.

Завершение: формируем bootstrap и готовим домашний проект.

Домашний проект по уроку

Соберите полноценную интеграцию Nexus с одним CI инструментом на выбор: Jenkins или GitLab CI.

Требования к результату:

Создайте документ CICD-Nexus-Integration-Runbook.md.

Опишите вашу модель доступа:

- какие service accounts используются (ci-reader, ci-publisher) - какие репозитории используются для read (group) и write (hosted)

Добавьте конфиги клиентов:

- Maven: settings.xml с mirror - npm: .npmrc или команды настройки - NuGet: команда dotnet nuget add source или NuGet.Config - Docker: команды docker login и endpoint(ы)

Добавьте минимум один рабочий pipeline:

- Build job, который тянет зависимости через Nexus (докажите кэш: повторный прогон быстрее или есть подтверждение в Browse) - Publish job (если вы готовы): публикация в hosted (Maven deploy, npm publish, nuget push или docker push)

Добавьте раздел Troubleshooting:

- команды curl для проверки доступности - где смотреть логи Nexus - типовые причины 401/403 и что проверять первым

Результат должен быть воспроизводимым по тексту и командам без ручного «кликания наугад».

Надёжность и масштаб: мониторинг, Tasks, БД, HA, S3 blob stores, проекты

Nexus Repository в реальном DevOps-ландшафте быстро перестаёт быть просто удобным UI для пакетов. Он становится критической точкой цепочки поставки: если Nexus деградирует или недоступен, останавливаются сборки, деплой, выпуск релизов, работа разработчиков.

В предыдущих уроках вы:

развернули Nexus и научились базовой диагностике (логи, status endpoint)

освоили UI и модель RBAC

создали репозитории hosted/proxy/group под Maven, npm, NuGet, Docker, raw

настроили базовые политики артефактов (cleanup, routing rules)

подключили CI/CD и проксирование

В этом уроке вы переходите от функциональности к эксплуатации: мониторинг, фоновые задачи, хранилище и база метаданных, масштабирование, а также enterprise-опции HA и объектные blob stores.

!Архитектура Nexus как центра артефактов и кэша

Результат, который считается готовым

Вы понимаете, что мониторить в Nexus и на хосте, и умеете собрать минимальный набор сигналов для алертов.

Вы умеете проектировать и планировать Tasks так, чтобы они не убивали производительность и не приводили к внезапным потерям артефактов.

Вы понимаете разделение на метаданные и бинарные данные и умеете объяснить, почему это важно для бэкапов, миграций и восстановления.

Вы знаете границы возможностей OSS и что меняется в Pro: внешняя БД, S3 blob stores, HA.

У вас есть практический runbook надёжности: как проверить здоровье, как расследовать деградацию, как безопасно делать обслуживание.

Ключевые понятия урока

Monitoring: наблюдаемость сервиса через метрики, логи и проверки доступности.

Tasks: встроенный планировщик Nexus для обслуживания репозиториев и хранилища.

Metadata database: база, где Nexus хранит структуру репозиториев, компоненты, ассеты, связи и служебные данные.

Blob store: слой хранения бинарных данных артефактов.

Scale up: вертикальное масштабирование одной ноды (CPU/RAM/диск).

HA: кластер высокой доступности (обычно enterprise-функция).

S3 blob store: объектное хранилище для blob store (обычно enterprise-функция).

Справка по продукту: Nexus Repository Manager 3 Documentation

Надёжность как набор слоёв

Надёжность Nexus почти всегда определяется самым слабым слоем:

сеть и DNS

диск и файловая система

ресурсы JVM (RAM, CPU, GC)

база метаданных

blob store

фоновые Tasks

внешние источники (для proxy)

Практическая привычка эксплуатации:

сначала стабилизируйте ресурсы и хранение

затем выстроите Tasks и политики

затем добавляйте масштабирование и enterprise-функции

Мониторинг: что проверять и где брать сигналы

Базовые проверки доступности

У вас уже есть два полезных REST endpoint из прошлых уроков:

GET /service/rest/v1/status

GET /service/rest/v1/status/check

Практика: готовая команда для uptime-проверки (под мониторинг или healthcheck):

Рекомендации:

делайте проверку под отдельным read-only пользователем

если Nexus за reverse proxy, проверяйте именно внешний URL

Минимальный набор метрик на прод

Если вы строите мониторинг, разделите сигналы на три группы.

Сигналы уровня сервиса Nexus:

1. доступность HTTP 2. время ответа на /status/check 3. рост количества 4xx/5xx в reverse proxy (если он есть) 4. частые 401/403 как индикатор проблем с RBAC, токенами, realm

Сигналы уровня JVM и процесса:

1. использование heap 2. частота и длительность GC пауз 3. количество потоков 4. частые рестарты процесса

Сигналы уровня хоста и диска:

1. свободное место (особенно там, где blob store) 2. IOPS и latency диска 3. нагрузка CPU 4. memory pressure и swap

Практическое правило:

если Nexus внезапно стал медленным, чаще всего это диск или память, а не “сломался UI”

Практика: минимальная диагностика с хоста Nexus

Команды, которые стоит держать в runbook.

Проверить порты:

Проверить, что процесс жив (в зависимости от установки):

или:

Проверить диск и inode:

Быстро оценить нагрузку:

Найти “тяжёлые” операции в логах (под вашу схему запуска):

или:

Экспорт JVM-метрик в Prometheus через JMX exporter

Nexus работает на JVM, поэтому один из самых универсальных способов получать метрики JVM и GC это JMX.

Подход:

вы поднимаете Java Agent или отдельный exporter

Prometheus собирает метрики

Grafana визуализирует

Справка по JMX exporter: Prometheus JMX Exporter

Важно:

не открывайте JMX наружу без защиты

мониторинг JVM полезен только вместе с метриками диска и HTTP

Tasks: как планировать обслуживание без самоубийства

Tasks в Nexus это обязательная часть эксплуатации. На небольшом стенде они почти незаметны, а на проде они могут:

стабилизировать систему (cleanup, перестройки)

или “положить” её (если запущены одновременно и в неправильное время)

Классификация Tasks по риску

Ниже практическая классификация, чтобы вы заранее понимали, что можно запускать днём, а что только в окно.

| Класс | Что это обычно | Риск | Типовой ресурсный профиль | |---|---|---|---| | Лёгкие | обновления служебных данных, мелкие проверки | низкий | мало CPU, мало диска | | Уборки | cleanup, удаление старых компонентов | средний | много диска, иногда CPU | | Перестройки | rebuild, reindex, пересчёт browse данных | средний/высокий | CPU + диск | | Repair/maintenance | операции восстановления консистентности | высокий | непредсказуемо, требует окна и бэкапа |

Практическое правило:

не запускайте одновременно несколько тяжёлых задач на большом объёме данных

Практика: “политика расписаний” для прод

Соберите расписание, которое вы сможете объяснить команде.

Cleanup proxy-репозиториев:

1. ночью или в “тихие часы” 2. регулярно, иначе диск будет заканчиваться рывками

Cleanup hosted:

1. только после согласования ретеншна 2. желательно после внедрения практики “версии не теряем без причины”

Перестройки и repair:

1. в окно обслуживания 2. только после проверки свободного места 3. желательно после свежего бэкапа

Практика: быстро найти самые тяжёлые Tasks

В UI:

Administration → Tasks

Что фиксировать в эксплуатационном документе:

какие задачи существуют

какие включены по расписанию

какие запускаются только вручную

где смотреть результат и лог выполнения

Метаданные и blob store: что вы реально бэкапите

Одна из самых частых ошибок эксплуатации: бэкапят только “файлы” или только “БД”, а затем удивляются, что восстановление не даёт рабочий Nexus.

Модель данных Nexus

Nexus хранит данные в двух больших частях:

metadata database: описания репозиториев, пользователей, компонентов, ассетов, связей

blob store: бинарные данные артефактов

!Почему нужно думать о базе метаданных и blob store отдельно

Практические последствия:

при росте производительности основным узким местом становится дисковая подсистема blob store

при “странных” ошибках поиска, browse и состава репозиториев часто виноваты метаданные и фоновые операции

Где лежат данные

Это зависит от установки:

Docker: обычно всё критичное внутри volume /nexus-data

systemd: обычно work directory вида /opt/sonatype-work/nexus3

Рекомендации:

располагайте work directory и blob store на диске с достаточными IOPS

для прод избегайте медленных сетевых дисков без гарантий latency

База метаданных: что важно знать администратору

Исторически Nexus Repository 3 использовал встроенную БД, и детали зависят от версии и редакции. Для практической эксплуатации важны не названия движков, а принципы.

Принципы эксплуатации метаданных

метаданные зависят от корректного завершения операций Tasks и фоновых процессов

метаданные чувствительны к внезапным выключениям, нехватке места и повреждениям ФС

проблемы метаданных обычно проявляются как:

- “в UI не видно то, что есть на диске” - “поиск не находит компонент” - “ошибки при публикации или скачивании при видимых файлах”

Практика: что делать при подозрении на проблемы метаданных

Сначала стабилизировать хост:

1. проверить место на диске 2. проверить, что нет OOM 3. проверить, что Nexus не уходит в рестарты

Затем посмотреть на Tasks:

1. не падают ли задачи обслуживания 2. нет ли бесконечно идущих тяжёлых задач

Затем действовать по runbook вашей версии:

1. использовать поддерживаемые repair-задачи 2. избегать “ручных удалений” из каталога blob store

Официальная точка входа в документацию: Nexus Repository Manager 3 Documentation

Масштабирование: что реально работает в Nexus

Вертикальное масштабирование

Это первый и самый частый шаг.

увеличить RAM под JVM

дать больше CPU

поставить быстрый диск и отделить данные от ОС

Практический порядок действий при росте нагрузки:

измерьте: что упирается в потолок (диск, CPU, heap)

оптимизируйте самое узкое место

только потом обсуждайте сложные архитектуры

Горизонтальное масштабирование

Горизонтальное масштабирование в Nexus обычно означает HA кластер, и это чаще всего относится к enterprise-возможностям.

Нужно честно разделять:

OSS: обычно один узел, высокая надёжность достигается резервированием, бэкапами, быстрым восстановлением

Pro: возможно построение кластера HA при соблюдении требований продукта

HA: что меняется в архитектуре

HA как цель означает:

отказ одной ноды не должен останавливать работу клиентов

обновления и обслуживание должны проходить без длительных простоев

Типовая high-level архитектура:

несколько Nexus нод

балансировщик перед ними

общее хранилище blob store (часто объектное)

общая база метаданных (внешняя, в зависимости от редакции)

!Концептуальная схема Nexus HA

Практические рекомендации, которые полезны даже если вы пока в OSS:

избегайте “ручных” изменений на проде, всё фиксируйте как конфигурацию

готовьте процедуры обновления и отката

документируйте зависимости: DNS, TLS, outbound proxy

S3 blob stores и объектное хранилище

Object storage как blob store полезен, когда:

объём артефактов большой и растёт непредсказуемо

вы хотите снизить зависимость от локального диска на каждой ноде

вы строите HA и вам нужно общее хранилище

Важно:

возможности S3 blob store зависят от редакции и лицензирования

объектное хранилище не отменяет требований к сети и latency

Практика: требования к S3-уровню (как чеклист)

Доступность и сеть:

1. стабильный канал до endpoint 2. предсказуемая latency

Безопасность:

1. отдельный bucket 2. отдельный IAM role/user с минимальными правами 3. server-side encryption

Эксплуатация:

1. lifecycle policy на уровне bucket по согласованным правилам 2. наблюдаемость ошибок доступа и throttling

Справка по S3: Amazon S3 User Guide

Практика: собрать runbook надёжности для вашего стенда

Сделайте один документ и доведите его до состояния, когда другой инженер сможет дежурить по Nexus.

Рекомендуемая структура runbook:

Быстрая проверка здоровья:

1. curl на /service/rest/v1/status/check 2. проверка доступности основных repo endpoint

Где смотреть логи:

1. Docker или systemd 2. как быстро собрать последние 200 строк

Диск и хранение:

1. где лежит work directory 2. как проверить место и inode

Tasks:

1. список тяжёлых задач 2. расписание 3. правила запуска repair

Инциденты:

1. “401/403” 2. “закончился диск” 3. “сборки стали медленными” 4. “docker login сломан”

Практические проекты уровня production

В этом уроке проекты нужны не как “лаба”, а как способ собрать боевую эксплуатационную конфигурацию.

Выберите один из проектов.

Проект A: Monitoring-first

Проект B: Task hygiene

Проект C: Scale-up readiness

Проект D: Enterprise design (теоретический)

Проект A: Monitoring-first

Цель: минимальный мониторинг, который реально поймает 80% проблем.

Результат:

отдельная проверка /status/check

сбор метрик диска и памяти на хосте

дашборд или хотя бы текстовый отчёт “что смотрим и почему”

Проект B: Task hygiene

Цель: превратить Tasks из “непонятных кнопок” в управляемое обслуживание.

Результат:

список всех задач

маркировка по риску

расписание и правила ручного запуска

доказательство, что cleanup работает и не ломает сборки

Проект C: Scale-up readiness

Цель: подготовиться к росту нагрузки без HA.

Результат:

перенос данных на отдельный диск или раздел

измерение места до и после проксирования нескольких форматов

план ретеншна и cleanup на 3 месяца вперёд

Проект D: Enterprise design (теоретический)

Цель: спроектировать HA и S3 blob store на бумаге, не внедряя.

Результат:

схема компонентов (LB, nodes, database, blob store)

список требований к сети, TLS, DNS

список рисков и план внедрения по этапам

Видео-скрипт урока

Вступление: почему Nexus падает “не из-за Nexus”, а из-за диска, задач и хранения.

Monitoring: что проверять через /status/check, почему важно время ответа.

JVM и хост: какие сигналы смотреть в первую очередь.

Tasks: классификация по риску, как делать расписание.

Данные: метаданные против blob store, почему нельзя “удалить файлы руками”.

Масштабирование: вертикально как первый шаг, затем enterprise-архитектуры.

HA и S3: концепции и требования, где границы OSS/Pro.

Завершение: собираем runbook и выбираем практический проект.

Домашний проект по уроку

Сделайте файл Reliability-Scaling-Runbook.md и приложите к нему подтверждения (логи, команды, скриншоты по необходимости).

Требования:

Раздел Monitoring:

1. команды curl для /status и /status/check 2. какие хостовые метрики вы будете мониторить и почему

Раздел Tasks:

1. список задач, которые есть в вашей инсталляции 2. какие вы считаете тяжёлыми и почему 3. ваше расписание cleanup

Раздел Storage:

1. где лежат данные Nexus в вашей установке 2. как вы проверяете место и inode

Раздел Scale plan:

1. что вы будете делать при росте нагрузки в 2 раза 2. что будет вашим первым ограничением (диск, RAM, сеть) и как вы это проверите

Раздел Enterprise awareness:

1. какие части HA и S3 blob store относятся к enterprise-возможностям 2. как бы вы спроектировали HA на уровне компонентов

Этот документ станет основой для следующих экспертных модулей: troubleshooting, миграции, backup и high-load эксплуатация.