Перенос приложений JBoss EAP в Azure Red Hat OpenShift

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

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

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

Убедитесь, что целевой объект является подходящим целевым объектом для усилий по миграции.

Первым шагом в успешной миграции приложения JBoss EAP в Azure является выбор наиболее подходящего целевого объекта миграции. JBoss EAP хорошо работает на виртуальных машинах Azure или Azure Red Hat OpenShift.

Целевой объект виртуальной машины — самый простой выбор, так как он больше всего похож на локальное развертывание. Интерфейс администрирования и развертывания виртуальных машин аналогиен тому, что у вас есть локально. Выбор виртуальных машин позволяет отложить модернизацию.

Red Hat OpenShift объединяет тестированные и доверенные службы, чтобы снизить трения при разработке, модернизации, развертывании, запуске и управлении приложениями. Azure Red Hat OpenShift основан на Kubernetes. Azure Red Hat OpenShift обеспечивает согласованный интерфейс в общедоступном облаке, локальной среде, гибридном облаке или пограничной архитектуре.

Если минимизация изменений является самым важным фактором для усилий по миграции, рассмотрите возможность миграции на основе виртуальной машины. В этом случае см. статью "Миграция приложений JBoss EAP в JBoss EAP на виртуальных машинах Azure". Если вы можете терпеть преобразование приложения в Red Hat OpenShift для снижения затрат на среду выполнения, рассмотрите миграцию на основе Azure Red Hat OpenShift. В этом случае продолжайте перенос приложений JBoss EAP в JBoss EAP в Azure Red Hat OpenShift. Сведения о различиях между JBoss EAP и JBoss EAP для OpenShift см. в статье "Сравнение: JBoss EAP и JBoss EAP для OpenShift".

Определите, является ли предварительно созданное предложение Azure Marketplace хорошим отправной точкой

Сначала решите, что Azure Red Hat OpenShift является подходящим целевым объектом развертывания. Затем определите, является ли предварительно созданное предложение Azure Marketplace хорошим отправным пунктом. Рассмотрим следующие моменты о предварительно созданном предложении Azure Marketplace:

• Red Hat и Корпорация Майкрософт создали это предложение, чтобы быстро подготовить JBoss EAP в Azure Red Hat OpenShift.
• На высоком уровне предложение автоматизирует следующие шаги.
  • Установите оператор EAP в Azure Red Hat OpenShift.
  • Создание образа приложения с помощью шаблона eap-s2i-build. Дополнительные сведения об исходном образе (S2I) см. в разделе Using OpenJDK 11 source-to-image for OpenShift.
  • Разверните приложение Java с помощью оператора EAP. Дополнительные сведения см. в справочной документации для оператора EAP в Red Hat.

Если вы не используете предварительно созданное предложение Azure Marketplace, необходимо узнать, как напрямую использовать оператор EAP. Мастеринг оператора выходит за рамки область этой статьи. Полная документация для оператора EAP доступна в Red Hat.

Оставшаяся часть этого раздела содержит некоторые рекомендации по использованию предварительно созданного предложения Azure Marketplace или непосредственного использования оператора.

Определение совместимости версии JBoss EAP

Существующая версия JBoss EAP должна быть одной из версий, поддерживаемых оператором. Дополнительные сведения см. в разделе "Совместимость версий и поддержка " в документации по Red Hat.

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

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

• Чтобы помочь выбрать размер виртуальных машин в пуле узлов.
• Чтобы понять объем памяти, используемый контейнером.
• Чтобы узнать, сколько ЦП требуется контейнеру.

Можно изменить размер пулов узлов в Azure Red Hat OpenShift. Дополнительные сведения см. в разделе "Изменение размера кластера-Microsoft Azure " в документации по Red Hat.

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

До появления таких технологических решений "конфигурация как услуга", как Azure Key Vault, понятие "секреты" не было четко определено. Вместо этого предоставлялся разнородный набор параметров конфигурации, которые использовались в качестве того, что сейчас называется секретами. При использовании серверов приложений, таких как JBoss EAP, эти секреты находятся в разных файлах конфигурации и хранилищах конфигураций. Проверьте все свойства и файлы конфигурации на рабочих серверах на наличие секретов и паролей. Обязательно проверка файлы конфигурации, такие как custom-config.xml или jboss-web.xml в приложениях. Кроме того, в приложении могут быть файлы конфигурации, содержащие пароли или учетные данные. См. основные понятия Azure Key Vault.

После получения твердой инвентаризации секретов обратитесь к документации оператора EAP по секретам. Дополнительные сведения см. в разделе "Создание секрета " в документации по Red Hat.

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

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

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

После получения твердой инвентаризации сертификатов их можно настроить в Azure Red Hat OpenShift. Дополнительные сведения см. в разделе tls configuration in OpenShift Container Platform(replace) в документации по Red Hat.

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

Для всех путей миграции для JBoss EAP в Azure Red Hat OpenShift требуется определенная версия Java, которая зависит от каждого пути. Необходимо убедиться, что приложение может работать правильно с помощью этой поддерживаемой версии.

Примечание.

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

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

java -version

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

Проверьте все ресурсы JNDI. Например, у источников данных, таких как базы данных, может быть связанное имя JNDI, которое позволяет JPA правильно привязывать экземпляры EntityManager к определенной базе данных. Дополнительные сведения о ресурсах и базах данных JNDI см . в документации по управлению источниками данных в Red Hat. Другие ресурсы, связанные с JNDI, такие как брокеры сообщений ActiveMQ Artemis, могут потребовать миграции или перенастройки. Дополнительные сведения о конфигурации ActiveMQ Artemis см . в разделе "Настройка обмена сообщениями " в документации по Red Hat.

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

Если приложение использует сеанс реплика tion, с infinispan или без него, у вас есть три варианта:

• Infinispan хорошо работает на виртуальных машинах Azure, но если вы используете профиль, предоставляющий возможности высокой доступности, помните о конфигурации JGroups . Определите, работает ли ваша система как управляемый домен или автономный сервер.
  • Если в управляемом домене профили высокого уровня или полного уровня доступности имеют дело с JGroups.
  • Если на автономном сервере файлы конфигурации standalone-ha.xml или standalone-full-ha.xml имеют дело с JGroups.
  • Microsoft Azure не поддерживает протоколы обнаружения JGroups, основанные на многоадресной рассылке UDP. Дополнительные сведения см. в статье Об использовании высокого уровня доступности JBoss EAP в Microsoft Azure в документации по Red Hat.
• Выполните рефакторинг приложения, чтобы использовать базу данных для управления сеансами.
• Выполните рефакторинг приложения, чтобы перенести сеанс в службу Redis Azure. См. сведения на странице с ценами на Azure Cache for Redis.

Для всех этих параметров рекомендуется понять, как JBoss EAP выполняет репликацию состояния сеанса HTTP. Дополнительные сведения см. в статье о репликации сеансов HTTP в документации по Red Hat.

Определение источников данных

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

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

Дополнительные сведения о драйверах JDBC в JBoss EAP см . в документации по управлению источниками данных.

Определение того, настроен ли JBoss EAP

Определите, какие из следующих настроек были сделаны.

• Были ли изменены скрипты запуска? К таким сценариям относятся узел, eap_env, автономный домен и домен.
• Есть ли какие-либо определенные параметры, передаваемые в виртуальную машину Java?
• Есть ли JAR-файлы, включенные в путь к классу сервера?

Эти настройки должны быть записаны в образе контейнера, работающем в Azure Red Hat OpenShift. Дополнительные сведения см. в разделе "Настройка JBoss EAP для образа OpenShift для приложения Java" в документации по Red Hat.

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

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

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

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

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

Дополнительные сведения см. в разделе "Настройка обмена сообщениями" в документации по Red Hat.

Определение того, используются ли настраиваемые общие библиотеки Java EE

Если вы используете общие библиотеки Java EE, у вас есть два варианта:

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

Эти библиотеки можно обрабатывать с помощью таких же методов, как описано в разделе "Определение того , настроен ли JBoss EAP".

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

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

Azure Red Hat OpenShift работает в OpenShift 4 с помощью Red Hat Enterprise Linux CoreOS (RHCOS) в качестве операционной системы для всех рабочих узлов и плоскостей управления. Любой код, зависящий от ОС, должен быть совместим с RHCOS.

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

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

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

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

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

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

Учет требований к балансировке нагрузки

Лучший способ учесть балансировку нагрузки — использовать интеграцию шлюза приложений. Дополнительные сведения см. в разделе "Что такое Шлюз приложений Azure?"

Миграция

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

Подготовка предложения

Чтобы открыть предложение в портал Azure, см. статью JBoss EAP в Azure Red Hat OpenShift. Нажмите кнопку "Создать", а затем следуйте инструкциям в предложении.

Миграция приложений

Предложение поддерживает процесс создания и запуска приложения Java на образе JBoss EAP для OpenShift. Red Hat содержит пример, показывающий, как это сделать вручную, если вы хотите развернуть позже самостоятельно. Дополнительные сведения см. в главе 2. Создание и запуск приложения Java в JBoss EAP для OpenShift Image в документации По Red Hat.

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

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

• Реализовать масштабирование. Динамическое масштабирование — это ключевое предложение, позволяющее оправдать сложность использования Azure Red Hat OpenShift. Сведения о достижении масштабирования решения см. в статье "Применение автомасштабирования к кластеру платформы контейнеров OpenShift" в документации По OpenShift.

• Вам может потребоваться выполнить дополнительную настройку на Шлюз приложений. Дополнительные сведения см. в статье Обзор конфигурации шлюза приложений.

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

• Получите мониторинг производительности приложений, оптимизированных для Java, с помощью Azure Monitor и Приложений Аналитика. Дополнительные сведения см. в статье "Мониторинг приложений с нулевой инструментацией" для Kubernetes — Аналитика приложения Azure Monitor.

• Разверните приложения в перенесенном кластере Azure Red Hat OpenShift с помощью Azure DevOps. Дополнительные сведения см. в документации по Azure DevOps.

• Используйте управляемые удостоверения Azure для управления секретами и назначения доступа на основе ролей к ресурсам Azure. См. сведения об управляемых удостоверениях для ресурсов Azure.

• Интеграция проверки подлинности и авторизации Java EE с идентификатором Microsoft Entra. Дополнительные сведения см . в руководстве по интеграции идентификатора Microsoft Entra с приложениями.