Установка Sonatype Nexus в Ubuntu Linux, а также пример использования совместно с SBT | Записки программиста

Что такое sonatype nexus 3?

Sonatype Nexus 3 — это свободно распространяемый менеджер репозиториев, с удобным web-интерфейсом. Менеджер позволяет создавать репозитории, как для хранения конкретных форматов данных (yum, apt, Maven, Docker, npm, PyPl и так далее), так и формат хранения файлов Raw, в котором можно хранить любые типы файлов.

Менеджер репозиториев можно установить, как на обычную физическую или виртуальную машину, так и развернуть в docker-контейнере. Я разворачивал Nexus в docker-контейнере, поэтому буду описывать, как поднять APT репозиторий именно в docker. Доступные docker-образы Sonatype Nexus 3 можно найти по этой ссылке.

Введение

Статья не претендует на полноту и отражает лишь базовое решение. В итоге в вашем распоряжении будет установленное ПО для управления артефактами на стороне какого-либо хоста, скрипт для публикации Android библиотеки, возможность реализовать зависимости в своём приложении из локального maven репозитория.

Описание

Часто в организациях используются сложные и дорогостоящие IDM  – класс систем Identity Management (как в рамках лицензирования, так и внедрения и обслуживания) для управления доступами. Нам хотелось совместить процессы запроса и предоставления ресурсов на сервисах CI/CD и предоставления доступов к этим ресурсам.

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

Что мы выбрали для PoC:

Как подход был выбран IaC (Infrastructure-as-Code) с описанием желаемых состояний в виде yaml файлов.Python — язык для написания автоматизации (подходящий вариант для прототипа);Bitbucket — веб-сервис для хостинга проектов и их совместной разработки;Jenkins — сервис непрерывной интеграции (необходим нам для визуализации выполнения задач).

Как пилотные системы для автоматизации были выбраны:

Jenkins job builder

JJB является python утилитой для описания сущностей jenkins в виде yaml манифестов, которые преобразуются в понятные jenkins API запросы. Это позволяет великолепно решать задачу управления большим количеством однотипных задач.

Jenkins в данном контексте является интерфейсом для отображения успешности выполняемых задач автоматизации и контроля над ними. Сами задачи на первом этапе планируем выполнять по расписанию, например, каждый час. Это позволит избавиться большой части неконтролируемых ручных изменений и будет каждый час приводить систему к описанному состоянию.

Структура репозитория jjb-core:

Каждая директория содержит описание Jenkins job состоящее из двух файлов.

Yaml файл описывает шаблон jenkins job имеет следующее наполнение:

---
- job:  # Создаем директорию CORE
    name: CORE
    project-type: folder

- job:  # Создаем поддиректорию ad-core-automation в CORE
    name: CORE/ad-core-automation
    project-type: folder

# Описание темплэйта
- job-template:
    name: 'CORE/ad-core-automation/{name}-{project_key}'
    project-type: pipeline
    job_description: Упралвение OU и SG для {project_key}

    # Defaults
    GIT_BRANCH: master
    GIT_CRED_ID: jenkins-ad-integration

    triggers:
        - timed: 'H(0-59) * * * *'

    parameters:
        - string:
            name: GIT_BRANCH
            default: '{GIT_BRANCH}'
            description: Git ref (branch/tag/SHA)
        - string:
            name: GIT_CRED_IDjenkins
            default: '{GIT_CRED_ID}'
            description: Jenkins credentials ID for BitBucket
        - string:
            name: META_LOCATION
            default: 'DEV/{project_key}/{project_key}_meta.yaml'
            description: Meta file location if CORE/meta repository

    dsl: !include-raw-escape: ./ad-core-automation.groovy

- project:
    name: ad-core
    project_key:
        - project1
        - project2
        - project3
    jobs:
        - 'CORE/ad-core-automation/{name}-{project_key}'

Файл groovy — это простой jenkinsfile:

Автоматизация atlassian bitbucket

Для концепта достаточно будет автоматизировать создание проекта и предоставление привилегий к нему.

Часть содержимого project1_meta.yaml, которая отвечает за Bitbucket:

...
  bitbucket:
    name: project1-bitbucket-project # Это не project key!
                                                     # project_key получается из имени файла
    description: "Описание проекта в свободной форме"
    privileges:
      <<: *global_privileges

Это все, что потребуется при заведении нового проекта. Project key будет взят из названия yaml файла (в данном примере — project1).

Как это выглядит в UI:

Пример скрипта

Автоматизация microsoft ad

Active Directory используется во многих организациях. Большое количество рабочих процессов организаций начинаются именно с него. У нас в Мир Plat.Form все сотрудники имеют учетные записи в AD и включены в различные группы.

За AD отвечает подразделение инфраструктуры. Для наших нужд была выделена техническая учетная запись (ТУЗ), которой делегировано управление одним из Organization unit (OU). Именно в нем с помощью простой автоматизации мы будем создавать группы и наполнять их пользователями.

Часть содержимого project1_meta.yaml, которая отвечает за AD:

Автоматизация sonatype nexus3 oss

Что такое Nexus?
 Nexus — это менеджер репозиториев, позволяющий обслуживать разные типы и форматы репозиториев через единый интерфейс (Maven, Docker, NPM и другие). 

На момент написания статьи версия была OSS 3.25.1-04

Почему именно Nexus?

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

Процесс хранения артефактов является важным при проектировании конвейера тестирования и развертывания.

Что потребуется автоматизировать?

BlobstoreВсе двоичные файлы, загружаемые через proxy репозитории (мы не предоставляем прямого доступа к интернет репозиториям, используем исключительно прокисрование через nexus), опубликованные в hosted (локальные репозитории) репозитории хранятся в хранилищах Blob-объектов, связанном с репозиторием.

UI Blob stores:

Как мы видим, по умолчанию нам уже доступно хранилище default. Из информации выше мы можем понять, что данный blob находится на диске и ему доступен весь объем дискового раздела, на котором находится директория sonatype-work.

Проблематика

В целом, все логично, но есть минимум две проблемы, о которых следует задуматься:

1. В случае, если все репозитории будут привязаны к одному blob, у нас могут появиться проблемы с тем, что хранилище может побиться.
2. Если мы предполагаем, что наш Nexus будет использоваться несколькими командами разработки, то стоит сразу задуматься о том, что в некоторых ситуациях чрезмерная генерация артефактов может забить весь раздел и проблема будет не только у команды, которая генерирует большой объем артефактов, но и у других команд.

Простое решение

Первое, что приходит в голову — это создание отдельных blob stores. Очевидно, это не решает проблему расположения на одном дисковом разделе. Подходящим решением является “нарезать” разделы для каждого проекта. Забегая вперед, это решит еще и вопрос мониторинга и отправки уведомлений ответственным за проект.

UI создания Blob stores:

Nexus позволяет настроить Soft quota, штука сомнительная. Она уведомляет о том, что с местом что-то не так, но не производит каких-либо действий. При правильном применении шагов, описанных выше, удается добиться большего функционала (Появляется простой способ отслеживания объема и обращений к диску, а переполнение не создает неприятности “соседям”).

В поле path мы можем указать раздел, который примонтирован, например, как nfs.Что позволяет держать раздел непосредственно на сетевом хранилище. Это может снизить скорость, но дает ряд преимуществ с точки зрения простоты. 

Nexus у нас запускается в Docker, для этого используется compose файл. Для подключения новых точек монтирования, простым решением будет добавить в compose файле монтирование родительского каталога точек монтирования.

Пример docker-compose:

version: "3"

services:
  nexus3:
    container_name: nexus3
    image: sonatype/nexus3:3.27.0
    ports:
      - 8443:8443
      - 50011:50011 # project1-docker-releases
      - 20012:50012 # project2-docker-releases
    volumes:
      - /nexus/sonatyep-work:/nexus-data
      - /mnt-blobs:/mnt-blobs
      - /etc/timezione:/etc/timezone
      - /etc/localtime:/etc/localtime
    logging:
      driver: "json-file"
      options:
        max-size: "10m"
        max-file: "10"

RepositoriesNexus позволяет создавать репозитории почти всех распространенных форматов. Если идти в сторону идеального хранения, то целесообразно для каждого проекта создавать минимум release и snapshot репозиторий, хотя идеальный вариант может содержать еще и release-candidat репозиторий. Это позволит настроить удобный механизм чистки репозиториев.

Определенно, release репозиторий должен во многих случаях иметь максимальную глубину хранения, как требование, в релизах не должно оказаться “мусора”. Напротив, с репозиториями snapshot мы должны иметь возможность очищать без опасений в любое удобное время и без рисков.

