что такое nexus sonatype
Настройка репозитория 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: Наткнулся на интересную статью, в которой рассматриваются похожие вопросы.
Как создать 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 или подобным ОС.
«Инфраструктура как код» в автоматизации сервисов CI/CD
Привет! Меня зовут Игорь Николаев, я пью за любовь работаю в отделе автоматизации процессов разработки Мир Plat.Form в НСПК. В этой статье я поделюсь тем, как наш отдел решал задачу по автоматизации предоставления различных ресурсов для команд разработки. Эта задача свойственна организациям с большим количеством проектов, инфраструктура которых состоит из распределенных и, возможно, слабо связанных сетевых сегментов.
В статье описан PoC (Proof of concept) решения задачи выделения ресурсов в рамках сервисов CI/CD (Continuous Integration & Continuous Delivery) и предоставления привилегий для пользователей этих сервисов.
Описание
Про тиражирование стоит сказать подробнее, у нас есть несколько сетевых сегментов с разными сервисами CI/CD, и иногда они имеют минимум сетевой связанности. Система должна с минимальными затратами обслуживать несколько окружений, которые могут отличаться друг от друга.
Что мы выбрали для PoC:
Как подход был выбран IaC (Infrastructure-as-Code) с описанием желаемых состояний в виде yaml файлов.
Python — язык для написания автоматизации (подходящий вариант для прототипа);
Bitbucket — веб-сервис для хостинга проектов и их совместной разработки;
Jenkins — сервис непрерывной интеграции (необходим нам для визуализации выполнения задач).
Как пилотные системы для автоматизации были выбраны:
Active Directory — всем известные службы каталогов (нам понадобятся группы и пользователи);
Bitbucket — часто запрашивают создание проектов, предоставление привилегий;
Nexus 3 OSS (не реклама, нет страницы в Wiki) — корпоративная система хранения артефактов, при появлении проектов создаются персональные репозитории проекта и выдаются привилегии.
Разговор об автоматизации следует начать с описания общей концепции.
В Bitbucket есть две важные сущности: проект(project) и репозиторий (repository), который входит в состав проекта. Для описания доступов в рамках концепта мы решили ограничиться доступами к проекту (более сегментированное предоставление привилегий (на репозиторий) в рамках концепта не потребуется).
У project в Bitbucket есть параметр project key, который понадобится для дальнейших манипуляций, мы взяли его за связующую основу. Именно он и будет являться названием директории в git-репозитории meta. В директории проекта будут размещаться meta-файлы (карты) проекта описанные в формате yaml.
Проектов в Мир Plat.Form много, и у каждого есть своя специфика. Возникает мысль держать в одном месте информацию о группах, инструментах, требуемых проекту, стендах (наборах серверов) и прочего, что имеет отношение к проекту. Для этого отлично подходит git репозиторий.
Какие задачи это решает?
Структура meta репозитория git:
DEV — наименование сетевого сегмента
project1 — ключ проекта в Bitbucket
project1_meta.yaml — карта проекта
examples — директория примера описания
Такая структура позволит описать несколько различных сетевых сегментов, при этом сохраняя гибкую возможность изменений и различий между ними.
Скрипты автоматизации в рамках концепта будут находиться в проекте в отдельных репозиториях (названия не принципиальны):
О назначении первых трех репозиториев легко догадаться. Последний репозиторий jjb-core — репозиторий в котором мы будем хранить описание Jenkins Job в виде рецептов для Jenkins Job builder (о нем будет рассказано ниже).
Автоматизация Microsoft AD
Active Directory используется во многих организациях. Большое количество рабочих процессов организаций начинаются именно с него. У нас в Мир Plat.Form все сотрудники имеют учетные записи в AD и включены в различные группы.
За AD отвечает подразделение инфраструктуры. Для наших нужд была выделена техническая учетная запись (ТУЗ), которой делегировано управление одним из Organization unit (OU). Именно в нем с помощью простой автоматизации мы будем создавать группы и наполнять их пользователями.
Часть содержимого project1_meta.yaml, которая отвечает за AD:
READY — булево значение и позволяет, в случае необходимости, выключить автоматизацию обработки данного мета файла
TEAM — секция, описывающая сущность проекта
ROLES — произвольные названия ролей на проекте, отображающие суть
GLOBAL_PRIVELEGES — секция описывает, какая роль будет обладать какими привилегиями
Пример мета репозитория
В рамках предоставления прав для окружения разработки, чтобы не усложнять пример, остановимся на 3х основных ролях: owner, developer, qa (в целом, количество и наименование ролей является произвольным). Для дальнейшей автоматизации эти роли позволят покрыть большую часть повседневных потребностей (у нас сразу появились роль tech, для ТУЗ, но для примера обойдемся без нее).
В рамках OU проекта будем автоматически, на основании meta-файлов проекта, создавать необходимые SG (Security group) и наполнять их пользователями.
На схеме структура выглядит так:
В AD используем плоскую иерархическую структуру, это позволит ее легко обслуживать, и выглядит она весьма наглядно.
Скрипт автоматизации получился очень простой. Он позволяет отслеживать изменения в составе групп (добавление/удаление пользователей) и создавать OU/SG.
Для запуска потребуется установить зависимости из requirements.txt (ldap3, PyYAML).
Автоматизация Sonatype Nexus3 OSS
Что такое Nexus? Nexus — это менеджер репозиториев, позволяющий обслуживать разные типы и форматы репозиториев через единый интерфейс (Maven, Docker, NPM и другие).
На момент написания статьи версия была OSS 3.25.1-04
Почему именно Nexus?
Есть community версия, которая обладает богатым функционалом, достаточным для выполнения большинства задач, связанных с хранением артефактов и проксирования внешних репозиториев.
Процесс хранения артефактов является важным при проектировании конвейера тестирования и развертывания.
Что потребуется автоматизировать?
Blobstore
Все двоичные файлы, загружаемые через proxy репозитории (мы не предоставляем прямого доступа к интернет репозиториям, используем исключительно прокисрование через nexus), опубликованные в hosted (локальные репозитории) репозитории хранятся в хранилищах Blob-объектов, связанном с репозиторием. В базовом развертывании Nexus, с одним узлом, обычно связаны с локальным каталогом на файловой системе, как правило, а каталоге sonatype-work.
Nexus версии >= 3.19 поддерживает два типа хранилищ File и S3.
Как мы видим, по умолчанию нам уже доступно хранилище default. Из информации выше мы можем понять, что данный blob находится на диске и ему доступен весь объем дискового раздела, на котором находится директория sonatype-work.
Проблематика
В целом, все логично, но есть минимум две проблемы, о которых следует задуматься:
Простое решение
Первое, что приходит в голову — это создание отдельных blob stores. Очевидно, это не решает проблему расположения на одном дисковом разделе. Подходящим решением является «нарезать» разделы для каждого проекта. Забегая вперед, это решит еще и вопрос мониторинга и отправки уведомлений ответственным за проект. Удобное решение второго пункта описанных проблем.
По первому пункту наиболее правильным решением является создание отдельных blob store для каждого репозитория.
UI создания Blob stores:
Nexus позволяет настроить Soft quota, штука сомнительная. Она уведомляет о том, что с местом что-то не так, но не производит каких-либо действий. При правильном применении шагов, описанных выше, удается добиться большего функционала (Появляется простой способ отслеживания объема и обращений к диску, а переполнение не создает неприятности «соседям»).
В поле path мы можем указать раздел, который примонтирован, например, как nfs.
Что позволяет держать раздел непосредственно на сетевом хранилище. Это может снизить скорость, но дает ряд преимуществ с точки зрения простоты.
Nexus у нас запускается в Docker, для этого используется compose файл. Для подключения новых точек монтирования, простым решением будет добавить в compose файле монтирование родительского каталога точек монтирования.
Repositories
Nexus позволяет создавать репозитории почти всех распространенных форматов. Если идти в сторону идеального хранения, то целесообразно для каждого проекта создавать минимум release и snapshot репозиторий, хотя идеальный вариант может содержать еще и release-candidat репозиторий. Это позволит настроить удобный механизм чистки репозиториев.
Определенно, release репозиторий должен во многих случаях иметь максимальную глубину хранения, как требование, в релизах не должно оказаться «мусора». Напротив, с репозиториями snapshot мы должны иметь возможность очищать без опасений в любое удобное время и без рисков.
Ко всем форматам репозиториев доступ осуществляется по 80 и/или 443 портам, за исключением docker. Репозиторий Docker, для доступа к нему, должен иметь персональный порт. Это приводит к некоторым сложностям. Каждый раз публикуя новый порт, мы должны добавлять его публикацию в compose файле.
LDAP
Nexus имеет возможность реализации подключения к LDAP и использования его в качестве аутентификации пользователей. В нашем случае мы используем группы пользователей для предоставления прав.
Roles
Для удобства роли создаются под проект, лучше идти от минимума, и для себя мы выбрали три роли для каждого проекта:
qa — обладают правами достаточными для read
developers — read, write
owners — read, write, delete
Группы из AD матчатся в локальные группы Nexus.
API
Начиная с версии Nexus OSS 3.19 появилось весьма удобное API для управления Nexus, это значимое нововведение, которое многие пользователи ждали позволит нам управлять Nexus и приводить его в нужное состояние.
На момент написания статьи API, по большей части, в статусе beta, но не смотря на это, работает без больших проблем и позволяет автоматизировать почти все необходимое.
Часть содержимого project1_meta.yaml, которая отвечает за nexus:
На основании такого файла система автоматизации создает все обслуживаемые сущности. В наших командах принято, что teamlead отвечает за наполнение файла проекта, однако, создать его может любой желающий. После создания pull request следует согласование вовлеченными в процесс участниками, после мерджа с master веткой, отрабатывает автоматизация.
Стоит отметить, мы стремимся сделать процесс максимально простым для пользователя, что влечет к использованию шаблонов конфигураций, которые описаны в виде примитивных моделей. Система позволяет переопределить умолчания в случае возникновения необходимости в описании карты проекта.
Пример кода модели для maven hosted repository:
Данный подход позволяет сократить описание создаваемой сущности до минимума.
Идеологически, все что может использовать значения по умолчанию должно их использовать, но при необходимости может быть заменено в файле карты проекта.
Автоматизация Atlassian Bitbucket
Для концепта достаточно будет автоматизировать создание проекта и предоставление привилегий к нему.
Часть содержимого project1_meta.yaml, которая отвечает за Bitbucket:
Это все, что потребуется при заведении нового проекта. Project key будет взят из названия yaml файла (в данном примере — project1).
Как это выглядит в UI:
Jenkins Job Builder
JJB является python утилитой для описания сущностей jenkins в виде yaml манифестов, которые преобразуются в понятные jenkins API запросы. Это позволяет великолепно решать задачу управления большим количеством однотипных задач.
Jenkins в данном контексте является интерфейсом для отображения успешности выполняемых задач автоматизации и контроля над ними. Сами задачи на первом этапе планируем выполнять по расписанию, например, каждый час. Это позволит избавиться большой части неконтролируемых ручных изменений и будет каждый час приводить систему к описанному состоянию.
Структура репозитория jjb-core:
Каждая директория содержит описание Jenkins job состоящее из двух файлов.
Yaml файл описывает шаблон jenkins job имеет следующее наполнение:
Файл groovy — это простой jenkinsfile:
Все это описывает создание следующей структуры Jenkins:
Общий алгоритм работы автоматизации:
Результат и развитие
Результатом данного концепта стало появление базовой автоматизации описанных процессов. Интерфейс взаимодействия в виде yaml карт проектов оказался весьма удобен, появились запросы на улучшения. Главными показателями успешности стали простота и скорость предоставления необходимых проектам ресурсов. Показатель скорости улучшился в разы по сравнению с ручным подходом. Все стало однотипным, понятным и повторяемым. Избавились от ручных ошибок.
На текущий момент описанный PoC перешел в стадию промышленной эксплуатации и претерпел значительные доработки. Мы переписали core систему автоматизации, к которой в виде плагинов подключаются модули для автоматизации новых сервисов. Появились тесты.
Всего автоматизацией обслуживается около 50 проектов и подключаются новые. Планируем тиражирование в другие сетевые сегменты.
Установка и настройка 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 в вашей игровой книге вы можете запустить: