JBoss Fuse — это мощная платформа распределенной интеграции со встроенными функциями для централизованного управления конфигурацией, обнаружения служб, управления версиями, шлюза API, балансировки нагрузки, отработки отказа и т. Д. Для развертываний микросервисов, ориентированных на интеграцию. JBoss Fuse 6.x построен поверх открытого проекта Fabric8 1.x. В этом сообщении блога показано, как использовать мощную автоматизацию, уже встроенную в Fuse, для создания пути миграции ваших приложений для достижения непрерывной доставки, если это необходимо.
Существует пример проекта, на который этот блог ссылается: https://github.com/christian-posta/fuse-fabric-promotion-build.
Что Fabric8 привносит в процесс автоматизации
Fabric8 1.x предоставляет простую модель группировки и подготовки во время выполнения, позволяющую вам быстро развертывать и обновлять / понижать качество ваших приложений с центральной панели мониторинга / консоли на множестве машин. Для этого вам не нужно настраивать скрипты / ansible / chef / puppet, так как автоматизация поставляется из коробки с Fuse / Fabric8.
Центральным понятием является набор текстовых файлов свойств, называемых профилями, которые декларативно описывают конечное состояние развертывания, т. Е. Они описывают, какие двоичные файлы, функции, конфигурации, зависимости и т. Д. Необходимо развертывать вместе. Профили имеют версии (для обеспечения непрерывного обновления) и могут иметь иерархические отношения для сокращения дублирования конфигураций.
Проблема
В общей среде, где у вас есть несколько команд, работающих над разными интеграциями / микросервисами / приложениями, у каждого из которых есть свои временные рамки, цикл развертывания или уже существующие циклы непрерывной интеграции, развертывание в общей среде может привести к коллизиям. Мы должны установить соглашение о том, как приложения попадают в эту среду, и быть в состоянии автоматизировать его / создать версию. Один из клиентов Continuous Delivery — версия, включающая в себя все, включая конфигурацию приложения, конфигурацию среды, сценарии автоматизации и т. Д., Чтобы при необходимости можно было воссоздавать среды на лету и избегать сред с индивидуальной настройкой вручную, которые в итоге становятся очень хрупкими и рискованными.
С профилями Fuse / Fabric8 все поддерживается версиями во встроенном бэкэнде управления конфигурацией Fuse / Fabric8, но как их можно воссоздать или как эти профили можно развернуть в Fuse при изменении приложений? И как мы можем сделать это в рамках ограничений приложений, развертываемых с разной скоростью, разных версий, разных циклов и т. Д.?
Решение
В Fabric8 встроена большая часть автоматизации, и в этом руководстве мы постараемся показать, как ее лучше всего использовать. Когда вы увидите, что можно автоматизировать, вы скажете «ах, поэтому мне не нужны все эти другие скрипты / инструменты для этого»? Давайте рассмотрим шаг за шагом. В центре внимания этого руководства будет fabric8 1.x, но более конкретно JBoss Fuse Fabric 6.1 или 6.2. Некоторые из готовых функций (я укажу их в дальнейшем) доступны только в версиях Fuse 6.2, но все же могут быть реализованы в среде Fuse 6.1 (хотя и с некоторыми сценариями)
fabric8-Maven-плагин
Предохранитель 6.1 / 6.2
Плагин fabric8-maven-plugin поставляется с предохранителем 6.1 . Он подключается к жизненному циклу Maven Maven с помощью нескольких строк конфигурации в pom.xml вашего проекта. Он предоставляет одну цель (следующий раздел) в Fuse 6.1 и добавляет дополнительные цели в Fuse 6.2.
Автоматизировать создание профилей
Предохранитель 6.1 / 6.2
Если вы посмотрите на примеры проектов / модулей в этом репозитории ( модуль EIP или модуль REST ), вы увидите, что в файле pom.xml есть раздел <build>
который настраивает fabric8-maven-plugin . Например, в модуле REST:
01
02
03
04
05
06
07
08
09
10
|
< plugin > < groupId >io.fabric8</ groupId > < artifactId >fabric8-maven-plugin</ artifactId > < version >${fabric8.maven.plugin.version}</ version > < configuration > < profile >my-rest</ profile > < features >fabric-cxf-registry fabric-cxf cxf war swagger</ features > < featureRepos >mvn:org.apache.cxf.karaf/apache-cxf/${version:cxf}/xml/features</ featureRepos > </ configuration > </ plugin > |
Это автоматически создаст профили fabric8 для этого проекта. Если вы запустите mvn fabric8:deploy
он установит профили в локально работающую fabric8. Это очень полезная цель времени разработки для проверки правильности создания профилей. (Обратите внимание, что вы должны правильно настроить файл ~ / .m2 / settings.xml, чтобы использовать un / pw для вашего фабричного сервера. По умолчанию идентификатор сервера, который он будет искать, — fabric8.upload.repo )
Автоматическое архивирование ваших профилей
Предохранитель 6.2
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
20
21
|
< plugin > < groupId >io.fabric8</ groupId > < artifactId >fabric8-maven-plugin</ artifactId > < version >${fabric8.maven.plugin.version}</ version > < configuration > < profile >my-rest</ profile > < features >fabric-cxf-registry fabric-cxf cxf war swagger</ features > < featureRepos >mvn:org.apache.cxf.karaf/apache-cxf/${version:cxf}/xml/features</ featureRepos > </ configuration > < executions > < execution > < id >fabric8-zip</ id > < phase > package </ phase > < goals > < goal >zip</ goal > </ goals > </ execution > </ executions > </ plugin > |
С этой конфигурацией вы также заметите, что по умолчанию цель zip
будет прикреплена к фазе сборки. Это доступно только в версии плагина Fuse 6.2 (см. Версии, используемые в этом проекте). Цель zip
создаст профили и объединит их в один дистрибутив, который можно загрузить в репозиторий maven. Так, например, как часть шага в процессах непрерывной интеграции, вы можете создать этот zip
файл и поместить его в репозиторий maven вместе с двоичными файлами для вашего проекта. Таким образом, у вас есть и двоичные файлы, и профили Fabric, развернутые в одном репозитории артефактов. Например, если вы запустите mvn clean install
из корня модуля REST в этом проекте, вы можете увидеть zip профиля в папке ./target, а также соответствующее расположение в ~ / .m2 / repository.
Независимое управление версиями
В вашей среде у вас может быть несколько приложений и развертываний. У каждого будет свой номер версии и жизненный цикл. Fuse также имеет встроенные версии профилей для развертывания обновленных приложений или понижения версии приложений. Fuse Fabric имеет следующие две концепции управления версиями профилей:
- Наборы версий
- Git поддерживает управление изменениями
Когда мы разворачиваем наши приложения, нам нужно выровнять различные независимые версии приложений с набором версий Fuse Fabric. Так, например, в нашем проекте у нас есть проект EIP и проект REST. Проект EIP имеет версию 2.0
а проект REST — 1.5
. Итак, как мы можем ввести эти две версии приложений и их профили в Fabric?
Среда сборки
Предохранитель 6.2
Мы используем единую сборку среды для объединения отдельных проектов, которые будут иметь профили, которые необходимо добавить в реестр Fuse Fabric. Если вы посмотрите на файл pom.xml проекта среды сборки, вы увидите что-то вроде этого:
01
02
03
04
05
06
07
08
09
10
11
12
13
14
|
< dependency > < groupId >com.redhat.demo.promotion</ groupId > < artifactId >eip</ artifactId > < version >2.0</ version > < type >zip</ type > < classifier >profile</ classifier > </ dependency > < dependency > < groupId >com.redhat.demo.promotion</ groupId > < artifactId >rest</ artifactId > < version >1.5</ version > < type >zip</ type > < classifier >profile</ classifier > </ dependency > |
Вы можете видеть, что различные профили, составляющие разрозненные приложения, добавляются как зависимости, и они представляют собой zip-файлы, которые классифицируются как «профиль», которые будут просматриваться в репозитории maven. Поэтому, если вы использовали цель zip
сверху и установили профили в свой репозиторий maven, вы можете ссылаться на них в сборке среды, как описано выше.
Ключевым моментом здесь является то, что у fabric8-maven-plugin есть цель под названием branch
которая будет выполнять следующее:
- Подключитесь к существующему репозиторию Fuse Fabric git и скопируйте существующий филиал в новый.
- Получите вышеуказанные zip-зависимости от maven
- Разархивируйте и объедините новые профили в Git-репо из ткани.
- Зафиксируйте изменения
- При желании перенести новую ветку обратно в Fabric
Для этого требуется Fuse 6.2 fabric8-maven-plugin, но он работает против существующей установки Fuse 6.1 или Fuse 6.2.
Конфигурация для цели branch
выглядит следующим образом:
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
20
21
|
< plugin > < groupId >io.fabric8</ groupId > < artifactId >fabric8-maven-plugin</ artifactId > < version >${fabric8.maven.plugin.version}</ version > < executions > < execution > < id >branch</ id > < phase >compile</ phase > < goals > < goal >branch</ goal > </ goals > < configuration > <!-- lets choose the name of the version in the git repository where we will create the branch --> < branchName >1.0.1</ branchName > < oldBranchName >1.0</ oldBranchName > < pushOnSuccess >true</ pushOnSuccess > </ configuration > </ execution > </ executions > </ plugin > |
Вы указываете в файле pom.xml (или в командной строке), что такое branchName
(новая ветвь) и нужно ли pushOnSuccess
. Если вы указываете на существующий работающий предохранитель и запускаете:
1
|
mvn compile |
Предохранитель должен автоматически выполнить описанные выше шаги и протолкнуть профили, как ожидается.
ПРИМЕЧАНИЕ: я только недавно внес некоторые исправления в fabric8, чтобы все работало, как описано, как было несколько ошибок ранее. Пожалуйста, дождитесь следующих ранних выпусков Fuse 6.2, чтобы воспользоваться этими функциями, как описано здесь
Ссылка: | Миграция профиля Fuse Fabric для непрерывной доставки от нашего партнера JCG Кристиана Поста в блоге |