что такое nexus репозиторий

Как создать APT репозиторий в Sonatype Nexus 3?

Авторизуйтесь

Как создать APT репозиторий в Sonatype Nexus 3?

Что такое Sonatype Nexus 3?

Sonatype Nexus 3 — это свободно распространяемый менеджер репозиториев, с удобным web-интерфейсом. Менеджер позволяет создавать репозитории, как для хранения конкретных форматов данных (yum, apt, Maven, Docker, npm, PyPl и так далее), так и формат хранения файлов Raw, в котором можно хранить любые типы файлов.

Менеджер репозиториев можно установить, как на обычную физическую или виртуальную машину, так и развернуть в docker-контейнере. Я разворачивал Nexus в docker-контейнере, поэтому буду описывать, как поднять APT репозиторий именно в docker. Доступные docker-образы Sonatype Nexus 3 можно найти по этой ссылке.

Установка зависимостей

Первое что нужно сделать, это подключиться к docker-контейнеру с оболочкой bash:

После этого нужно установить пакет pinentry, для того, чтобы можно было дальше сгенерировать ключи для apt репозитория:

Генерация ключей

После установки пакета pinentry, можно приступать к созданию ключей:

Заполняем поля, вводим O и нажимаем Enter. Далее нужно будет ввести 2 раза пароль, для генерации ключа. Копируем ID, который был сгенерирован 6C44AA9D06EA1B2E805C90FF6935F7FB57FFEF6F. Создаём открытый ключ:

Создаём закрытый ключ:

Здесь нужно будет ввести пароль, который вводили при генерации ID.

Выводим содержимое файла, который был сгенерирован при создание закрытого ключа. Копируем содержимое файла.

Создание APT репозитория

Заходим в web-интерфейс менеджера репозиториев Nexus http://10.10.1.1:8080. Авторизуемся с правами администратора и нажимаем на шестерёнку вверху. Далее выбираем раздел Repositories. Нажимаем Create repository и выбираем apt(hosted):

Создание APT репозитория

Далее заполняем поля и вставляем в поле Signing Key содержимое из файла private.gpg.key:

Вставляем закрытый ключ

В поле Passphrase вводим пароль, который вводили при генерации ID и закрытого ключа. Нажимаем Create repository. После этого будет создан репозиторий APT, в который можно загружать deb-файлы и подключать к Debian/Ubuntu или подобным ОС.

Источник

Настройка репозитория Sonatype Nexus для проксирования артефактов Maven

Про утилиту сборки для Java-проектов Maven и про возможность создания локального сервера для Maven-репозитория с помощью Sonatype Nexus на Хабре уже упоминали (тут и тут). Однако, никакого рецепта по этому поводу представлено не было. Это неудивительно при наличии достаточно полной грамотной документации. По долгу службы мне пришлось настраивать его на нашей фирме, и оказалось, что советы из официальной документации не совсем подходят. Возникшей проблемой и способом ее решения я и хочу поделиться с сообществом. Но обо всем по порядку.

Зачем это нужно?

Локальный сервер для Maven-репозитория (как, например, Sonatype Nexus) может быть использован для хранения локальных артефактов Maven, и действительно пригодится командам, которые разрабатывают модульные приложения, но не собираются публиковать модули в общий доступ.

Установка Sonatype Nexus

На данном этапе можно смело следовать документации, на моей памяти проблем не возникало. На сайте Sonatype есть неплохой обучающий скринкаст. Вкратце перескажу суть процесса установки.

В принципе, им уже можно пользоваться без всякой настройки(из коробки доступны прокси-репозитории Maven central, Codehaus, Apache), но имеет смысл настроить права доступа, группы репозиториев, добавить необходимые прокси-репозитории, включить индексирование, и.т.п.

Настройка Maven для использования Sonatype Nexus в качестве прокси

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

Здесь рекомендуют в settings.xml записать следующее:

mirror >
id > nexus id >
mirrorOf > * mirrorOf >
url > http://host:8081/nexus/content/groups/public url >
mirror >

