Поделиться через

Миграция приложений JBoss EAP на платформу JBoss EAP в Службе приложений Azure

  • Статья

В этом руководстве описывается, что следует учитывать при переносе существующего приложения Red Hat JBoss Enterprise Application Platform (EAP) для запуска в JBoss EAP в экземпляре службы приложений Azure.

Подготовка к миграции

Чтобы обеспечить успешную миграцию, перед ее началом выполните шаги оценки и инвентаризации, описанные в следующих разделах.

Инвентаризация мощностей сервера

Определите характеристики оборудования текущих рабочих серверов (показатели памяти, ЦП и диска), а также среднее и пиковое количество запросов и объем потребляемых ресурсов. Эти сведения понадобятся, независимо от выбранного пути миграции. Это полезно, например, для выбора размера виртуальных машин в пуле узлов, объема памяти, который будет использоваться контейнером, и количества процессорных ресурсов, необходимых контейнеру.

Можно изменить размер пулов узлов в AKS. Дополнительные сведения см. в разделе Изменение размера пулов узлов в службе Azure Kubernetes (AKS).

Учёт всех секретов

Проверьте все свойства и файлы конфигурации на рабочих серверах для любых секретов и паролей. Обязательно проверьте jboss-web.xml в файлах архива веб-приложений (WAR). Файлы конфигурации, содержащие пароли или учетные данные, также можно найти в приложении.

Мы рекомендуем хранить секреты в Azure KeyVault. Для получения дополнительной информации см. основные понятия Azure Key Vault.

Вы можете использовать секреты Хранилища ключей в экземпляре Службы приложений, задавая ссылки на них. Ссылки на Key Vault позволяют использовать в приложениях секреты, которые надежно хранятся в зашифрованном виде. Дополнительные сведения см. в статье Использование ссылок на Key Vault в Службе приложений и Функциях Azure.

Инвентаризация всех сертификатов

Определите все сертификаты, используемые для общедоступных конечных точек SSL. Вы можете просмотреть все сертификаты на рабочих серверах, выполнив следующую команду:

keytool -list -v -keystore <path to keystore>

Проверка правильной работы поддерживаемой версии Java

Для JBoss EAP в службе приложений требуется поддерживаемая версия Java. Рекомендации по выбору версии комплекта разработки Java (JDK) см. в разделе Поддерживаемые конфигурации документации Red Hat.

Примечание.

Эта проверка особенно важна, если на текущем сервере используется неподдерживаемая версия JDK (например, Oracle JDK или IBM OpenJ9).

Чтобы получить текущую версию Java, войдите на сервер в рабочей среде и выполните следующую команду:

java -version

Проверка внешних ресурсов

Внешние ресурсы, такие как источники данных, брокеры сообщений Java (JMS) и другие, внедряются с помощью интерфейса именования Java и каталога (JNDI). Для некоторых таких ресурсов может потребоваться миграция или перенастройка.

В приложении

Проверьте файлы WEB-INF/jboss-web.xml и (или) WEB-INF/web.xml. Найдите элементы <Resource> в элементе <Context>.

Источники данных

Источники данных — это ресурсы JNDI с атрибутом type, для которого задано значение javax.sql.DataSource. Для каждого источника данных запишите следующие сведения:

  • имя источника данных;
  • конфигурация пула подключений;
  • Где можно найти JAR-файл драйвера подключения к базе данных Java (JDBC) ?

Дополнительные сведения см. в разделе О источниках данных JBoss Enterprise Application Platform (EAP) в документации по JBoss EAP.

Все прочие внешние ресурсы

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

Определение того, используется ли файловая система и как именно она используется

Для любого использования файловой системы на сервере приложений требуется перенастройка или, в редких случаях, изменения архитектуры. Модули JBoss EAP или код приложения могут использовать файловую систему. Вы можете определить некоторые или все сценарии, описанные в следующих разделах.

Статическое содержимое только для чтения

Если приложение в настоящее время обслуживает статическое содержимое, для него требуется альтернативное расположение. Следует рассмотреть возможность перемещения статического содержимого в хранилище BLOB-объектов Azure и добавления Azure Front Door для быстрого скачивания глобально. Дополнительные сведения см. в статьях Статическое размещение веб-сайтов в Azure Storage и Интеграция учетной записи хранения Azure сAzure Front Door.

