Перенос Java-нагрузок OpenShift – зачем и как

Несмотря на ударные темпы распространения платформ оркестрации контейнеров, вроде Kubernetes или Red Hat OpenShift, подавляющее большинство Java-нагрузок в мире по-прежнему выполняются на виртуальных машинах или на «голом железе». Однако перенос корпоративных нагрузок, и в частности, приложений Red Hat JBoss Enterprise Application Platform (EAP), в облако рано или поздно состоится, и OpenShift представляется здесь естественным выбором. Сегодня мы вкратце ответим на типовые вопросы, которые возникают при таком переходе, и покажем на примере, как он производится.

Что входит в процесс миграцит 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-charts/charts/releases/download/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:

Если щелкнуть маршрут, можно увидеть запущенный экземпляр приложения. На рисунке ниже показано приложение kitchen-sink с записью по умолчанию в базе данных.

Итак

Выше мы показали, как выполнить анализ, контейнеризацию и развертывание приложения JBoss EAP на OpenShift с подключением к инстансу MySQL.

Как видно, EAP S2I Builder и миграционный инструментарий Red Hat для приложений делают анализ и перенос приложений на контейнерные платформы, вроде OpenShift, довольно простым делом. Оба этих инструмента можно использоваться не только автономно, как показано в этой статье, но и составе конвейеров автоматизации миграции.