Непрерывная интеграция с JBoss Fuse, Jenkins и Nexus

Недавно я собирал быстрый проект Maven, чтобы показать возможный подход к организации проекта JBoss Fuse .

Проект доступен на Github здесь: https://github.com/paoloantinori/fuse_ci

И это небольшая эволюция того, что я узнал, работая с моим другом Джеймсом Роулингсом

Проект предлагает способ организации вашей кодовой базы в мультимодульном проекте Maven.

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

В папке ci вы найдете подпапки, такие как features или karaf_scripts с файлами, которые вы, вероятно, в конечном итоге karaf_scripts в каждом проекте, и с встроенными комментариями, которые помогут вам с настройкой и настройкой в соответствии с вашими конкретными потребностями .

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

В этом посте я покажу вам, как развернуть этот пример проекта в очень типичной среде разработки, в которую входят JBoss Fuse , Maven , Git , Nexus и Jenkins .

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

Я не хочу, чтобы вы проповедовали на эту тему или пытались рассказать вам, что они должны делать. Мне нравится доверять им и полагать, что они знают свои приоритеты проекта и что они приняли компромисс между доступным временем, отставанием и дополнительными общими преимуществами каждого вида деятельности. Точно так же мне нравится верить, что мы все согласны с тем, что для больших и длинных проектов оптимальная практика CI, безусловно, обязательна, и что никто не должен спорить об их ценности.

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

Я не буду покрывать пошаговые инструкции. Но чтобы доказать вам, что все это работает, я создал bash-скрипт, использующий Docker , который продемонстрирует, как можно легко создавать сценарии и, что более важно, они действительно работают!

Если вы хотите перейти прямо до конца, скрипт доступен здесь:

https://github.com/paoloantinori/fuse_ci/blob/master/ci/deploy_scripts/remote_nexus.sh

Он использует некоторые образы Docker, которые я создал и опубликовал в качестве доверенных сборок на Docker Index :

https://index.docker.io/u/pantinor/fuse/

https://index.docker.io/u/pantinor/centos-jenkins/

https://index.docker.io/u/pantinor/centos-nexus/

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

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

Давайте начнем с описания компонента нашего примера установки Continuous Integration :

1. JBoss Fuse 6.1

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

2. нексус

Это программное обеспечение, которое мы используем для хранения двоичных файлов, которые мы производим из нашей базы кода. К нему обращается JBoss Fuse , который загружает с него артефакты, но также к нему обращается Jenkins , который публикует двоичные файлы на нем, как последний шаг успешного задания сборки.

3. Дженкинс

Это наш создатель рабочих мест . Он публикует свои выходные данные в Nexus и создает свои выходные данные, если код, который он извлек с помощью Git, успешно собирается.

4. Git Server

Это держатель удаленного хранилища кода . Дженкинс получил доступ к нему, чтобы загрузить самую последнюю версию кода, который мы хотим построить, и он заполняется всеми разработчиками, когда они делятся своим кодом и когда они хотят построить на сервере Continous Integration. В нашем случае git server — это просто файловая система, доступ к которой осуществляется через ssh .

http://yuml.me/edit/7e75fab5

мерзавец

Первое, что нужно сделать, это настроить git для управления исходным кодом ( SCM ).
Как вы можете догадаться, мы могли бы использовать любое другое подобное программное обеспечение для выполнения этой работы, от SVN до Mercurial, но я предпочитаю git поскольку это один из самых популярных вариантов, а также потому, что это официально поддерживаемый инструмент для непосредственного взаимодействия с конфигурацией Fabric8.
У нас нет больших требований для git . Нам просто нужна файловая система для хранения нашего общего кода и транспортная служба, которая позволяет получить доступ к этому коду.
Для простоты я решил использовать SSH в качестве транспортного протокола .
Это означает, что в окне, в котором будет храниться код, нам нужен только запущенный демон sshd , некоторый действительный пользователь и папка, к которой он может получить доступ.
Что-то типа:

Хотя единственный конкретный шаг для git — это инициализация git репозитория

нексус

Nexus OSS — менеджер хранилища, который можно использовать для хранения артефактов Maven.
Он реализован как веб-приложение на Java. По этой причине установка Nexus особенно проста .
Благодаря встроенному экземпляру Jetty, который расширяет его возможности, нужно всего лишь извлечь архив дистрибутива и запустить двоичный файл:

После запуска Nexus будет доступен по умолчанию на этой конечной точке: http: // your_ip / 8081 / nexus с admin качестве пользователя и admin123 качестве пароля.