Динамическое или внутреннее содержимое

Для использования файлов, которые приложение часто записывает и считывает (например, временные файлы данных), или статических файлов, видимых только для вашего приложения, вы можете использовать локальное файловое хранилище, связанное с вашим планом службы приложений. Дополнительные сведения см. в статье Функциональность операционной системы в Службе приложений Azure и Understanding the Azure App Service file system (Обзор файловой системы Службы приложений Azure).

Убедитесь, что ваше приложение использует запланированные задания.

Запланированные задания, такие как задачи планировщика Quartz или задания cron в UNIX, НЕЛЬЗЯ использовать со Службой приложений Azure. Служба приложений Azure не будет препятствовать развертыванию приложения, содержащего запланированные задачи. Но если приложение масштабируется, одно запланированное задание может выполняться несколько раз в течение указанного периода. Это может привести к нежелательным последствиям.

Проверьте все запланированные задачи, выполняемые на рабочих серверах, внутри или за пределами кода приложения.

Определение того, нужно ли подключаться к локальной среде

Если вашему приложению требуется доступ к какой-либо из локальных служб, вам необходимо подготовить одну из служб подключения Azure. Дополнительные сведения см. в статье Выбор решения для подключения локальной сети к Azure. Кроме того, необходимо выполнить рефакторинг приложения, чтобы использовать общедоступные API-интерфейсы, предоставляемые локальными ресурсами.

Определите, используются ли очереди или топики в Java Message Service (JMS)

Если приложение использует очереди или разделы JMS, их необходимо перенести на внешний сервер JMS. Использование Служебной шины Azure и Расширенного протокола управления очередью сообщений (AMQP) — это подходящая стратегия миграции для тех, кто работает с JMS. Для получения дополнительной информации см. использование Java 1.1 со службой сообщений с стандартной служебной шиной Azure и AMQP 1.0.

Если постоянные хранилища JMS настроены, вам нужно записать их конфигурацию и применить ее после миграции.

Определение того, используются ли соединители JCA

Если в приложении используются соединители архитектуры соединителей Java (JCA), убедитесь, что соединитель JCA можно использовать в JBoss EAP. Если соединитель JCA можно использовать в JBoss EAP, то для его доступности необходимо добавить файлы архива Java (JAR) в путь к классу сервера и поместить необходимые файлы конфигурации в правильное расположение в каталогах сервера JBoss EAP.

Определение того, используется ли JAAS

Если приложение использует JAAS, необходимо определить настройки JAAS. Если используется база данных, ее можно преобразовать в домен JAAS в JBoss EAP. Если используется пользовательская реализация, необходимо проверить, можно ли использовать ее в JBoss EAP.

Определение того, использует ли приложение адаптер ресурсов

Если приложению требуется адаптер ресурсов, он должен быть совместимым с JBoss EAP. Определите, корректно ли работает адаптер ресурсов в отдельном экземпляре JBoss EAP, развернув его и правильно настроив на сервере. Если адаптер ресурсов работает правильно, добавьте JAR-файлы в путь к классу сервера Службы приложений и поместите необходимые файлы конфигурации в нужное расположение в каталогах сервера JBoss EAP, чтобы обеспечить доступность.

Определение того, состоит ли приложение из нескольких WAR-файлов

Если ваше приложение состоит из нескольких WAR-файлов, вам следует рассматривать каждый из этих WAR-файлов как отдельное приложение и пройтись по этому руководству для каждого из них.

Определение того, упаковано ли приложение как EAR-файл

Если приложение упаковано как EAR-файл, обязательно проверьте файл application.xml, определив его конфигурацию.

Примечание.

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

Определение всех внешних процессов и управляющих программ, запущенных на рабочих серверах

Если за пределами сервера приложений выполняются какие-либо процессы (например, управляющие программы мониторинга), вам нужно будет удалить их или перенести в другое расположение.

Тестирование на месте

Перед созданием веб-приложений перенесите приложение в версии JDK и JBoss EAP, которые вы планируете использовать в службе приложений. Тщательно протестируйте приложение, чтобы обеспечить совместимость и высокую производительность.

Заметки о возможностях JBoss EAP в Службе приложений