Вполне логичный совет, но имеется ряд организационных проблем, связанных с ограничением доступа к администрированию Nexus. Так, например, для того чтобы попробовать в деле какую-нибудь библиотеку стороннюю, разработчик вынужден дергать админа, чтоб тот добавил соответствующий репозиторий в Nexus. На время отключать это зеркало в settings.xml — тот еще костыль.

profiles >
profile >
id > nexus id >
repositories >
repository >
id > nexus-repo id >
name > Nexus repo name >
url > http://host:8081/nexus/content/groups/public url >
releases >
enabled > true enabled >
releases >
snapshots >
enabled > true enabled >
snapshots >
repository >
repositories >
pluginRepositories >
pluginRepository >
id > nexus-repo id >
name > Nexus repo name >
url > http://host:8081/nexus/content/groups/public url >
releases >
enabled > true enabled >
releases >
snapshots >
enabled > true enabled >
snapshots >
pluginRepository >
pluginRepositories >
profile >
profiles >
activeProfiles >
activeProfile > nexus activeProfile >
activeProfiles >

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

Теперь все запросы сначала отправляются Nexus_у. Тот в зависимости от наличия запрашиваемого артефакта в хранимых и подключенных прокси-репозиториях либо отдает запрошенный артефакт, либо отвечает отрицательно. В случае отрицательного ответа Maven просто продолжит опрос перечисленных в pom.xml репозиториев, а затем обратится и к репозиторию Maven central.

Примущества подхода

Недостатки подхода

Выявлен только один недостаток — существует опасность забыть добавить необходимый дополнительный репозиторий в pom.xml. Правда, следует отметить, что этот недостаток касается фактически всех подходов (кроме 2-го) а также может проявляться вообще в отсутствие локального Nexus репозитория.

Дело в том, что если сторонний репозиторий добавлен в Nexus, то у разработчиков, у которых Nexus подключен, сборка будет проходить без проблем. Но разработчики, без настроенного Nexus не смогут собрать проект вообще, так как их Maven не будет знать, из какого дополнительного репозитория нужно запросить артефакты.

Аналогичная ситуация может возникнуть просто если какой-то артефакт закеширован в локальных репозиториях разработчиков после работы над предыдущими проектами. Вобщем, в этом вопросе лишь важно не терять бдительность.

Послесловие

Надо сказать, что совет авторов документации добавлять все дополнительные репозитории, описанные в pom.xml проектов, в Nexus никто не отменял. Это действительно лучше делать для того, чтобы получить выгоду от использования проксирующего Maven-репозитория. Но зато применение предложенного решения делает это необязательным, что может убрать время ожидания разработчика, пока админ добавит нужный репозиторий.

UPD: Наткнулся на интересную статью, в которой рассматриваются похожие вопросы.

Источник

Nexus: установка, запуск, деплой в репозиторий + NGINX и SSL

У Android-команды поломался “деплой” через отправку письма с вложением на Gmail (было сделано ещё до меня), и появилась необходимость быстренько “накостылить” репозиторий.

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

Запуск Nexus из Docker

Обновляем систему, устанавливаем NGINX, и пока его стопаем:

Делаем тестовый запуск Nexus:

Дефолтный логин-пасс – admin:admin123, можно зайти, посмотреть как всё выглядит под админом:

Добавление репозитория

Добавляем репозиторий – переходим в Repositories:

Кликаем Create repository, выбираем raw(hosted) (см. описание тут>>>):

Попробуем в него загрузить файл.

Выбираем POST /v1/components, жмём Try it out, указываем что и куда будем загружать, нам тут интересен Request URL:

Источник

Centos

Nexus явля­ет­ся попу­ляр­ным мене­дже­ром репо­зи­то­ри­ев (repository manager). Он исполь­зу­ет­ся для хра­не­ния арте­фак­тов или прок­си, т.е. всё что выка­чи­ва­ет­ся через него, сохра­ня­ет­ся в нём.

yum install java-1.8.0-openjdk java-1.8.0-openjdk-devel createrepo

wget http://download.sonatype.com/nexus/3/latest-unix.tar.gz

vim /opt/nexus/bin/nexus.rc

vim /etc/systemd/system/nexus.service

[Unit]
Description=nexus service
After=network.target

[Service]
Type=forking
ExecStart=/opt/nexus/bin/nexus start
ExecStop=/opt/nexus/bin/nexus stop
User=nexus
Restart=on-abort

Умень­шить коли­че­ство потреб­ля­е­мой опе­ра­тив­ной памяти:
vim /var/nexus/nexus-3.19.1-01/bin/nexus.vmoptions
меняем
-Xms2703m
-Xmx2703m
на
-Xms512m
-Xmx512m

systemctl daemon-reload & & systemctl enable nexus

systemctl start nexus & & systemctl status nexus

WEB-интер­фейс

для авто­ри­за­ции в каче­стве логи­на используйте
admin
пароль мож­но посмот­реть тут:
cat /opt/sonatype-work/nexus3/admin.password

так­же по умол­ча­нию пароль может быть следующим:
Login : admin

Описание работы с данной утилитой

Общий репозиторий:

Далее пере­хо­дим к спис­ку репозиториев:

Name: test-repo-epel

Созда­ём yum group

Name: yum-repo-group

добав­ля­ем в него 2 создан­ных нами прок­си и сохраняем.

всё, репо­зи­то­рий создан.

и на целе­вой тач­ке созда­ем репозиторий:

[Centos-7-Nexus]
baseurl = http://192.168.1.177:8081/repository/ yum-repo-group /
gpgcheck = 1
enabled=1
gpgkey = file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7
name = Centos-Nexus

сохра­ня­ем и проверяем.

Общий репозиторий docker:

Name: docker-private
type hosted

http: 8083

мож­но ещё доба­вить для https

Нажи­ма­ем save

Нажи­ма­ем save

Нажи­ма­ем save

на целе­вой тач­ке добавляем:
cat /etc/docker/daemon.json
<
«insecure-registries»: [«192.168.1.177:8081″,»192.168.1.177:8082″,»192.168.1.177:8083»],
«experimental»: true
>

Далее необ­хо­ди­мо зало­ги­нить­ся в nexus репозитории:
docker login http://192.168.1.177:8082/repository/docker-group

. ВАЖНО. Если вы исполь­зу­е­те прок­си, то необ­хо­ди­мо убрать его, пере­за­пу­стить демон, и рестар­та­нуть docker(reload не хватит):

Источник

Sonatype Nexus

Менеджер репозиториев для локального хранения и управления артефактами, зависимостями и Docker-образами.

подходящих зависимостей на старте проекта.

зависимостей на уязвимости перед вводом новых
компонентов в цепочку разработки.

Какие бизнес-задачи можно решать

Снижение рисков финансовых и репутационных потерь при возможной компрометации данных и\или остановке сервисов из-за взлома приложений через уязвимые сторонние компоненты.

Sonatype Nexus позволяет проксировать, собирать и управлять зависимостями без постоянного обращения к внешним хранилищам бинарных JAR-артефактов.

Особенности

Выбор подходящих зависимостей на старте проекта

Жизненный цикл Nexus позволяет в режиме реального времени получить представление о качестве компонентов и принять оптимальное решение о том, какие зависимости включать в ваши приложения.

Внутренние инструменты для обеспечения безопасности разработки

Контроль качества исходников

Богатый и гибкий механизм настройки политик

Проверка зависимостей на уязвимости перед вводом новых компонентов в цепочку разработки

Точная информация по
использованию зависимостей
с подробными отчетами

Нужна помощь или совет?

У вас есть вопрос? Не уверены что именно вам нужно? Вам необходимо независимое экспертное мнение по информационной безопасности в бизнес терминах?

В рамках бесплатной 30-минутной консультации, ответим на любые ваши вопросы

Источник