nexus artifactory что это
Настройка репозитория 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 или Artifactory для репо Maven?
Мы используем Maven для большого процесса сборки (> 100 модулей). Мы храним наши внешние зависимости в управлении исходным кодом и используем их для обновления локального репо.
Тем не менее, мы готовы перейти к локальному репо, который может кэшировать центральное хранилище, так что нам не нужно предварительно загружать все сторонние репозитории (но у нас все еще может быть локальное репо для извлечения). Кроме того, мы хотим опубликовать наши внутренние артефакты из ночной сборки, чтобы разработчикам не приходилось создавать мир.
Мы рассматриваем Nexus и Artifactory. Каковы причины предпочтения одного над другим? Есть ли другие, которые мы должны рассмотреть?
Я не знаю об Artifactory, но вот мои причины для использования Nexus:
Я уверен, что если вы будете говорить только о сохранении двоичных файлов из » mvn deploy «, то все будет хорошо.
Мы очень широко используем Artifactory со всеми улучшениями на этом пути. Множество проектов, многочисленные снимки развернуты и внешние репозитории прокси. Ни единой проблемы. Мне трудно объяснить, как другие люди испытывают проблемы с его БД, индексацией или чем-то еще. Ничего подобного никогда не случалось с нами. Кроме того, Artifactory позволяет хранить данные на диске и использовать только БД для хранения метаданных, это довольно гибко ( подробнее здесь ).
Что делает эти приложения очень разными, так это их подход к интеграции с другими инструментами и технологиями сборки. Nexus и Sonatype в значительной степени привязаны к Maven и m2Eclipse. Они игнорируют все остальное и только недавно начали работать над своей собственной интеграцией Hudson (см. Их вебинар Maven ). РЕДАКТИРОВАТЬ: Это больше не так с 2017 года, когда Nexus предоставляет гораздо большая поддержка для других инструментов сборки Конец редактирования
Как вы видите, Artifactory думает «вне коробки», а Nexus думает «внутри коробки» и заботится только об артефактах Maven и Maven.
Подводя итог, для основного хранения артефактов Maven я думаю, что оба в порядке. Но в то время как Nexus перестает быть просто «менеджером репозитория Maven», Artifactory продолжает работать, являясь общим «хранилищем бинарных файлов» для бинарных файлов любого типа с любого инструмента сборки и CI-сервера.
Другим важным отличием является то, что Artifactory имеет уникальную интеграцию с Hudson и TeamCity для сбора информации о развернутых артефактах, разрешенных зависимостях и данных среды, связанных с прогонами сборки, что обеспечивает полную отслеживаемость сборки.
Artifactory хранит артефакты в базе данных, что означает, что если что-то пойдет не так, все ваши артефакты исчезнут. Nexus использует плоский файл для ваших драгоценных артефактов, так что вам не нужно беспокоиться о том, что все они будут потеряны.
Если вам нужны «профессиональные» функции (например, постановка репо, продвижение артефактов, NuGet), то вам необходимо рассмотреть различные модели ценообразования, которые отображаются на их веб-сайтах.
7 450 долл. США в год позволят вам приобрести примерно 67 мест в Nexus Pro (1–50 при 108 долл., Остальные при 120 долл.).
Только по цене и поддержке Nexus Pro имеет смысл, пока вы не получите 67 пользователей, после чего Artifactory становится более дешевым вариантом.
Если вы делаете всю поддержку внутри компании; однако этот магический момент составляет около 23 пользователей (самое основное предложение поддержки Artifactory составляет 2750 долларов в год).
Недавно я провел некоторое исследование об Artifactory 2 и Nexus 1.3. Я перечислю здесь основные различия, которые я нашел:
Вы должны использовать Artifactory. Его последняя версия была настоящим скачком. Вы можете постепенно создавать резервные копии своих репозиториев, что означает, что вы можете сохранить и сохранить все свои артефакты. Он имеет простой в использовании веб-интерфейс и действительно прост в настройке. из своей новой версии 2.0
С точки зрения учащихся, я отмечаю некоторые конкретные различия между ними.
Помимо политики и религии, лицензирование имеет значение для некоторых организаций.
Артефакт является Apache лицензирован LGPLv по состоянию на версию 2.1 продукта.
Я вижу, что использование Nexus растет, в то время как использование Artifcatory в целом остается неизменным.
В двух словах о NEXUS
Весной этого года команда наших разработчиков побывала на тренинге по многокомандному скраму с использованием фреймворка Nexus. Это оказался очень интересный инструмент, и мы хотим поделиться с вами впечатлениями от его возможностей.
Nexus — это фреймворк Кена Швабера, являющийся органичным и эволюционным расширением классического скрама для крупных проектов с многокомандной разработкой. Он базируется на тех же привычных scrum-основах: ролях, артефактах и ивентах, дополняя их аналогичными ивентами и артефактами для выявления и управления зависимостями, своевременного обмена информацией и доменными знаниями между командами и удержания фокуса на конечном продукте, а не индивидуальных инкрементах.
К стандартным scrum-ролям добавляется новая — Nexus Integration Team, отвечающая за успешную интеграцию всех сделанных инкрементов и решение технических и нетехнических ограничений между командами.
Эта группа участников состоит из выбранных представителей команд, которые озвучивают интересы команды. Если рабочее время участников делится между NIT и командой разработчиков, то более приоритетна работа в Nexus Integration Team.
Состав интеграционной команды может меняться по необходимости.
События
С камнем преткновения многокомандного скрама — перекрёстными зависимостями между фичами и командами, — в процесс официально добавляются refinement sessions, время проведения которых жёстко не задано и выбирается в любой удобный момент спринта.
Событие проходит в несколько этапов: сперва NIT разбивает содержимое бэклога на мелкие и независимые части до уровня, когда одна команда может закончить фичу за один спринт.
Затем выявляются и визуализируются все зависимости между фичами и командами. На этом этапе NIT определяет своеобразную «дорожную карту» фич и зависимостей: что и какой командой будет сделано, в каком спринте.
Дальше фичи спускаются на уровень команд и пересматриваются более подробно с помощью того же подхода: разделить на более мелкие части, выделить и визуализировать зависимости.
Планирование в Nexus также проходит этапами:
Классические три вопроса скрама для интеграционной команды трансформируются в:
Nexus Retrospective состоит из трёх частей:
Артефакты
Чтобы видеть целостную картину по продукту, Product Backlog всегда сохраняется в единственном числе, как и инкремент. В Nexus нет командных Sprint Review, и результатом спринта является сумма всего, сделанного командами — Integrated Increment по продукту. Помимо Sprint Backlog, добавляется новый артефакт — Nexus Sprint Backlog, который является набором фич для всех команд с указанными между ними зависимостями — своеобразным общим планом спринта, — и используется для отслеживания прогресса и ежедневного перепланирования по общему инкременту.
Definition of Done формируется NIT, пересматривается и поддерживается в актуальном состоянии после каждой ретроспективы. Команды могут дополнительно создавать свои DoD, но правила должны быть строже, чем у общего.
Масштабирование
Масштабирование начинается с хорошо настроенного скрама в рамках одной команды — те же основы и опыт фрактально переносятся на многокомандный уровень. Постепенно исходная команда делится на две-три команды и итеративно и инкрементально добавляются новые разработчики. Нужно следить, чтобы общий инкремент оставался устойчивым и предсказуемым. В ином случае количество потраченных усилий будет несравнимо выше, и сложность зависимостей, интеграционных и коммуникационных проблем будет расти в геометрической прогрессии при добавлении каждой следующей команды.
Nexus предполагает работу над одним продуктом 3-9 команд. Существует еще Nexus+, представляющий собой следующий уровень надстройки над фреймворком (Nexus для Nexus-а), но стоит трижды подумать, прежде чем его применять. В какой-то момент количество времени, уходящее на менеджмент зависимостей, перевешивает пользу от добавления новых команд.
Single source control, continuous integration/build/test/deploy, use of SOLID principles, API’s, DevOps concepts и т.п. — чем больше масштабирование, тем большее количество техник и подходов необходимо использовать.
Product Owner отвечает за верхнеуровневое видение продукта, за стратегию, приоритезацию и определение ценности. В независимости от масштаба проекта, существует только один бэклог и один PO на продукт. Он или она может иметь помощников по ежедневными задачами: описывать критерии истории, разъяснять командам детали, обращаться за помощью к экспертам в какой-то доменной области. Но финальное слово по приоритезации остаётся за Product Owner.
Nexus Repository Preferred 2:1 Over JFrog Artifactory
10 million developers in 148 countries trust Nexus Repository.
Start Your Free Trial
Manage what you code in Git. Secure what you build in Nexus.
Highly Available Package Management Integrated Into Your CI/CD Pipelines
Manage components from dev through delivery: binaries, containers, and build artifacts. Nexus offers universal support and is compatible with popular tools like Eclipse, IntelliJ, Hudson, Jenkins, Puppet, Chef, Docker, and more.
Universal Support For All Your Packages and Containers
Extensive format coverage supporting all major languages and ecosystems. Nexus Repository offers a truly universal, central system of record to efficiently distribute binaries and containers across all your development teams.
Take Your Build Pipeline to the Next Level
Create a Secure Development Environment
Enforce open source policies within the developer’s IDE and SCM tools and quarantine bad components with an OSS firewall.
Enterprise-Grade Storage Capabilities and Reliability on Premises and in the Cloud
Scale DevOps delivery, on premises or in your favorite private cloud, with dynamic storage, high availability, and active/active clustering for all your Nexus deployments.
Detect Unknown or Unauthorized Components
Automatically generate a software bill of materials to identify open source and third-party libraries used within your software supply chain.
Best-in-class Component Security with Repository Health Check (RHC)
RHC provides up-to-date component intelligence, so you know how many OSS components are in your repositories and the severity of any existing vulnerabilities.
Implement Change-Detection Mechanisms
Continuously monitor applications for new open source security risk and resolve quickly with expert remediation guidance.
Global Community with Enterprise Support
#1 Ranked Repository Manager offering robust, enterprise storage management, 10M+ Nexus user community, and 24/7 customer support.
“One of the most valuable features is the variety of permissions you can use on the repository. That helps us protect access to information inside of the repository.”
— ANTHONY E., IT CENTRAL STATION REVIEW
“It has helped us reduce the effort in maintaining several systems. This is a huge benefit.”
— HAGEN R., IT CENTRAL STATION REVIEW
Nexus is powered by best in class intelligence
Nexus as a Container Registry
Built on extensive enterprise storage capabilities, Nexus Repository is a robust package registry for all of your Docker images and Helm Chart repositories.
Developer Smarter, Not Harder
Using open source libraries to build apps is a no brainer, but always choosing the best open source libraries requires a helping hand.
Learning Paths: Adventures Begin
Prepare to set out on a journey to learn how to increase developer productivity, reduce OSS risks, and shift left with secure coding practices.
Ready to Try Sonatype?
Secure and automate your software supply chain.
Products
Free Tools
Solutions
Resources
Customer Portal
Company
Copyright © 2008-present, Sonatype Inc. All rights reserved. Includes the third-party code listed here. Sonatype and Sonatype Nexus are trademarks of Sonatype, Inc. Apache Maven and Maven are trademarks of the Apache Software Foundation. M2Eclipse is a trademark of the Eclipse Foundation. All other trademarks are the property of their respective owners.
Установка и настройка Nexus Sonatype используя подход infrastructure as code
Sonatype Nexus – интегрированная платформа, с помощью которой разработчики могут проксировать, хранить и управлять зависимостями Java (Maven), образами Docker, Python, Ruby, NPM, Bower, RPM-пакетами, gitlfs, Apt, Go, Nuget, а также распространять свое программное обеспечение.
Зачем нужен Sonatype Nexus?
Артефакты поддерживаемые в базовой поставке Sonatype Nexus:
Артефакты поддерживаемые сообществом:
Установка Sonatype Nexus используя https://github.com/ansible-ThoTeam/nexus3-oss
Требования
Пример ansible-playbook для установки nexus без LDAP с репозиториями Maven (java), Docker, Python, Ruby, NPM, Bower, RPM и gitlfs.
Скриншоты:
Переменные роли
Role Variables
Переменные со значениями по умолчанию (см. default/main.yml ):
General variables
Если вы измените версию на более новую, то роль попытается обновить ваш установленный Nexus.
Если вы используете более старую версию Nexus, чем последняя, вы должны убедиться, что не используете функции, которые недоступны в установленном выпуске (например, размещенние yum репозиториев доступно для nexus больше чем 3.8.0, git lfs repo для nexus больше чем 3.3.0 и т. д.)
nexus timezone — это имя часового пояса Java, которое может быть полезно в сочетании с приведенными ниже выражениями cron для nexus_scheduled tasks.
Порт Nexus и контекстный путь
Пользователь и группа ОС Nexus
Пользователь и группа, используемые для владения файлами Nexus и запуска службы, будут созданы ролью, если она отсутствует.
Разрешить изменять домашний каталог по умолчанию для пользователя nexus
Каталоги экземпляров Nexus
Настройка использование памяти Nexus JVM
Это настройки по умолчанию для Nexus. Пожалуйста, не изменяйте эти значения Если вы не прочитали раздел памяти системных требований nexus и не понимаете, что они делают.
Как второе предупреждение, вот выдержка из вышеупомянутого документа:
Не рекомендуется увеличивать память JVM heap больше рекомендуемых значений в попытке повысить производительность. Это на самом деле может иметь противоположный эффект, приводя к ненужной работе операционной системы.
Пароль администратора
Пароль учетной записи «admin» для настройки. Это работает только при первой установке по умолчанию. Пожалуйста, смотрите [Изменить пароль администратора после первой установки](# change-admin-password-after-first-install), если вы хотите изменить его позже с помощью роли.
Настоятельно не рекомендуется хранить свой пароль в виде открытого текста в playbook, а использовать [шифрование ansible-vault] (https://docs.ansible.com/ansible/latest/user_guide/vault.html) (либо встроенный или в отдельный файл, загруженный, например, с помощью include_vars)
Анонимный доступ по умолчанию
Анонимный доступ по умолчанию вылючен. Подробнее про анонимный доступ.
Публичное имя хоста
Полное доменное имя и схема (https или http), по которой экземпляр Nexus будет доступен для его клиентов.
Доступ API для этой роли
Эти переменные контролируют, как роль подключается к API Nexus для предоставления.
Только для продвинутых пользователей. Скорее всего, вы не хотите изменять эти настройки по умолчанию
Настройка обратного прокси
С httpd_copy_ssl_files: true (по умолчанию) вышеупомянутые сертификаты должны существовать в вашей директории playbook и будут скопированы на сервер и настроены в apache.
Если вы хотите использовать существующие сертификаты на сервере, установите httpd_copy_ssl_files: false и предоставьте следующие переменные:
httpd_ssl_cert_chain_file_location является необязательным и должен быть оставлен неустановленным, если вы не хотите настраивать файл цепочки
Установить адрес электронной почты администратора по умолчанию
Конфигурация LDAP
Соединения LDAP и область безопасности по умолчанию отключены
Соединения LDAP, каждый элемент выглядит следующим образом:
Пример конфигурации LDAP для анонимной аутентификации (анонимная привязка), это также «минимальная» конфигурация:
Пример конфигурации LDAP для простой аутентификации (с использованием учетной записи DSA):
Пример конфигурации LDAP для простой аутентификации (с использованием учетной записи DSA) + группы, сопоставленные как роли:
Пример конфигурации LDAP для простой аутентификации (с использованием учетной записи DSA) + группы, динамически сопоставленные как роли:
Привилегии
Список привилегий для настройки. Посмотрите документацию и графический интерфейс, чтобы проверить, какие переменные должны быть установлены в зависимости от типа привилегии.
Эти элементы объединяются со следующими значениями по умолчанию:
Роли (внутри Nexus имеется виду)
Список ролей для настройки.
Пользователи
Local (non-LDAP) users/accounts list to create in nexus.
Список локальных (не LDAP) пользователей/учетных записей для создания в Nexus.
Маппинг Ldap пользователей/ролей. Состояние absent удалит роли из существующего пользователя, если он уже существует.
Пользователи Ldap не удаляются. Попытка установить роль для несуществующего пользователя приведет к ошибке.
Селекторы контента
Для получения дополнительной информации о селекторе контента см. Документацию.
Чтобы использовать селектор контента, добавьте новую привилегию с type: repository-content-selector и соответствующим contentSelector
Blobstores и репозитории
Delete the repositories from the nexus install initial default configuration. This step is only executed on first-time install (when nexus_data_dir has been detected empty).
Удаление репозиториев из исходной конфигурации по умолчанию для Nexus. Этот шаг выполняется только при первой установке (когда nexus_data_dir пустой).
Blobstores to create. A blobstore path and a repository blobstore cannot be updated after initial creation (any update here will be ignored on re-provisionning).
Configuring blobstore on S3 is provided as a convenience and is not part of the automated tests we run on travis. Please note that storing on S3 is only recommended for instances deployed on AWS.
Cоздание Blobstores. Путь к хранилищу и репозиторию хранилищ не могут быть обновлены после первоначального создания (любое обновление здесь будет игнорироваться при повторной установке).
Настройка хранилища BLOB-объектов на S3 предоставляется для удобства. Обратите внимание, что хранение на S3 рекомендуется только для экземпляров, развернутых на AWS.
Выше пример конфигурации прокси-сервер Maven.
Maven hosted repositories configuration. Negative cache config is optionnal and will default to the above values if omitted.
Конфигурация размещенных (hosted) репозиториев Maven. Конфигурация отрицательного кэша (-1) является необязательной и будет по умолчанию использовать вышеуказанные значения, если не указана.
Все три типа репозитория объединяются со следующими значениями по умолчанию:
Docker, Pypi, Raw, Rubygems, Bower, NPM, Git-LFS and yum repository types:
see defaults/main.yml for these options:
Хранилища Docker, Pypi, Raw, Rubygems, Bower, NPM, Git-LFS и yum по умолчанию выключены:
Смотрите defaults/main.yml для этих опций:
Обратите внимание, что вам может потребоваться включить определенные области безопасности, если вы хотите использовать другие типы репозиториев, кроме maven. Это по умолчанию false
Remote User Realm также может быть включена с помощью
и заголовок может быть настроен путем определения
Запланированные задачи
Запланированные задачи для настройки. typeId и специфичные для задачи taskProperties / booleanTaskProperties можно угадать либо:
Свойства задачи должны быть объявлены в правильном блоке yaml в зависимости от их типа:
Резервные копии
Если вы хотите ротировать/удалять резервные копии, установите nexus_backup_rotate: true и настройте количество бекапов, которое вы хотели бы сохранить с помощью nexus_backup_keep_rotations (по умолчанию 4).
Процедура восстановления
Удаление nexus
Предупреждение: это полностью удалит текущие данные. Обязательно сделайте резервную копию ранее, если это необходимо
Изменить пароль администратора после первой установки
Если вы хотите изменить пароль администратора после первой установки, вы можете временно изменить его на старый пароль из командной строки. После изменения nexus_admin_password в вашей игровой книге вы можете запустить: