Перенос приложений WebSphere в JBoss EAP в службе приложение Azure

  • Статья

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

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

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

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

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

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

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

Проверьте все свойства и файлы конфигурации на рабочем сервере или серверах для любых секретов и паролей. Обязательно проверьте наличие файла ibm-web-bnd.xml в WAR-файлах. Кроме того, в приложении могут быть файлы конфигурации, содержащие пароли или учетные данные. Эти файлы могут включать в себя приложения Spring Boot, свойства application.properties или application.yml файлы.

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

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

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

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

JBoss EAP в службе приложение Azure поддерживает Java 8 и 11. Поэтому вам нужно проверить, может ли приложение правильно работать с этой поддерживаемой версией. Эта проверка особенно важна, если на текущем сервере используется поддерживаемая версия JDK (например, Oracle JDK или IBM OpenJ9).

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

java -version

Проверка ресурсов JNDI

Проверьте все ресурсы JNDI. Для некоторых ресурсов, таких как брокеры сообщений JMS, может потребоваться миграция или перенастройка.

В приложении

Проверьте файл WEB-INF/ibm-web-bnd.xml и/или файл WEB-INF/web.xml.

Определение того, используются ли базы данных

Если приложение использует какие-либо базы данных, необходимо определить следующие сведения:

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

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

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

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

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

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

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

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

Для файлов, которые часто записываются и считываются приложением (например, временные файлы данных) или статические файлы, видимые только приложению, можно подключить служба хранилища Azure в файловую систему Служба приложений. Дополнительные сведения см. в разделе "Подключение служба хранилища Azure в качестве локальной общей папки в Служба приложений".

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

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

Для выполнения запланированных заданий в Azure рекомендуется использовать Функции Azure с триггером таймера. Дополнительные сведения см. в статье Триггер таймера для Функций Azure. Переносить сам код задания в функцию не нужно. Функция может просто вызвать URL-адрес в приложении, чтобы активировать задание.

Примечание.

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

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

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

Определение того, используются ли очереди или разделы Java Message Service (JMS)

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

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

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

Если приложение использует API для конкретной веб-платформы, вам потребуется рефакторинг приложения, чтобы не использовать их. Набор средств миграции Red Hat для приложений может помочь в удалении и рефакторинге этих зависимостей.

Определение того, использует ли приложение компоненты Entity Bean или bean-компоненты CMP в стиле EJB 2.x

Если ваше приложение использует компоненты Entity Bean или bean-компоненты CMP в стиле EJB 2.x, необходимо выполнить рефакторинг приложения, чтобы удалить эти зависимости.

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

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

Определение того, содержит ли приложение код, зависящий от ОС

Если приложение содержит любой код с зависимостями в ос узла, необходимо рефакторинговать его, чтобы удалить эти зависимости. Например, может потребоваться заменить любое использование / или \ в пути к файловой системе или File.Separator Paths.get , если ваше приложение работает в Windows.

Определение того, используются ли таймеры EJB

Если приложение использует таймеры EJB, необходимо проверить, может ли код таймера EJB запускаться каждым экземпляром JBoss EAP независимо. Эта проверка необходима, так как при горизонтальном масштабировании Служба приложений каждый таймер EJB будет активирован в собственном экземпляре JBoss EAP.

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

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

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

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

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

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

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

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

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

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

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

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

Миграция

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

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

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

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

В списке доступных планов обслуживания выберите план, спецификации которого соответствуют или превышают спецификации текущего производственного оборудования.

Примечание.

Если вы намерены использовать промежуточное или раннее развертывание либо слоты развертывания, план службы приложений должен учитывать эту дополнительную емкость. Для приложений Java рекомендуется использовать план уровня "Премиум" или выше.

Создайте этот план службы приложений.

Создание и развертывание веб-приложений

Вам потребуется создать веб-приложение в плане Служба приложений для каждого WAR-файла, развернутого на сервере JBoss EAP.

Примечание.

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

Приложения Maven

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

Приложения, отличающиеся от Maven

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

После создания веб-приложения используйте один из доступных механизмов развертывания для развертывания приложения. Дополнительные сведения см. в разделе "Развертывание файлов в Служба приложений".

Перенос параметров среды выполнения JVM

Если для работы приложения требуются определенные параметры среды выполнения, используйте наиболее подходящий механизм, чтобы указать их. Дополнительные сведения см. в разделе "Настройка параметров среды выполнения Java" в разделе "Развертывание" и настройка приложения Tomcat, JBoss или Java SE в службе приложение Azure.

Указание секретов

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

Настройка личного домена и SSL

Если приложение будет отображаться в личном домене, вам нужно будет сопоставить с ним веб-приложение. Дополнительные сведения см. в статье Сопоставление существующего настраиваемого DNS-имени со Службой приложений Azure.

Затем необходимо привязать TLS/SSL-сертификат для этого домена к веб-приложению Служба приложений. Дополнительные сведения см. в учебнике Защита пользовательского DNS-имени с помощью привязки TLS/SSL в Службе приложений Azure.

Перенос источников данных, библиотек и ресурсов JNDI

Чтобы перенести источники данных, выполните действия, описанные в разделе "Настройка источников данных" для приложения Tomcat, JBoss или Java SE в службе приложение Azure.

Перенос дополнительных зависимостей класса уровня сервера. Дополнительные сведения см. в разделе "Настройка источников данных" для приложения Tomcat, JBoss или Java SE в службе приложение Azure.

Перенос дополнительных ресурсов JDNI на уровне общего сервера. Дополнительные сведения см. в разделе "Настройка источников данных" для приложения Tomcat, JBoss или Java SE в службе приложение Azure.

Примечание.

Если вы используете рекомендуемую архитектуру одного WAR для каждого приложения, рассмотрите возможность переноса библиотек классов уровня сервера и ресурсов JNDI в приложение. Это значительно упрощает управление компонентами и управление изменениями. Если вы хотите развернуть несколько WAR для каждого приложения, ознакомьтесь с одним из наших вспомогательных руководств, упомянутых в начале этого руководства.

Перенос запланированных заданий

Как минимум, вы должны переместить запланированные задания на виртуальную машину Azure, чтобы они больше не были частью приложения. Кроме того, вы можете модернизировать их на основе событий Java с помощью таких служб Azure, как Функции Azure, База данных SQL и Центры событий.

Перезапуск и тест состояния

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

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

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

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