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

  • Статья

Из этого руководства вы узнаете, что следует учитывать при переносе существующего приложения JBoss EAP для запуска в JBoss EAP в экземпляре Службы приложений Azure.

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

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

Проверка емкости сервера

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

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

Проверка всех секретов

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

Мы рекомендуем хранить секреты в Azure KeyVault. См. основные понятия Azure Key Vault.

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

Проверка всех сертификатов

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

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

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

Для JBoss EAP на виртуальных машинах Azure требуется поддерживаемая версия Java. Инструкции по использованию версии JDK см . в документации по Red Hat в поддерживаемых конфигурациях .

Примечание.

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

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

java -version

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

Внешние ресурсы, такие как источники данных, брокеры сообщений JMS и другие, внедряются с помощью API JNDI (Java Naming and Directory Interface). Возможно, для некоторых из этих ресурсов потребуется выполнить перенос или перенастройку.

В приложении

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

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

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

  • имя источника данных;
  • конфигурация пула подключений;
  • путь к JAR-файлу драйвера JDBC.

См. сведения об источниках данных JBoss EAP в документации по JBoss EAP.

Другие связанные внешние ресурсы

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

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

Если приложение использует репликацию сеансов, вам потребуется удалить из него эту зависимость. Служба приложений не позволяет экземплярам взаимодействовать друг с другом напрямую.

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

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

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

Если ваше приложение сейчас обслуживает статическое содержимое, вам потребуется альтернативное расположение для этого статического содержимого. Вы можете переместить статическое содержимое в хранилище BLOB-объектов Azure и включить Azure CDN для быстрого скачивания в глобальном масштабе. Дополнительные сведения см. в статье "Размещение статических веб-сайтов" в служба хранилища Azure и кратком руководстве. Интеграция учетной записи хранения Azure с Azure CDN. Вы также можете напрямую развернуть статическое содержимое в приложении в плане Azure Spring Apps Enterprise. Дополнительные сведения см. в разделе "Развертывание статических веб-файлов".

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

Если приложение допускает использование статического содержимого, которое передается или создается приложением и после этого становится неизменяемым, вы можете использовать хранилище BLOB-объектов Azure и Azure CDN, как описано выше, с Функциями Azure для выполнения отправки и обновления CDN. Практический пример реализации см. в руководстве по отправке и предварительной загрузке статического содержимого CDN с помощью Функций Azure. Вы также можете напрямую развернуть статическое содержимое в приложении в плане Azure Spring Apps Enterprise. Дополнительные сведения см. в разделе "Развертывание статических веб-файлов".

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

Для использования файлов, которые приложение часто записывает и считывает (например, временные файлы данных), или статических файлов, видимых только для вашего приложения, вы можете использовать локальное файловое хранилище, связанное с вашим планом службы приложений. Дополнительные сведения см. в статье Функциональность операционной системы в Службе приложений 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. Сведения см. в руководстве по использованию JMS со Служебной шиной Azure и AMQP 1.0.

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

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

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

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

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

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

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

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

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

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

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

Примечание.

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

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

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

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

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

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

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

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

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

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

  • Кластеризация между серверами: по состоянию на 15 марта 2022 г. кластеризованное развертывание JBoss EAP поддерживается в общедоступной предварительной версии. Эта поддержка означает, что вам больше не нужно удалять следующие функции из приложений, прежде чем их можно развернуть в Служба приложений:

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

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

Миграция

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

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

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

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

Используйте следующие команды для создания группы ресурсов и плана службы приложений Azure. После создания плана службы приложений создается план веб-приложения Linux с использованием среды выполнения JBoss EAP. Сайты JBoss EAP можно создавать только на уровнях планов службы приложений "Премиум" версии 3 и "Изолированный" версии 2.

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

Примечание.

Для планов "Премиум" версии 3 и "Изолированный" версии 2 применимы цены на зарезервированные экземпляры, что может снизить затраты. Дополнительные сведения о ценах на уровни планов службы приложений и зарезервированных экземпляров см. в статье Цены на Службу приложений.

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 P1V2
az webapp create \
    --resource-group $resourceGroup \
    --name $jbossWebApp \
    --plan $jbossAppServicePlan \
    --runtime "JBOSSEAP|7-java8"
    #  Or use "JBOSSEAP|7-java11" if you're using Java 11

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

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

mvn clean install -DskipTests

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

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

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

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

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

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

  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. Позже вы настроите App Service на выполнение этого сценария при запуске экземпляра.

    $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. Обновите конфигурацию источника данных 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, используйте подключаемый модуль веб-приложения для Maven, чтобы создать и развернуть веб-приложение. Дополнительные сведения см. в кратком руководстве по созданию приложения Java в службе приложение Azure.

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

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

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

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