для чего нужен nexus
В двух словах о 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.
Русские Блоги
О повышении эффективности командной разработки можно много сказать, вот относительно простой и «очевидный эффект».
В некоторых компаниях, если доступ к внешней сети ограничен, для доступа к внешней сети может потребоваться унифицированный прокси. И более строгое управление может также выдавать самозаверяющие сертификаты для внешних ресурсов, к которым осуществляется доступ, что вызовет несколько проблем.
Вышеупомянутые проблемы могут влиять на людей, выполняющих разные роли, будь то разработка, тестирование или даже эксплуатация и обслуживание. (Пока это связано с упаковкой, это повлияет более или менее)
Если одному человеку требуется 30 минут, чтобы решить вышеуказанные проблемы, то 10 людям нужно 5 часов. Общее время расчета по-прежнему велико, что сильно влияет на общую эффективность.
(если вы индивидуальный разработчик, это может не иметь большого смысла)
Есть ли решение? возможно Nexus Repository Это выбор.
Что такое Nexus и для чего он нужен?
Nexus Repository Есть Pro Платная версия, но обычно мы пользуемся ею бесплатно OSS Версия нормальная.
Как пользоваться Nexus?
установка
Здесь я использую docker Для установки, конечно, вы также можете напрямую загрузить установочный пакет и установить его.
скачать nexus новейший image
Привязываем порт и запускаем
Локальный тест, откройте браузер и введите
Увидев этот интерфейс, установка прошла успешно
В первый раз, когда установка будет успешной, нам будет предложено изменить пароль администратора по умолчанию, нам нужно shell Войдите и получите пароль
Если вы хотите остановить или запустить нексус, выполните следующую команду
$ docker stop/start nexus
В репо по умолчанию есть эти
Android/Java
Конфигурация на стороне сервера
Android и Java будут разделять большую часть общедоступных maven, наиболее распространенными из них являются
Кроме того, Android также будет использовать
В качестве примера возьмите распределение Gradle, чтобы увидеть, как добавить эту конфигурацию
Обратите внимание, что его тип raw(proxy)
Вот краткое изложение часто используемых maven и соответствующего типа
После создания соответствующего репо по очереди настройте maven-public, чтобы добавить все репо типа maven2
Конфигурация клиента
Возьмите проект Android в качестве примера, чтобы увидеть, какую конфигурацию нам нужно изменить.
Сначала откройте проект в любом текстовом редакторе (не используйте Android Studio или IDEA, он автоматически запустит синхронизацию градиента)
Изменить элемент build.gradle Репо
Изменить файл gradle/wrapper/gradle-wrapper.properties
NodeJs
Конфигурация на стороне сервера
Создайте npm (proxy) Репо, удаленный URL
Конфигурация клиента
Настроить зеркало npm
Восстановить реестр npm
Python
Конфигурация на стороне сервера
Создайте pypi (proxy) Репо, удаленный URL
Конфигурация клиента
Создайте файл в каталоге пользователя
/.pip/pip.conf (Если его не существует), добавьте следующую конфигурацию
Создайте cocoapods (proxy) Репо, удаленный URL
Summary
Настройка репозитория 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 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 в вашей игровой книге вы можете запустить:
Sonatype Nexus
Менеджер репозиториев для локального хранения и управления артефактами, зависимостями и Docker-образами.
подходящих зависимостей на старте проекта.
зависимостей на уязвимости перед вводом новых
компонентов в цепочку разработки.
Какие бизнес-задачи можно решать
Снижение рисков финансовых и репутационных потерь при возможной компрометации данных и\или остановке сервисов из-за взлома приложений через уязвимые сторонние компоненты.
Sonatype Nexus позволяет проксировать, собирать и управлять зависимостями без постоянного обращения к внешним хранилищам бинарных JAR-артефактов.
Особенности
Выбор подходящих зависимостей на старте проекта
Жизненный цикл Nexus позволяет в режиме реального времени получить представление о качестве компонентов и принять оптимальное решение о том, какие зависимости включать в ваши приложения.
Внутренние инструменты для обеспечения безопасности разработки
Контроль качества исходников
Богатый и гибкий механизм настройки политик
Проверка зависимостей на уязвимости перед вводом новых компонентов в цепочку разработки
Точная информация по
использованию зависимостей
с подробными отчетами
Нужна помощь или совет?
У вас есть вопрос? Не уверены что именно вам нужно? Вам необходимо независимое экспертное мнение по информационной безопасности в бизнес терминах?
В рамках бесплатной 30-минутной консультации, ответим на любые ваши вопросы