Ко всем форматам репозиториев доступ осуществляется по 80 и/или 443 портам, за исключением docker. Репозиторий Docker, для доступа к нему, должен иметь персональный порт. Это приводит к некоторым сложностям. Каждый раз публикуя новый порт, мы должны добавлять его публикацию в compose файле.

LDAPNexus имеет возможность реализации подключения к LDAP и использования его в качестве аутентификации пользователей. В нашем случае мы используем группы пользователей для предоставления прав.

RolesДля удобства роли создаются под проект, лучше идти от минимума, и для себя мы выбрали три роли для каждого проекта:qa — обладают правами достаточными для readdevelopers — read, writeowners — read, write, deleteГруппы из AD матчатся в локальные группы Nexus.

APIНачиная с версии Nexus OSS 3.19 появилось весьма удобное API для управления Nexus, это значимое нововведение, которое многие пользователи ждали позволит нам управлять Nexus и приводить его в нужное состояние.

Swagger UI API:

На момент написания статьи API, по большей части, в статусе beta, но не смотря на это, работает без больших проблем и позволяет автоматизировать почти все необходимое.

Часть содержимого project1_meta.yaml, которая отвечает за nexus:

Автоматическая заливка

Возвращаемся к проекту test-package. Файл build.sbt редактируем как-то так:

Если вы хотите заливать -SNAPSHOT и релизные версии артефакта в разные репозитории, тут написано, как это настроить.

Все credentials мы уже настроили на шаге про использование Nexus в роли прокси. Поэтому просто говорим sbt publish. Будет залит обычный jar’ник, а также javadoc и sources.

Во втором проекте, который зависит от test-package, изменяем build.sbt:

Обратите внимание, что теперь используется два знака процента, а не один. То есть, при заливке sbt автоматически указал имя артефакта test-package_2.11, как, собственно, и принято в мире Scala. Проверяем, что все собирается.

Также SBT поддерживает кросс-сборку. То есть, в одном проекте можно собирать артефакт для нескольких версий языка Scala. Например, чтобы артефакт собирался для Scala 2.10 и 2.11, в build.sbt нужно дописать:

crossScalaVersions := Seq(“2.10.5”, “2.11.6”)

Тестирование, сборка и публикация всех версий артефакта:

sbt ‘ test’sbt ‘ package’sbt ‘ publish’

Бывает так, что нужно использовать немного разные версии библиотек или флаги компилятора в зависимости от версии Scala. Это делается примерно так:

scalacOptions ={CrossVersion.partialVersion(scalaVersion.value)match{case Some((2, 11))=>

Seq(“-Ywarn-infer-any”)case_=> Seq.empty}}

Нужно отметить, что перед sbt publish не лишним будет делать sbt publish-local для «заливки» артефакта в кэш, протестировать, что все ОК, и только потом заливать артефакт в репозиторий.

Генерация ключей

После установки пакета pinentry, можно приступать к созданию ключей:

gpg –gen-key

Заполняем поля, вводим O и нажимаем Enter. Далее нужно будет ввести 2 раза пароль, для генерации ключа. Копируем ID, который был сгенерирован 6C44AA9D06EA1B2E805C90FF6935F7FB57FFEF6F. Создаём открытый ключ:

gpg –armor –output public.gpg.key –export 6C44AA9D06EA1B2E805C90FF6935F7FB57FFEF6F

Создаём закрытый ключ:

gpg –armor –output private.gpg.key –export-secret-key 6C44AA9D06EA1B2E805C90FF6935F7FB57FFEF6F

Здесь нужно будет ввести пароль, который вводили при генерации ID.

Выводим содержимое файла, который был сгенерирован при создание закрытого ключа. Копируем содержимое файла.

cat private.gpg.key

Использование nexus как прокси

Чтобы все артефакты качались через Nexus, создаем файл ~/.sbt/repositories такого содержания:

Настраиваем приложение

Теперь переходим к pom.xml приложения.

В секцию properties добавляем версии плагинов и URL нексуса.

Особенности

Проверка зависимостей на уязвимости перед вводом новых компонентов в цепочку разработки

• Модуль Nexus Firewall предотвращает ввод уязвимых компонентов в процесс разработки. Вы получаете инструмент автоматического контроля поступающих в вашу среду разработки внешних компонентов исходя из общих факторов риска – таких как уязвимости, возраст, популярность и лицензионные данные. С Nexus вы предотвратите разработку приложений, использующих нежелательные или неодобренные зависимости.

