Nexus Repository

Введение

Одним предложением, Nexus Repository — это общий внутренний склад компонентов для разработки. Это сервер, который собирает и управляет библиотеками, пакетами, образами Docker и аналогичными ресурсами, используемыми в разработке, в одном месте, чтобы их можно было получить в любой момент.

В настоящее время каждый разработчик самостоятельно скачивает необходимые ресурсы из Интернета. Двадцать человек могут двадцать раз скачать одну и ту же библиотеку, а если внешний сайт ненадолго станет недоступен, сборки у всех одновременно остановятся. Nexus находится между ними: он скачивает ресурс один раз и распространяет его среди всех.

Nexus выполняет три основные функции.

• Скачивание и хранение — кэширование библиотек, загруженных из внешних источников, внутри организации.

• Хранение собственных артефактов — хранение создаваемых нами общих модулей и результатов сборки.

• Объединение за единой точкой входа — объединение нескольких репозиториев и предоставление доступа к ним через единый адрес.

Возможности репозиториев

Существует три основных типа репозиториев.

1. Прокси-репозиторий — обращается к внешним репозиториям от нашего имени и может кэшировать полученные результаты.

2. Размещённый репозиторий — позволяет напрямую загружать в Repository созданные нами артефакты.

3. Групповой репозиторий — используется для объединения нескольких репозиториев под единым адресом.

Если администратор объединяет Proxy и Hosted Repositories в Group Repository, пользователи могут использовать Group Repository при обращении к репозиториям, то есть им нужно работать только с одним Repository.

Пример конфигурации репозитория

Форматы пакетов, поддерживаемые Nexus

Главное преимущество Nexus заключается в том, что он поддерживает более 20 форматов, включая Java (Maven·Gradle), фронтенд (npm), Python, образы Docker и пакеты Linux, на одном сервере. Нет необходимости настраивать отдельные репозитории для каждого языка. Ниже перечислены поддерживаемые типы пакетов; также поддерживаются Terraform, Yum и другие форматы.

Использование во внутренних сетях

Разделение сетей создаёт одно существенное ограничение. Серверы во внутренней сети не могут получить доступ к Интернету. Поэтому они не могут использовать Proxy repositories, которые «получают ресурсы для них из внешних источников», и для переноса ресурсов, заранее загруженных из внешних источников, требуется процесс импорта.

Наиболее распространённая конфигурация предполагает развёртывание двух экземпляров Nexus. Один размещается во внешней сети (или в DMZ) для предварительной загрузки необходимых ресурсов, а другой — во внутренней сети для их распространения среди разработчиков. Ресурсы регулярно передаются между ними через систему сетевого взаимодействия.

  [인터넷] → [외부망 Nexus · Proxy] ← 필요한 것을 미리 받아 캐싱
                    ↓ 추출 → 검증(해시·백신·취약점) → 승인
      ═══ 망분리 경계 · 망연계 시스템으로 전송 ═══
                    ↓
  [내부망 Nexus · Hosted] → [개발자 PC / CI 서버]

Преимущества внедрения Nexus во внутренней сети

С точки зрения безопасности

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

Привилегии позволяют разделять права пользователей на работу с репозиториями.

Основные функции — просмотр, чтение, добавление, редактирование и удаление. Поэтому, если разработчику нужен только доступ для скачивания, можно предоставить только права на чтение и просмотр, а право на добавление выдавать лишь при необходимости загрузки.

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

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

Практический пример (Java + Gradle)

(1) Учетные данные — gradle.properties

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

# ~/.gradle/gradle.properties
nexusUrl=https://nexus.example.local
nexusUser=build-bot
nexusToken=xxxxxxxx-xxxx-xxxx

(2) Где получать библиотеки — settings.gradle

Gradle плагиныи библиотекиполучаются через разные пути. Необходимо указать оба. Если упустить это в изолированной сети, можно столкнуться с ситуацией, когда «библиотека скачивается, но процесс останавливается на плагине».

pluginManagement {
    repositories {
        maven {
            url = uri("${nexusUrl}/repository/gradle-plugins/")
            credentials { username = nexusUser; password = nexusToken }
        }
    }
}

dependencyResolutionManagement {
    // 하위 모듈이 mavenCentral()을 임의로 선언하지 못하게 막습니다
    repositoriesMode = RepositoriesMode.FAIL_ON_PROJECT_REPOS
    repositories {
        maven {
            url = uri("${nexusUrl}/repository/maven-public/")
            credentials { username = nexusUser; password = nexusToken }
        }
    }
}

(3) Загрузка артефактов сборки — build.gradle

Если к версии добавлен SNAPSHOT, она отправляется в репозиторий разработки; в противном случае — в репозиторий релизов. Рекомендуется запретить перезапись в репозитории релизов с помощью настроек Nexus. Это позволяет структурно предотвращать ситуации, когда содержимое различается, несмотря на одинаковую версию.

plugins { id 'java'; id 'maven-publish' }

publishing {
    publications { maven(MavenPublication) { from components.java } }
    repositories {
        maven {
            url = version.toString().endsWith('SNAPSHOT')
                ? "${nexusUrl}/repository/maven-snapshots/"
                : "${nexusUrl}/repository/maven-releases/"
            credentials { username = nexusUser; password = nexusToken }
        }
    }
}

Распространенные проблемы

1. При сборке и загрузке файлов иногда бывает, что файл загружен, но Gradle не может его найти, поскольку метаданные не были обновлены. Запустите задачу Nexus Repair - Rebuild Maven repository metadata или нажмите Invalidate cache в репозитории, чтобы очистить кэш.

2. Необходимо управлять емкостью сервера Nexus. Данные, непрерывно поступающие в репозитории Proxy и Hosted, будут накапливаться. Администраторам следует использовать настройки Cleanup Policy для управления удалением устаревших данных snapshot. Регулярно запускайте Compact blob store.

Заключение

Nexus — не самый эффектный инструмент. Однако после его настройки разработчикам больше не приходится ждать библиотеки, а специалисты по безопасности могут проверять в одном месте, что именно было получено. Часто говорят, что безопасность и скорость разработки противоречат друг другу, но по крайней мере в этой области грамотно спроектированный единый шлюз улучшает и то, и другое.

Ссылки

· Официальная документация Sonatype Nexus Repository — Типы репозиториев / Введение в Community Edition (help.sonatype.com)

Ввод