Как создать 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-минутной консультации, ответим на любые ваши вопросы
