Перенос приложений WebLogic Server в JBoss EAP в службе приложение Azure
В этом руководстве описывается, что следует учитывать при переносе существующего приложения WebLogic Server для запуска в службе приложение Azure с помощью JBoss EAP.
Подготовка к миграции
Чтобы обеспечить успешную миграцию, перед ее началом выполните шаги оценки и инвентаризации, описанные в следующих разделах.
Если вы не можете выполнить какие-либо из этих предварительных требований миграции, см. руководство по переносу приложений в Виртуальные машины. Перенос приложений WebLogic Server в Azure Виртуальные машины
Проверка емкости сервера
Определите характеристики оборудования текущих рабочих серверов (показатели памяти, ЦП и диска), а также среднее и пиковое количество запросов и объем потребляемых ресурсов. Эти сведения понадобятся, независимо от выбранного пути миграции. Это полезно, например, чтобы помочь выбрать план Служба приложений.
Список доступных уровней плана Служба приложений отображает сведения о памяти, ядрах ЦП, хранилище и ценах. Обратите внимание, что JBoss EAP на Служба приложений доступен только на уровнях плана "Премиум" версии 3 и "Изолированный" версии 2 Служба приложений.
Проверка всех секретов
До появления таких технологических решений "конфигурация как услуга", как Azure Key Vault, понятие "секреты" не было четко определено. Вместо этого предоставлялся разнородный набор параметров конфигурации, которые использовались в качестве того, что сейчас называется секретами. При использовании серверов приложений, таких как WebLogic Server, эти секреты находятся в разных файлах конфигурации и хранилищах конфигураций. Проверьте все свойства и файлы конфигурации на рабочих серверах на наличие секретов и паролей. Обязательно проверьте наличие файла weblogic.xml в WAR-файлах. Кроме того, в приложении могут быть файлы конфигурации, содержащие пароли или учетные данные. См. основные понятия Azure Key Vault.
Проверка всех сертификатов
Определите все сертификаты, используемые для общедоступных конечных точек SSL. Вы можете просмотреть все сертификаты на рабочих серверах, выполнив следующую команду:
keytool -list -v -keystore <path to keystore>
Проверка ресурсов JNDI
Проверьте все ресурсы JNDI. Например, у источников данных, таких как базы данных, может быть связанное имя JNDI, которое позволяет JPA правильно привязывать экземпляры EntityManager
к определенной базе данных. См. сведения о ресурсах и базах данных JNDI в описании источников данных WebLogic Server в документации по Oracle. Для других ресурсов, связанных с JNDI, таких как брокеры сообщений JMS, может потребоваться выполнить миграцию или перенастройку. Дополнительные сведения о конфигурации JMS см. в статье Oracle WebLogic Server 12.2.1.4.0.
Инспекция конфигурации домена
Основной единицей конфигурации на сервере WebLogic Server является домен. Следовательно, файл config.xml содержит множество конфигураций, которые необходимо внимательно проверить перед миграцией. Файл содержит ссылки на дополнительные XML-файлы, которые хранятся в подкаталогах. Oracle рекомендует использовать консоль администрирования для настройки управляемых объектов и служб WebLogic Server, а также включить для сервера WebLogic Server поддержку файла config.xml. См. сведения о файлах конфигурации домена.
В приложении
Проверьте файлы WEB-INF/weblogic.xml и (или) WEB-INF/web.xml.
Определение того, используется ли репликация сеансов
Если работа приложения зависит от репликации сеансов с помощью модуля Oracle Coherence*Web или без него, у вас есть два варианта:
- Выполните рефакторинг приложения, чтобы использовать базу данных для управления сеансами.
- Выполните рефакторинг приложения, чтобы перенести сеанс в службу Redis Azure. См. сведения на странице с ценами на Azure Cache for Redis.
Для всех этих вариантов рекомендуется указать, как именно WebLogic выполняет репликацию состояния сеанса HTTP. См. руководство по репликации состояния сеанса HTTP в документации Oracle.
Определение источников данных
Если приложение использует какие-либо базы данных, необходимо определить следующие сведения:
- имя источника данных;
- конфигурация пула подключений;
- путь к JAR-файлу драйвера JDBC.
См. руководство по использованию драйверов JDBC с WebLogic Server.
Определение того, была ли настроена платформа WebLogic
Определите, какие из следующих настроек были сделаны.
- Были ли изменены скрипты запуска? Эти скрипты включают setDomainEnv, commEnv, startWebLogic и stopWebLogic.
- Есть ли какие-либо определенные параметры, передаваемые в виртуальную машину Java?
- Есть ли JAR-файлы, включенные в путь к классу сервера?
Определение того, нужно ли подключаться к локальной среде
Если вашему приложению требуется доступ к какой-либо из локальных служб, вам необходимо подготовить одну из служб подключения Azure. Дополнительные сведения см. в статье Выбор решения для подключения локальной сети к Azure. Кроме того, необходимо выполнить рефакторинг приложения, чтобы использовать общедоступные API-интерфейсы, предоставляемые локальными ресурсами.
Определение того, используются ли очереди или разделы Java Message Service (JMS)
Если приложение использует очереди или разделы JMS, их необходимо перенести на внешний сервер JMS. Использование Служебной шины Azure и Расширенного протокола управления очередью сообщений (AMQP) — это подходящая стратегия миграции для тех, кто работает с JMS. Дополнительные сведения см. в разделе "Использование службы сообщений Java 1.1" с Служебная шина Azure standard и AMQP 1.0.
Если постоянные хранилища JMS настроены, вам нужно записать их конфигурацию и применить ее после миграции.
Определение того, используются ли настраиваемые общие библиотеки Java EE
Если вы используете общие библиотеки Java EE, у вас есть два варианта:
- Выполните рефакторинг кода приложения, чтобы удалить все зависимости от библиотек и внедрить функции непосредственно в приложение.
- Включите библиотеки в путь к классу сервера.
Определение того, используются ли пакеты OSGi
Если вы использовали пакеты OSGi, добавленные на сервер WebLogic Server, вам нужно будет добавить аналогичные JAR-файлы непосредственно в приложение.
Определение того, содержит ли приложение код, зависящий от ОС
Если приложение содержит любой код с зависимостями в ос узла, необходимо рефакторинговать его, чтобы удалить эти зависимости. Например, может потребоваться заменить любое использование /
или \
в пути к файловой системе или File.Separator
Paths.get
, если ваше приложение работает в Windows.
Определение того, используется ли Oracle Service Bus
Если приложение использует Oracle Service Bus (OSB), необходимо определить настройки этой службы. См. руководство по установке Oracle Service Bus.
Определение того, состоит ли приложение из нескольких WAR-файлов
Если приложение состоит из нескольких WAR-файлов, их следует рассматривать как отдельные приложения, как описано в этом руководстве.
Определение того, упаковано ли приложение как EAR-файл
Если приложение упаковано как EAR-файл, обязательно проверьте файлы application.xml и weblogic-application.xml, определив их конфигурации.
Определение всех внешних процессов и управляющих программ, запущенных на рабочих серверах
Если за пределами сервера приложений выполняются какие-либо процессы (например, управляющие программы мониторинга), вам нужно будет удалить их или перенести в другое расположение.
Проверка правильной работы поддерживаемой версии Java
JBoss EAP в службе приложение Azure поддерживает Java 8 и 11. Поэтому вам нужно проверить, может ли приложение правильно работать с этой поддерживаемой версией. Эта проверка особенно важна, если на текущем сервере используется поддерживаемая версия JDK (например, Oracle JDK или IBM OpenJ9).
Чтобы получить текущую версию Java, войдите на сервер в рабочей среде и выполните следующую команду:
java -version
Определение того, использует ли приложение запланированные задания
Запланированные задания, такие как задачи планировщика Quartz или задания cron в UNIX, НЕЛЬЗЯ использовать со Службой приложений Azure. Служба приложений Azure не будет препятствовать развертыванию приложения, содержащего запланированные задачи. Но если приложение масштабируется, одно запланированное задание может выполняться несколько раз в течение указанного периода. Это может привести к нежелательным последствиям.
Для выполнения запланированных заданий в Azure рекомендуется использовать Функции Azure с триггером таймера. Дополнительные сведения см. в статье Триггер таймера для Функций Azure. Переносить сам код задания в функцию не нужно. Функция может просто вызвать URL-адрес в приложении, чтобы активировать задание.
Примечание.
Чтобы предотвратить вредоносное использование, необходимо убедиться, что конечная точка вызова задания запрашивает ввод учетных данных. В этом случае функция для триггеров должна предоставить учетные данные.
Определение того, используется ли WebLogic Scripting Tool (WLST)
Если вы используете WLST для выполнения развертывания, вам потребуется оценить, что это делает. Если WLST изменяет какие-либо параметры (среды выполнения) приложения в рамках развертывания, необходимо убедиться, что эти параметры соответствуют одному из следующих параметров:
- они извлечены как параметры приложения;
- они внедрены в приложение;
- используется интерфейс командной строки (CLI) JBoss во время развертывания.
Если WLST делает больше, чем упоминалось выше, у вас будет дополнительная работа во время миграции.
Определение того, использует ли приложение API, зависящие от WebLogic
Если приложение использует API для конкретного веб-приложения, вам потребуется рефакторинг приложения, чтобы не использовать их. Например, если вы применили класс, упомянутый в справочнике по API Java для Oracle WebLogic Server, значит в вашем приложении используется API, зависящий от WebLogic. Набор средств миграции Red Hat для приложений может помочь в удалении и рефакторинге этих зависимостей.
Определение того, использует ли приложение компоненты Entity Bean или bean-компоненты CMP в стиле EJB 2.x
Если приложение использует сущности Beans или EJB 2.x стиле CMP, вам потребуется рефакторинг приложения, чтобы не использовать их.
Определение того, используется ли клиент приложения Java EE
Если у вас есть клиентские приложения, которые подключаются к приложению (серверу) с помощью функции клиента приложений Java EE, необходимо рефакторинг как клиентских приложений, так и приложения (сервера) для использования API HTTP.
Определение того, использовался ли план развертывания
Если план развертывания использовался для выполнения развертывания, необходимо оценить, какой план развертывания выполняется. Если план развертывания предусматривает простое развертывание, вы можете развернуть веб-приложение без изменений. В случае использования более сложного плана, определите, можно ли применить CLI JBoss для правильной настройки приложения в рамках развертывания. Если CLI JBoss невозможно использовать, выполните рефакторинг приложения таким образом, чтобы необходимость в плане развертывания отпала.
Определение того, используются ли таймеры EJB
Если приложение использует таймеры EJB, необходимо проверить, может ли код таймера EJB запускаться каждым экземпляром JBoss EAP независимо. Эта проверка необходима, так как при горизонтальном масштабировании Служба приложений каждый таймер EJB будет активирован в собственном экземпляре JBoss EAP.
Проверка того, используется ли файловая система и как она используется
Для использования файловой системы на сервере приложений требуется перенастройка или, в редких случаях, изменение архитектуры. Файловая система может использоваться общими модулями WebLogic или кодом приложения. Вы можете определить некоторые или все сценарии, описанные ниже.
Статическое содержимое только для чтения
Если приложение в настоящее время обслуживает статическое содержимое, потребуется альтернативное расположение для этого статического содержимого. Вы можете рассмотреть возможность перемещения статического содержимого в Хранилище BLOB-объектов Azure и добавления Azure CDN для молниеносных скачиваний глобально.
Динамически опубликованное статическое содержимое
Если приложение допускает использование статического содержимого, которое передается или создается приложением и после этого становится неизменяемым, вы можете использовать хранилище BLOB-объектов Azure и Azure CDN, как описано выше, с Функциями Azure для выполнения отправки и обновления CDN. Мы предоставили пример реализации для вашего использования.
Динамическое или внутреннее содержимое
Для файлов, которые часто записываются и считываются приложением (например, временные файлы данных) или статические файлы, видимые только приложению, служба хранилища Azure можно подключить к файловой системе Служба приложений.
Определение того, используются ли соединители JCA
Если в приложении используются соединители JCA, необходимо проверить, можно ли использовать соединитель JCA в JBoss EAP. Если реализация JCA привязана к WebLogic, необходимо рефакторинг приложения, чтобы не использовать соединитель JCA. Если его можно использовать, необходимо добавить JAR в путь к классу сервера и поместить необходимые файлы конфигурации в правильное расположение в каталоги сервера JBoss EAP, чтобы он был доступен.
Определение того, использует ли приложение адаптер ресурсов
Если приложению требуется адаптер ресурсов, он должен быть совместимым с JBoss EAP. Определите, хорошо ли работает адаптер ресурсов в отдельном экземпляре JBoss EAP, развернув его на сервере и правильно настроив. Если RA работает правильно, необходимо добавить JAR в путь к классу сервера экземпляра Служба приложений и поместить необходимые файлы конфигурации в правильное расположение в каталоги сервера JBoss EAP, чтобы он был доступен.
Определение того, используется ли JAAS
Если приложение использует JAAS, необходимо записать настройку JAAS. Если используется база данных, ее можно преобразовать в домен JAAS в JBoss EAP. Если используется пользовательская реализация, необходимо проверить, можно ли использовать ее в JBoss EAP.
Определение того, используется ли кластеризация WebLogic
Скорее всего, вы развернули приложение на нескольких серверах WebLogic Server для обеспечения высокой доступности. служба приложение Azure может масштабироваться, но если вы использовали API кластера WebLogic, вам потребуется рефакторинг кода для устранения использования этого API.
Миграция
Набор средств миграции 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" в разделе "Настройка приложения Java для службы приложение Azure".
Перенос внешних параметров
Если вам нужно использовать внешние параметры, их необходимо задать в качестве параметров приложения. Дополнительные сведения см. в разделе Настройка параметров приложения.
Перенос скриптов запуска
Если исходное приложение использовало пользовательский скрипт запуска, необходимо перенести его в скрипт Bash. Дополнительные сведения см. в разделе "Настройка конфигурации сервера приложений".
Указание секретов
Чтобы сохранить все секреты, относящиеся к вашему приложению, используйте параметры приложения. Если вы планируете использовать один и тот же секрет или секреты для нескольких приложений или требуется более точное определение политик доступа и возможностей аудита, используйте ссылки На Azure Key Vault. Дополнительные сведения см. в разделе "Use KeyVault References" статьи "Настройка приложения Java для службы приложение Azure".
Настройка личного домена и SSL
Если приложение будет отображаться в личном домене, вам нужно будет сопоставить с ним веб-приложение. Дополнительные сведения см. в статье Сопоставление существующего настраиваемого DNS-имени со Службой приложений Azure.
Затем необходимо привязать TLS/SSL-сертификат для этого домена к веб-приложению Служба приложений. Дополнительные сведения см. в учебнике Защита пользовательского DNS-имени с помощью привязки TLS/SSL в Службе приложений Azure.
Перенос источников данных, библиотек и ресурсов JNDI
Чтобы перенести источники данных, выполните действия, описанные в разделе "Настройка источников данных" в разделе "Настройка приложения Java для службы приложение Azure".
Выполните миграцию дополнительных зависимостей классов уровня сервера, следуя инструкциям в разделе JBoss EAP настройки приложения Java для службы приложение Azure.
Перенос дополнительных ресурсов JDNI на уровне общего сервера. Дополнительные сведения см. в разделе JBoss EAP о настройке приложения Java для службы приложение Azure.
Перенос соединителей JCA и модулей JAAS
Перенесите все соединители JCA и модули JAAS, следуя инструкциям по установке модулей и зависимостей.
Примечание.
Если вы используете рекомендуемую архитектуру одного WAR для каждого приложения, рассмотрите возможность переноса библиотек классов уровня сервера и ресурсов JNDI в приложение. Это значительно упрощает управление компонентами и управление изменениями. Если вы хотите развернуть несколько WAR для каждого приложения, ознакомьтесь с одним из наших вспомогательных руководств, упомянутых в начале этого руководства.
Перенос запланированных заданий
Как минимум, вы должны переместить запланированные задания на виртуальную машину Azure, чтобы они больше не были частью приложения. Кроме того, вы можете модернизировать их на основе событий Java с помощью таких служб Azure, как Функции Azure, База данных SQL и Центры событий.
Перезапуск и тест состояния
Наконец, перезапустите веб-приложение, чтобы применить все изменения конфигурации. После завершения перезагрузки убедитесь, что приложение работает правильно.
После миграции
После переноса приложения в Службу приложений Azure нужно убедиться, что оно работает правильно. После этого у нас есть некоторые рекомендации, которые могут сделать приложение более облачным.
Рекомендации
Если для хранения файлов вы решили использовать каталог /home, попробуйте заменить его службой хранилища Azure. Дополнительные сведения см. в разделе "Подключение служба хранилища Azure в качестве локальной общей папки в пользовательском контейнере в Служба приложений".
Если у вас есть конфигурация в каталоге /home, который содержит строка подключения, ssl-ключи и другие секретные сведения, рассмотрите возможность использования сочетания azure Key Vault и внедрения параметров с параметрами приложения, где это возможно. Дополнительные сведения см. в статье "Использование ссылок Key Vault для Служба приложений и Функции Azure" и "Настройка приложения Служба приложений".
Для предоставления надежных развертываний с нулевым временем простоя вы можете использовать слоты развертывания. См. сведения о том, как настраивать промежуточные среды в Службе приложений Azure.
Разработайте и реализуйте стратегию DevOps. Чтобы обеспечить надежность и ускорить разработку, вы можете автоматизировать развертывание и тестирование с помощью Azure Pipelines. Дополнительные сведения см. в статье "Сборка и развертывание в веб-приложении Java". Если вы используете слоты развертывания, можно автоматизировать развертывание в слоте и последующем переключении слотов. Дополнительные сведения см. в разделе "Пример: развертывание в слоте" раздела "Развертывание в Служба приложений с помощью Azure Pipelines".
Разработайте и реализуйте стратегии обеспечения непрерывности бизнес-процессов и аварийного восстановления. Для критически важных приложений вы можете использовать архитектуру развертывания с несколькими регионами. Дополнительные сведения см. в статье Высокодоступное веб-приложение с поддержкой нескольких регионов.