Дженкинс

Дженкинс — это планировщик работы, который мы собираемся использовать для создания нашего проекта. Мы хотим настроить Jenkins таким образом, чтобы он мог напрямую подключаться к нашему git репо для загрузки исходного кода проекта. Для этого нам понадобится дополнительный плагин Git Plugin . Нам, очевидно, также нужны java и maven установленные на коробке. Поскольку конфигурация Jenkins состоит из различных этапов, включающих взаимодействие с несколькими административными страницами, я лишь дам несколько советов о важных этапах, которые необходимо выполнить. По этой причине я настоятельно рекомендую вам проверить мой полностью автоматизированный скрипт, который делает все в полной автоматизации . Как и Nexus, Jenkins реализован как веб-приложение на Java. Поскольку мне нравится использовать RHEL- совместимый дистрибутив, такой как Centos или Fedora , я устанавливаю Jenkins в упрощенном виде . Вместо того, чтобы извлекать архив вручную, как мы это делали для Nexus, я просто определяю новый репозиторий yum и позволяю yum выполнять установку и настройку как сервис для меня:

После запуска Jenkins вы найдете его веб-интерфейс, доступный здесь: http: // your_ip: 8080 /
По умолчанию он настроен в однопользовательском режиме, и этого достаточно для нашей демонстрации. Вы можете проверить http: // your_ip: 8080 / configure, чтобы проверить, хорошо ли выглядят значения для JDK, Maven и git. Обычно они автоматически выбираются, если у вас уже установлено программное обеспечение до Jenkins. Затем вам необходимо установить Git Plugin : http: // your_ip: 8080 / pluginManager

Как только вы все настроите и после перезапуска экземпляра Jenkins, мы сможем увидеть новую опцию в форме, которая позволяет нам создавать задания сборки Maven. Под разделом: Управление исходным кодом теперь есть опция git . Это просто вопрос предоставления координат вашего SSH-сервера, например:

А в разделе « Сборка» в разделе « Цели и параметры» нам необходимо явно указать Maven, что мы хотим запустить фазу deploy , предоставив IP-адрес Nexus insance:

Последний шаг настройки — указать другой файл настроек maven в расширенных свойствах maven , который хранится вместе с исходным кодом:

https://github.com/paoloantinori/fuse_ci/blob/master/my_settings.xml

И это содержит имя пользователя и пароль для представления в Nexus, при отправке артефактов туда.

Настройка завершена, но нам нужен дополнительный шаг, чтобы Jenkins работал с Git .

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

Чтобы избежать всего этого, уловка заключается в том, чтобы подключиться к jenkins Jenkins через SSH, стать пользователем, который используется для запуска процесса Jenkins, в моем случае — jenkins , и оттуда вручную подключиться к серверу ssh git для выполнения операции идентификации. в интерактивном режиме, так что это больше не потребуется в будущем:

Альтернативный подход, который я использую в своем образе док-станции Jenkins, состоит в том, чтобы полностью отключить идентификацию отпечатка пальца SSH , подход, который может быть слишком небезопасным для вас:

Если все настроено правильно, Jenkins сможет автоматически загрузить наш проект, собрать его и опубликовать на Nexus.

Но…

Перед тем, как сделать это, нам нужен разработчик, который отправит наш код в git, иначе не будет никакого исходного файла для сборки! Для этого вам просто нужно клонировать мое репо, настроить дополнительное удаленное репо (наш частный сервер git) и нажать:

На этом этапе вы можете запустить задание сборки на Jenkins. Если вы запускаете его впервые, Maven загрузит все зависимости, так что это может занять некоторое время . если все пройдет успешно, вы получите подтверждение того, что ваши артефакты были опубликованы в Nexus.

JBoss Fuse

Теперь, когда наш сервер Nexus заполнен артефактами maven, созданными из нашей базы кода, нам просто нужно указать нашему экземпляру Fuse использовать Nexus в качестве удаленного репозитория Maven. Обучает нас, как это сделать: в оболочке karaf нам нужно изменить значение свойства,

И теперь мы можем убедиться, что интеграция завершена с помощью этой команды:

Если все в порядке, вы увидите вывод, похожий на этот:

Это означает, что karaf сценарием karaf предоставляющим координаты Maven, работала хорошо, и теперь вы можете использовать shell:source , osgi:install или любую другую команду, которая требует артефактов, опубликованных на Nexus.

Вывод

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