Несмотря на ударные темпы распространения платформ оркестрации контейнеров, вроде Kubernetes или Red Hat OpenShift, подавляющее большинство Java-нагрузок в мире по-прежнему выполняются на виртуальных машинах или на «голом железе». Однако перенос корпоративных нагрузок, и в частности, приложений Red Hat JBoss Enterprise Application Platform (EAP), в облако рано или поздно состоится, и OpenShift представляется здесь естественным выбором. Сегодня мы вкратце ответим на типовые вопросы, которые возникают при таком переходе, и покажем на примере, как он производится.
После того, как образ приложения создан, есть несколько способов развернуть его на платформе OpenShift, например, шаблоны, или механизм Helm chart, или Kubernetes-операторы. Мы рекомендуем использовать для этого оператор JBoss EAP Operator, который был специально разработан, чтобы упростить целый ряд задач при развертывании приложений EAP. Этот Оператор поддерживает вещи, критически важные для приложений корпоративного уровня, такие как восстановление транзакций и удаленные вызовы Enterprise Java Bean (EJB). С этим оператором развертывание приложения зачастую сводится к определению образа и заданию количества развертываемых инстансов.
Чтобы вы могли понять, понадобится ли дорабатывать код приложения, Red Hat предлагает специальный миграционный инструментарий для приложений. Он анализирует Java-приложения и определяет, насколько они пригодны для миграции на различные целевые платформы, включая контейнеры. Инструментарий миграции можно запускать из веб-интерфейса (см. Рис. 1), из командной строки, с помощью плагина Maven или расширения для IDE. Этот инструмент можно использовать для анализа приложений, которые надо контейнеризировать, и получить все обязательные или рекомендуемые доработки в виде отчета.
Рис. 1. Графический интерфейс миграционного инструментария для приложений предлагает несколько вариантов целевых платформ, включая контейнеризацию.
Кроме того, есть целый ряд инструментов, разрабатываемых в рамках open-source проекта Konveyor, которые помогают осуществить миграцию рабочих нагрузок на Kubernetes. Помимо инструментов для рехостинга имеющихся контейнерных приложений, рехостинга виртуальных машин и миграции приложения на Kubernetes, проект Konveyor также предоставляет инструменты для управления портфелем корпоративных приложений и контроля того, как протекают процессы доставки ПО, за счет сбора и анализа метрик поведения команд и организации на продолжительном отрезке времени.
Примечание: проект Konveyor развивается силами сообщества и не обеспечивается поддержкой Red Hat.
Теперь рассмотрим процесс миграции на примере.
$ cd kitchensink && mvn clean package
В результате, в папке kitchensink/target создается файл kitchensink.war
Рис. 2. На странице Create project вводим имя проекта: «kitchensink».
Затем щелкаем Next и в открывшейся форме загружаем файл для анализа kitchensink.war:
Рис. 3. В поле Add applications загружаем файл kitchensink.war.
Щелкаем Next и выбираем тип анализа. В данном случае нас интересует только контейнеризация:
Рис. 4. В качестве целевой платформы выбираем Containerization.
Щелкаем Next и попадаем на страницу Select Packages. Здесь выбираем пакет org и добавляем его в список «Included packages»:
Рис. 5. На странице Create project выбираем пакет «org».
Просто пролистываем три следующие страницы, поскольку не добавляем никаких пользовательских правил, меток и опций, и попадаем на страницу Review project details:
Рис. 6. На странице Review project details видим наше приложение kitchensink и добавленный пакет «org».
Щелкаем Save and run, чтобы запустить анализ. Через несколько секунд анализ завершается, и мы попадаем на страницу Analysis Results:
Рис. 7. Страница результатов анализа.
Щелкаем значок маленькой гистограммы в столбце Actions, чтобы просмотреть отчет, и попадаем на страницу Application List, где указан файл kitchensink.war:
Рис. 8. После выполнения анализа, на странице Application List отображаются миграционные требования.
На этой странице мы видим, что дела обстоят неплохо: ноль сюжетных точек и всего пять информационных элементов. Щелкаем ссылку kitchensink.war, чтобы просмотреть детали, и видим, что, как и было сказано, для контейнеризации этого приложения код дорабатывать не надо:
Рис. 9. Информационная панель показывает, сколько предупреждений было сгенерировано при анализе приложения.
Итак, с помощью миграционного инструментария для приложений мы убедились, что наше приложение подходит для контейнеризации и развертывания на OpenShift.
modules
└── com
└── mysql
└── main
└── module.xml
└── mysql-connector-java-8.0.26.jar
Файл module.xml имеет следующее содержание:
<?xml version="1.0" ?>
<module xmlns="urn:jboss:module:1.1" name="com.mysql">
<resources>
<resource-root path="mysql-connector-java-8.0.26.jar"/>
</resources>
<dependencies>
<module name="javaee.api"/>
<module name="sun.jdk"/>
<module name="ibm.jdk"/>
<module name="javax.api"/>
<module name="javax.transaction.api"/>
</dependencies>
</module>
При запуске JBoss EAP читает этот файл и добавляет в систему модуль com.mysql.
При создании репозитория мы выполняем следующую команду с помощью интерфейса командной строки Jboss, чтобы добавить драйвер:
/subsystem=datasources/jdbc-driver=mysql:add(driver-name=mysql,driver-module-name=com.mysql)
И еще одна команда для создания источника данных, подключенного к локальному экземпляру MySQL:
$ data-source add --name=mysql --jndi-name=java:/jdbc/mysql --driver-name=mysql --connection-url=jdbc:mysql://127.0.0.1:3306/books --user-name=root --password=root
modules
└── com
└── mysql
└── main
└── module.xml
└── mysql-connector-java-8.0.26.jar
Чтобы использовать этот метод, создадим папку extensions, а в ней – файл drivers.env следующего содержания:
#DRIVER
DRIVERS=MYSQL
MYSQL_DRIVER_NAME=mysql
MYSQL_DRIVER_MODULE=com.mysql
MYSQL_DRIVER_CLASS=com.mysql.cj.jdbc.Driver
Теперь создадим файл install.sh:
#!/bin/bash
if [ "${SCRIPT_DEBUG}" = "true" ] ; then
set -x
echo "Script debugging is enabled, allowing bash commands and their arguments to be printed as they are executed"
fi
injected_dir=$1
source /usr/local/s2i/install-common.sh
configure_drivers ${injected_dir}/drivers.env
Когда мы запускаем сборку S2I, то указываем этот каталог в качестве источника данных для расширений, и S2I-builder запустит файл install.sh для настройки источника данных.
Источник данных фактически создается при конфигурации во время выполнения, поэтому мы проверим это при развертывании нашего приложения с помощью JBoss EAP Operator.
Здесь есть два варианта, Helm Chart и шаблон. Оба они создают одинаковые Kubernetes-объекты: конфигурации сборки, потоки образов, сервис и т.д. Однако в случае с Helm Chart развертывание выполнять необязательно, поэтому мы можем использовать Helm Chart только для создания объектов сборки. Мы будем выполнять развертывание образа с помощью оператора, поэтому Helm Chart идеально подходит для выполнения сборки.
Инструкции и объекты, необходимые для сборки и развертывания образа с помощью Helm и Оператора, находятся в репозитории eap-migration GitHub. Этот репозиторий содержит конфигурацию Helm Chart (install-helm.yml), config map для настройки соединения MySQL (eap-cm.yml), подписку JBoss EAP Operator (eap-operator.yml) и custom resource deployment сервера WildFly (eap-deploy.yml).
Теперь проверим наш репозиторий и выполним перечисленные ниже шаги, чтобы собрать и развернуть наше приложение на OpenShift.
$ oc new-project eap-kitchensink
$ oc new-app -e MYSQL_DATABASE=eap -e MYSQL_PASSWORD=demo -e MYSQL_USER=eap mysql-persistent
$ oc create secret docker-registry my-pull-secret --docker-server=registry.redhat.io --docker-username=$USERNAME --docker-password=$PASSWORD --docker-email=$EMAIL
Чтобы развернуть Helm Chart, используя эти параметры конфигурации, выполним следующую команду:
$ helm install kitchensink -f install-helm.yml http://github.com/openshift-helm-ch...oad/redhat-eap74-1.1.0/redhat-eap74-1.1.0.tgz
Теперь подождём несколько минут, пока завершатся две сборки, eap_app_build_artifacts и eap_app.
$ oc create -f eap-cm.yml
$ oc create -f eap-operator.yml
Теперь развернем инстанс приложения с помощью оператора, развернув объект сервера WildFly:
apiVersion: wildfly.org/v1alpha1
kind: WildFlyServer
metadata:
name: kitchen-sink
spec:
applicationImage: 'kitchensink:latest'
envFrom:
- configMapRef:
name: eap-config
replicas: 1
Для этого объекта надо задать лишь applicationImage, имя переменных среды контейнера config map и количество реплик, а затем выполнить команду:
oc create -f eap-deploy.yml
После того, как приложение будет развернуто, его топология появится в интерфейсе Developer UI:
Рис. 10. На странице Topology отображается приложение kitchen-sink и база БД MySQL.
Если щелкнуть маршрут, можно увидеть запущенный экземпляр приложения. На рисунке ниже показано приложение kitchen-sink с записью по умолчанию в базе данных.
Рис. 11. Наше приложение запущено и показывает одну запись в базе данных.
Как видно, EAP S2I Builder и миграционный инструментарий Red Hat для приложений делают анализ и перенос приложений на контейнерные платформы, вроде OpenShift, довольно простым делом. Оба этих инструмента можно использоваться не только автономно, как показано в этой статье, но и составе конвейеров автоматизации миграции.
habr.com
Что входит в процесс миграцит Java-приложений на OpenShift?
OpenShift – это корпоративный вариант платформы Kubernetes, которая в свою очередь является системой оркестрации контейнеров и предназначена для автоматизации процессов развертывания, масштабирования и управления приложениями. Все приложения, развертываемые в Kubernetes, должны быть контейнеризированы. Для контейнеризации необходимо создать образ, отвечающий требованиям Open Container Initiative (OCI), который будет содержать необходимую среду выполнения, все дополнительные библиотеки, а также код приложения. Red Hat предлагает специальный инструмент для создания таких образов из приложений JBoss EAP, который называется JBoss EAP Source-to-Image (S2I) Builder.После того, как образ приложения создан, есть несколько способов развернуть его на платформе OpenShift, например, шаблоны, или механизм Helm chart, или Kubernetes-операторы. Мы рекомендуем использовать для этого оператор JBoss EAP Operator, который был специально разработан, чтобы упростить целый ряд задач при развертывании приложений EAP. Этот Оператор поддерживает вещи, критически важные для приложений корпоративного уровня, такие как восстановление транзакций и удаленные вызовы Enterprise Java Bean (EJB). С этим оператором развертывание приложения зачастую сводится к определению образа и заданию количества развертываемых инстансов.
В чем преимущества переноса нагрузок JBoss EAP на OpenShift?
Их довольно много, вот лишь некоторые из основных:- Снижение операционных расходов – инструменты OpenShift, такие как JBoss EAP Operator, OpenShift Service Mesh, Tekton и Argo CD, снижает нагрузку на специалистов по эксплуатации.
- Оптимальное использование ресурсов – инструменты, входящие в состав OpenShift JBoss EAP S2I Builder, начиная с JBoss EAP версии 7.3, значительно сокращают размер образа приложения и место в памяти за счет сочетания механизмов послойной инициализации Galleon и специального образа среды выполнения JBoss EAP.
- Интегрированный мониторинг и метрики – OpenShift предлагает встроенные средства мониторинга приложений с использованием инструментария Prometheus, который ведет сбор метрик приложений JBoss EAP, работающих на OpenShift. Кроме того, используя инструмент JBoss EAP Expansion Pack (XP) MicroProfile, можно с минимумом кода сделать так, что приложения JBoss EAP будут рапортовать в OpenShift о своем состоянии.
- Улучшенный опыт разработчика – OpenShift предлагает множество полезных инструментов для разработчиков, таких как Developer UI (специальное представление работающего кластера, ориентированное на задачи разработчика), инструменты непрерывной интеграции (Tekton), а также все шаблоны микросервисов OpenShift Service Mesh, предоставляемые из коробки.
- Функционал Kubernetes – целый ряд сервисов для управления процессами сопровождения и эксплуатации рабочих нагрузок приложений, включая, управление ресурсами, мониторинг состояния приложений, диспетчеризацию нагрузок и горизонтальное масштабирование. Все это помогает более эффективно использовать ресурсы и сократить расходы.
- Дополнительные преимущества пакета Red Hat Runtimes – подписки на JBoss EAP можно бесплатно конвертировать в подписки на Red Hat Runtimes, чтобы сохранить прежний уровень поддержки JBoss EAP и получить тот же уровень поддержки для таких важных при разработке облачных приложений технологий Red Hat, как Single Sign-On, Data Grid и AMQ Broker.
Насколько сложно перенести нагрузки?
В мире корпоративных ИТ-систем все зависит от автоматизации. Перенос одной рабочей нагрузки на OpenShift выполняется очень просто, мы рассмотрим его чуть ниже. Если приложений много, то процесс потребуется автоматизировать. Однако, все операции, которые мы разберем на примере переноса одного приложения, легко можно реализовать средствами конвейеров и инструментов автоматизации.Как проверить, понадобится ли дорабатывать код?
У Red Hat довольно большой опыт в том, что касается традиционных Java-приложений и приложений JBoss EAP на платформе в Kubernetes, поэтому мы можем довольно точно, сказать, что будет хорошо работать в контейнерах. По нашему опыту, приложения JBoss EAP 7 редко требуют модификации кода при контейнеризации. Исключения бывают, например, когда есть удаленный вызов методов, но такое встречается редко. Как правило, обычно применяют удаленный EJB.Чтобы вы могли понять, понадобится ли дорабатывать код приложения, Red Hat предлагает специальный миграционный инструментарий для приложений. Он анализирует Java-приложения и определяет, насколько они пригодны для миграции на различные целевые платформы, включая контейнеры. Инструментарий миграции можно запускать из веб-интерфейса (см. Рис. 1), из командной строки, с помощью плагина Maven или расширения для IDE. Этот инструмент можно использовать для анализа приложений, которые надо контейнеризировать, и получить все обязательные или рекомендуемые доработки в виде отчета.
Какие инструменты могут помочь при переносе нагрузок на OpenShift?
Два мы уже упоминали: JBoss EAP S2I Image Builder и миграционный инструментарий для приложений.Кроме того, есть целый ряд инструментов, разрабатываемых в рамках open-source проекта Konveyor, которые помогают осуществить миграцию рабочих нагрузок на Kubernetes. Помимо инструментов для рехостинга имеющихся контейнерных приложений, рехостинга виртуальных машин и миграции приложения на Kubernetes, проект Konveyor также предоставляет инструменты для управления портфелем корпоративных приложений и контроля того, как протекают процессы доставки ПО, за счет сбора и анализа метрик поведения команд и организации на продолжительном отрезке времени.
Примечание: проект Konveyor развивается силами сообщества и не обеспечивается поддержкой Red Hat.
Итак
OpenShift упрощает разработку и развертывание приложений в целом ряде аспектов. Кроме того, существуют инструменты, как производства компании Red Hat, так развиваемые в рамках проекта Konveyor, которые позволяют относительно легко переносить на эту платформу Java-приложения.Теперь рассмотрим процесс миграции на примере.
Пример миграции Java-приложения на Red Hat OpenShift
В качестве примера возьмём учебное приложение Red Hat JBoss Enterprise Application Platform (EAP) под названием kitchen-sink, но в слегка доработанном виде, чтобы в качестве базы данных использовался MySQL. Исходный код можно найти в репозитории eap-quickstarts на GitHub.Сборка приложения
Прежде чем анализировать приложение, его надо собрать. Это делается следующей командой:$ cd kitchensink && mvn clean package
В результате, в папке kitchensink/target создается файл kitchensink.war
Анализ приложения
Теперь проверим, подходит ли только что собранное приложение для контейнеризации. Запустим миграционный инструментарий для приложений (Migration Toolkit for Applications) и создадим новый проект, который назовем kitchensink:
Затем щелкаем Next и в открывшейся форме загружаем файл для анализа kitchensink.war:
Щелкаем Next и выбираем тип анализа. В данном случае нас интересует только контейнеризация:
Щелкаем Next и попадаем на страницу Select Packages. Здесь выбираем пакет org и добавляем его в список «Included packages»:
Просто пролистываем три следующие страницы, поскольку не добавляем никаких пользовательских правил, меток и опций, и попадаем на страницу Review project details:
Щелкаем Save and run, чтобы запустить анализ. Через несколько секунд анализ завершается, и мы попадаем на страницу Analysis Results:
Щелкаем значок маленькой гистограммы в столбце Actions, чтобы просмотреть отчет, и попадаем на страницу Application List, где указан файл kitchensink.war:
На этой странице мы видим, что дела обстоят неплохо: ноль сюжетных точек и всего пять информационных элементов. Щелкаем ссылку kitchensink.war, чтобы просмотреть детали, и видим, что, как и было сказано, для контейнеризации этого приложения код дорабатывать не надо:
Итак, с помощью миграционного инструментария для приложений мы убедились, что наше приложение подходит для контейнеризации и развертывания на OpenShift.
Миграция приложения
Чтобы перенести приложение, надо взглянуть на существующее развертывание JBoss EAP. Приложению kitchen-sink не требовалось вносить какие-либо изменения в конфигурационный файл JBoss EAP (standalone.xml). Чтобы добавить модуль для MySQL, этот репозиторий добавляет файлы в каталог modules. Структура каталога и добавленные файлы выглядят следующим образом:modules
└── com
└── mysql
└── main
└── module.xml
└── mysql-connector-java-8.0.26.jar
Файл module.xml имеет следующее содержание:
<?xml version="1.0" ?>
<module xmlns="urn:jboss:module:1.1" name="com.mysql">
<resources>
<resource-root path="mysql-connector-java-8.0.26.jar"/>
</resources>
<dependencies>
<module name="javaee.api"/>
<module name="sun.jdk"/>
<module name="ibm.jdk"/>
<module name="javax.api"/>
<module name="javax.transaction.api"/>
</dependencies>
</module>
При запуске JBoss EAP читает этот файл и добавляет в систему модуль com.mysql.
При создании репозитория мы выполняем следующую команду с помощью интерфейса командной строки Jboss, чтобы добавить драйвер:
/subsystem=datasources/jdbc-driver=mysql:add(driver-name=mysql,driver-module-name=com.mysql)
И еще одна команда для создания источника данных, подключенного к локальному экземпляру MySQL:
$ data-source add --name=mysql --jndi-name=java:/jdbc/mysql --driver-name=mysql --connection-url=jdbc:mysql://127.0.0.1:3306/books --user-name=root --password=root
Добавление модуля
При развертывании приложений JBoss EAP в OpenShift модули, драйвера и источники данных добавляются немного иначе. Во время сборки образа S2I содержимое папки /modules репозитория приложения копируется в kitchensink/modules. Поэтому при подготовке к миграции в репозиторий kitchensink был добавлен каталог modules с тем же содержимым, что и при развертывании JBoss EAP. В результате, структура папки modules в репозитории приложений выглядит следующим образом:modules
└── com
└── mysql
└── main
└── module.xml
└── mysql-connector-java-8.0.26.jar
Добавление источника данных
После добавления модуля необходимо создать источник данных. Обычно в традиционном развертывании JBoss EAP это делается с помощью инструмента jboss-cli.sh. JBoss EAP S2I Image Builder предоставляет альтернативный метод настройки источников данных.Чтобы использовать этот метод, создадим папку extensions, а в ней – файл drivers.env следующего содержания:
#DRIVER
DRIVERS=MYSQL
MYSQL_DRIVER_NAME=mysql
MYSQL_DRIVER_MODULE=com.mysql
MYSQL_DRIVER_CLASS=com.mysql.cj.jdbc.Driver
Теперь создадим файл install.sh:
#!/bin/bash
if [ "${SCRIPT_DEBUG}" = "true" ] ; then
set -x
echo "Script debugging is enabled, allowing bash commands and their arguments to be printed as they are executed"
fi
injected_dir=$1
source /usr/local/s2i/install-common.sh
configure_drivers ${injected_dir}/drivers.env
Когда мы запускаем сборку S2I, то указываем этот каталог в качестве источника данных для расширений, и S2I-builder запустит файл install.sh для настройки источника данных.
Источник данных фактически создается при конфигурации во время выполнения, поэтому мы проверим это при развертывании нашего приложения с помощью JBoss EAP Operator.
Сборка образа приложения JBoss EAP
Итак, мы подготовили приложение, можно создавать его образ.Здесь есть два варианта, Helm Chart и шаблон. Оба они создают одинаковые Kubernetes-объекты: конфигурации сборки, потоки образов, сервис и т.д. Однако в случае с Helm Chart развертывание выполнять необязательно, поэтому мы можем использовать Helm Chart только для создания объектов сборки. Мы будем выполнять развертывание образа с помощью оператора, поэтому Helm Chart идеально подходит для выполнения сборки.
Инструкции и объекты, необходимые для сборки и развертывания образа с помощью Helm и Оператора, находятся в репозитории eap-migration GitHub. Этот репозиторий содержит конфигурацию Helm Chart (install-helm.yml), config map для настройки соединения MySQL (eap-cm.yml), подписку JBoss EAP Operator (eap-operator.yml) и custom resource deployment сервера WildFly (eap-deploy.yml).
Теперь проверим наш репозиторий и выполним перечисленные ниже шаги, чтобы собрать и развернуть наше приложение на OpenShift.
Создание проекта OpenShift
Создаем проект:$ oc new-project eap-kitchensink
Развертывание MySQL
Развертываем простую базу данных MySQL, используя шаблон mysql-persistent:$ oc new-app -e MYSQL_DATABASE=eap -e MYSQL_PASSWORD=demo -e MYSQL_USER=eap mysql-persistent
Создание pull-секрета со своими учетные данными на registry.redhat.io
Заменяем $USERNAME, $PASSWORD и $EMAIL на соответствующие данные нашей учетной записи на registry.redhat.io:$ oc create secret docker-registry my-pull-secret --docker-server=registry.redhat.io --docker-username=$USERNAME --docker-password=$PASSWORD --docker-email=$EMAIL
Установка Helm CLI
Чтобы разрешить использование команд Helm, действуем согласно документации.Установка Helm Chart
При установке Helm chart мы будем использовать конфигурационный файл install-helm.yml, в котором указываются Git URL, ветвь и contextDir, из которых будет извлекаться исходный код приложения. Этот конфигурационный файл включает в себя pull Secret и параметры конфигурации S2I, такие как builder-образы.Чтобы развернуть Helm Chart, используя эти параметры конфигурации, выполним следующую команду:
$ helm install kitchensink -f install-helm.yml http://github.com/openshift-helm-ch...oad/redhat-eap74-1.1.0/redhat-eap74-1.1.0.tgz
Теперь подождём несколько минут, пока завершатся две сборки, eap_app_build_artifacts и eap_app.
Настройка источника данных MySQL
Создадим config map с переменными окружения MySQL следующей командой:$ oc create -f eap-cm.yml
Развертывание приложения с использованием JBoss EAP Operator
Установим JBoss EAP Operator:$ oc create -f eap-operator.yml
Теперь развернем инстанс приложения с помощью оператора, развернув объект сервера WildFly:
apiVersion: wildfly.org/v1alpha1
kind: WildFlyServer
metadata:
name: kitchen-sink
spec:
applicationImage: 'kitchensink:latest'
envFrom:
- configMapRef:
name: eap-config
replicas: 1
Для этого объекта надо задать лишь applicationImage, имя переменных среды контейнера config map и количество реплик, а затем выполнить команду:
oc create -f eap-deploy.yml
После того, как приложение будет развернуто, его топология появится в интерфейсе Developer UI:
Рис. 10. На странице Topology отображается приложение kitchen-sink и база БД MySQL.
Если щелкнуть маршрут, можно увидеть запущенный экземпляр приложения. На рисунке ниже показано приложение kitchen-sink с записью по умолчанию в базе данных.
Рис. 11. Наше приложение запущено и показывает одну запись в базе данных.
Итак
Выше мы показали, как выполнить анализ, контейнеризацию и развертывание приложения JBoss EAP на OpenShift с подключением к инстансу MySQL.Как видно, EAP S2I Builder и миграционный инструментарий Red Hat для приложений делают анализ и перенос приложений на контейнерные платформы, вроде OpenShift, довольно простым делом. Оба этих инструмента можно использоваться не только автономно, как показано в этой статье, но и составе конвейеров автоматизации миграции.
Перенос Java-нагрузок на OpenShift – зачем и как
Несмотря на ударные темпы распространения платформ оркестрации контейнеров, вроде Kubernetes или Red Hat OpenShift, подавляющее большинство Java-нагрузок в мире по-прежнему выполняются на виртуальных...
habr.com