При работе с JBoss EAP в Службе приложений обязательно учитывайте следующее.

  • Консоль управления JBoss EAP: Веб-консоль JBoss не доступна в Службе приложений. Вместо нее на портале Azure предоставляются API управления для приложения, а развертывание следует выполнять через интерфейс командной строки Azure, приложение Maven для Azure или другие средства разработки. Дополнительную настройку ресурсов JBoss можно достичь с помощью интерфейса командной строки JBoss во время запуска приложения.

  • транзакции: API транзакций поддерживается, и есть поддержка автоматического восстановления транзакций. Дополнительные сведения см. в разделе об управлении транзакциями в JBoss EAP в документации по Red Hat.

  • Режим управляемого домена. В рабочей среде с множеством серверов JBoss EAP позволяет применять режим управляемого домена, чтобы централизованно управлять серверами. Но когда JBoss EAP работает в Службе приложений, платформа Службы приложений выполняет настройку и администрирование экземпляров серверов. Служба приложений устраняет необходимость в режиме управляемого домена JBoss EAP. Режим домена — это хороший вариант для развертываний на основе виртуальных машин с большим числом серверов. Дополнительные сведения см. в разделе об управляемых доменах в документации по Red Hat.

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

    • Компоненты сессии с отслеживанием состояния.
    • Распределенные транзакции.
    • Аналогичные функции, требующие обмена данными между экземплярами или высокой доступности.

    Дополнительные сведения см. в разделе кластеризациинастройка приложения Java для службы приложений Azure.

Миграция

Набор средств миграции Red Hat для приложений

Набор средств миграции Red Hat для приложений — это бесплатное расширение для Visual Studio Code. Это расширение анализирует код приложения и конфигурацию, чтобы предоставить рекомендации по миграции в облако из локальной среды. Для получения дополнительной информации см. обзор "Набора средств миграции для приложений".

Содержимое этого руководства поможет вам решить другие компоненты процесса миграции, например выбрать правильный тип Плана службы приложений, вынесение состояния сеанса и использовать Azure для управления экземплярами EAP вместо интерфейса JBoss Management.

Подготовка Службы приложений Azure для среды выполнения EAP JBoss

Используйте следующие команды для создания группы ресурсов и плана службы приложений Azure. После создания плана службы приложений план веб-приложения Linux создается с помощью среды выполнения JBoss Enterprise Application Platform (EAP).

Убедитесь, что указанные переменные среды имеют соответствующие значения.

az group create --resource-group $resourceGroup --location eastus
az acr create --resource-group $resourceGroup --name $acrName --sku Standard
az appservice plan create \
    --resource-group $resourceGroup \
    --name $jbossAppService \
    --is-linux \
    --sku P0v3
az webapp create \
    --resource-group $resourceGroup \
    --name $jbossWebApp \
    --plan $jbossAppServicePlan \
    --runtime "JBOSSEAP|8-java17"
    #  Or use "JBOSSEAP|8-java11" if you're using Java 11

Создайте приложение

Запустите сборку приложения с помощью следующей команды Maven.

mvn clean install -DskipTests

Развертывание приложения

Если ваше приложение построено на основе POM-файла Maven, используйте плагин для Webapp в Maven, чтобы создать веб-приложение и развернуть его. Для получения дополнительной информации см. в разделе «Быстрый старт: Создание приложения Java в службе приложений Azure».

Чтобы автоматизировать развертывание приложений JBoss EAP, можно использовать задачу Azure Pipelines для веб-приложения или GitHub Actions для развертывания в веб-приложении Azure.

Настройка источников данных

Существует три основных шага при регистрации источника данных в JBoss Enterprise Application Platform (EAP): отправка драйвера подключения к базе данных Java (JDBC), добавление драйвера JDBC в качестве модуля и регистрация модуля. Дополнительные сведения см. в разделе Управление источниками данных в документации по JBoss EAP. App Service — это бестранзакционная служба размещения, поэтому команды конфигурации для добавления и регистрации модуля источника данных должны быть записаны в скрипт и применены при запуске контейнера.