Результат и развитие

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

На текущий момент описанный PoC перешел в стадию промышленной эксплуатации и претерпел значительные доработки. Мы переписали core систему автоматизации, к которой в виде плагинов подключаются модули для автоматизации новых сервисов. Появились тесты.Всего автоматизацией обслуживается около 50 проектов и подключаются новые. Планируем тиражирование в другие сетевые сегменты.

Резюме

Теперь у вас есть возможность повторно использовать приватные Android библиотеки в проектах. Жду замечаний!

Надеюсь вы не зря потратили своё время, спасибо!

Сборка артефакта и его заливка вручную

Создаем новый Scala-проект, как мы это уже много раз делали, пишем код в таком стиле:

Говорим:

sbt package

В итоге получим файл target/scala-2.11/test-package_2.11-0.1.jar или вроде того. Заливаем артефакт в Nexus в последний созданный репозиторий через вкладку Artifact Upload. Указываем Group, Artifact, Version.

Заводим еще один проект, в коде пишем:

import me.eax.test._object Example extends App {TestPackage.test()}

В файл build.sbt дописываем:

Собираем, проверяем, что все работает.

Еще есть команды sbt package-doc и sbt package-src. Как можно без труда догадаться, они собирают jar’ники с документацией и исходниками.

Заливать артефакты вручную неудобно и чревато ошибками. Поэтому ниже будет показано, как автоматизировать заливку. Но сначала нам потребуются кое-какие дополнительные знания, которые проще всего получить, рассмотрев работу Nexus в качестве прокси.

Установка зависимостей

Первое что нужно сделать, это подключиться к docker-контейнеру с оболочкой bash:

docker exec -it -u 0 nexus bash

После этого нужно установить пакет pinentry, для того, чтобы можно было дальше сгенерировать ключи для apt репозитория:

yum -y install pinentry

Установка и базовая настройка

Все описанные ниже шаги были проверены в Ubuntu Linux 14.04 LTS, но, по идее, будут верны и для других версий Ubuntu, а также мало отличаться для других дистрибутивов Linux.

Готового deb-пакета с Nexus нет, но, к счастью, руками он устанавливается не сложно. На машине должна быть установлена виртуальная машина Java. Не так давно, в заметке, посвященной Cassandra, мы выясняли, как она ставится:

sudoadd-apt-repository ppa:webupd8team/javasudoapt-get updatesudoapt-get install oracle-java8-installersudoapt-get install oracle-java8-unlimited-jce-policy

Далее качаем архив с Nexus и распаковываем его в /usr/local:

Шаг 1. подготовка

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

Шаг 2. установка и настройка nexus

Скачанный архив достаточно распаковать там, где вам удобно. После чего можно запускать программу и начинать работать. Для долгосрочного и удобного использования нужно зарегистрировать Nexus как службу и запускать её при старте ОС. Как это сделать — достаточно понятно

. В нашем же случае достаточно перейти в папку ”

nexus-3.12/bin/

” и запустить из командной строки файл nexus.

В случае c Windows:

nexus.exe /run

В случае с Unix:

./nexus run

В результате вы должны увидеть оповещение об успешном старте, выглядит оно примерно так:

Пришло время проверить работоспособность Nexus. Для этого достаточно перейти по ссылке

Шаг 3. создание и публикация android библиотеки

Создаём Android проект, назовём его «TestLibrary». Далее в «Project View» нажимаем на корень проекта правой кнопкой мыши выбираем «New» и «Module». В открывшемся окне выбираем «Android library» и называем библиотеку «HelloLibrary». В итоге вы увидите рядом с модулем «app» модуль нашей новой библиотеки.

Добавим в библиотеку класс с функцией приветствия:

package com.example.nexus.hellolibrary

fun helloFromOurLibrary() {
    println("### Hello World! This is our new Android library!")
}

Библиотека готова, пора публиковать. В «Project view» в модуль «hellolibrary» добавляем файл и называем его «publisher.gradle». В нём будет храниться скрипт для публикации библиотеки.

Шаг 4. использование зависимостей из nexus

Для теста предлагаю создать ещё один пустой Android проект.

Для начала подключим репозиторий к проекту, просто добавив данные в «build.gradle» файл уровня проекта:

Заключение

Немного ссылок по теме:

А куда вы заливаете артефакты?

Метки: Linux, Scala, Разработка, Функциональное программирование.