Чтобы настроить источники данных, выполните следующие действия.

  1. Получите драйвер JDBC для базы данных.

  2. Создайте файл определения модуля XML для драйвера JDBC. В примере показано определение модуля для PostgreSQL. Не забудьте заменить значение resource-root path на путь к используемому драйверу JDBC.

    <?xml version="1.0" ?>
<module xmlns="urn:jboss:module:1.1" name="org.postgres">
    <resources>
    <!-- ***** IMPORTANT: REPLACE THIS PLACEHOLDER *******-->
    <resource-root path="/home/site/deployments/tools/postgresql-42.2.12.jar" />
    </resources>
    <dependencies>
        <module name="javax.api"/>
        <module name="javax.transaction.api"/>
    </dependencies>
</module>

  3. Вставьте команды интерфейса командной строки JBoss в файл с именем jboss-cli-commands.cli. Команды JBoss должны добавить модуль и зарегистрировать его в качестве источника данных. В примере показаны команды интерфейса командной строки JBoss для PostgreSQL.

    Примечание.

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

    module add --name=org.postgres --resources=/home/site/deployments/tools/postgresql-42.2.12.jar --module-xml=/home/site/deployments/tools/postgres-module.xml

/subsystem=datasources/jdbc-driver=postgres:add(driver-name="postgres",driver-module-name="org.postgres",driver-class-name=org.postgresql.Driver,driver-xa-datasource-class-name=org.postgresql.xa.PGXADataSource)

data-source add --name=postgresDS --driver-name=postgres --jndi-name=java:jboss/datasources/postgresDS --connection-url=${POSTGRES_CONNECTION_URL,env.POSTGRES_CONNECTION_URL:jdbc:postgresql://db:5432/postgres} --user-name=${POSTGRES_SERVER_ADMIN_FULL_NAME,env.POSTGRES_SERVER_ADMIN_FULL_NAME:postgres} --password=${POSTGRES_SERVER_ADMIN_PASSWORD,env.POSTGRES_SERVER_ADMIN_PASSWORD:example} --use-ccm=true --max-pool-size=5 --blocking-timeout-wait-millis=5000 --enabled=true --driver-class=org.postgresql.Driver --exception-sorter-class-name=org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLExceptionSorter --jta=true --use-java-context=true --valid-connection-checker-class-name=org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLValidConnectionChecker

  4. Создайте сценарий запуска под названием startup_script.sh, который вызывает команды интерфейса командной строки JBoss. В примере показано, как вызвать файл jboss-cli-commands.cli. Позже вы настроите службу приложений для запуска этого скрипта при запуске экземпляра.

    $JBOSS_HOME/bin/jboss-cli.sh --connect --file=/home/site/deployments/tools/jboss-cli-commands.cli

  5. Используя любой FTP-клиент, загрузите драйвер JDBC, jboss-cli-commands.cli, startup_script.sh и определение модуля по адресу /site/deployments/tools/.

  6. Настройте сайт для выполнения startup_script.sh при запуске контейнера. На портале Azure перейдите к Настройки и конфигурация > Основные настройки > Команда запуска. Укажите в поле команды запуска /home/site/deployments/tools/startup_script.sh, затем выберите Сохранить.

  7. Перезапустите веб-приложение, которое приводит к запуску скрипта конфигурации.

  8. Обновите конфигурацию источника данных API транзакций Java (JTA) для приложения. Откройте файл src/main/resources/META-INF/persistence.xml для вашего приложения и найдите элемент <jta-data-source>. Замените его содержимое, как показано ниже:

    <jta-data-source>java:jboss/datasources/postgresDS</jta-data-source>

Сборка приложения

Запустите сборку приложения с помощью следующей команды Maven.

mvn clean install -DskipTests

Развертывание приложения

Если ваше приложение создано на основе POM-файла Maven, используйте плагин Webapp для Maven, чтобы создать и развернуть ваше приложение. Для получения дополнительной информации см. руководство по быстрому старту: Создание приложения Java в службе приложений Azure.

Чтобы автоматизировать развертывание приложений JBoss EAP, можно использовать задачу Azure Pipelines для веб-приложения или GitHub Actions для развертывания в веб-приложении Azure.

После миграции

Теперь, когда приложение перенесено в службу приложений Azure, убедитесь, что оно работает должным образом. После этого у нас есть некоторые рекомендации, которые могут сделать приложение более облачным.

Рекомендации