Перенос приложений WebSphere в WildFly в Службе Azure Kubernetes
Статья
Из этого руководства вы узнаете, что следует учитывать при переносе приложения WebSphere для запуска в WildFly в контейнере Службы Azure Kubernetes.
Подготовка к миграции
Чтобы обеспечить успешную миграцию, перед ее началом выполните шаги оценки и инвентаризации, описанные в следующих разделах.
Проверка емкости сервера
Определите характеристики оборудования текущих рабочих серверов (показатели памяти, ЦП и диска), а также среднее и пиковое количество запросов и объем потребляемых ресурсов. Эти сведения понадобятся, независимо от выбранного пути миграции. Это полезно, например, чтобы помочь выбрать размер виртуальных машин в пуле узлов, объем памяти, который будет использоваться контейнером, и сколько ЦП разделяет потребности контейнера.
Проверьте все свойства и файлы конфигурации на рабочих серверах на наличие секретов и паролей. Обязательно проверьте наличие файла ibm-web-bnd.xml в WAR-файлах. Кроме того, в приложении могут быть файлы конфигурации, содержащие пароли или учетные данные.
Проверка всех сертификатов
Определите все сертификаты, используемые для общедоступных конечных точек SSL. Вы можете просмотреть все сертификаты на рабочих серверах, выполнив следующую команду:
keytool -list -v -keystore <path to keystore>
Проверка правильной работы поддерживаемой версии Java
Для работы WildFly в Службе Azure Kubernetes требуется определенная версия Java, поэтому вам нужно убедиться, может ли приложение правильно работать с этой поддерживаемой версией.
Примечание
Эта проверка особенно важна, если на текущем сервере используется неподдерживаемая версия JDK (например, Oracle JDK или IBM OpenJ9).
Чтобы получить текущую версию Java, войдите на сервер в рабочей среде и выполните следующую команду:
Определение того, используется ли файловая система и как именно она используется
Для использования файловой системы на сервере приложений требуется перенастройка или, в редких случаях, изменение архитектуры. Файловая система может использоваться модулями WebSphere или кодом приложения. Вы можете определить некоторые или все сценарии, описанные в следующих разделах.
Если приложение допускает использование статического содержимого, которое передается или создается приложением и после этого становится неизменяемым, вы можете использовать хранилище BLOB-объектов Azure и Azure CDN, как описано выше, с Функциями Azure для выполнения отправки и обновления CDN. Практический пример реализации см. в руководстве по отправке и предварительной загрузке статического содержимого CDN с помощью Функций Azure.
Динамическое или внутреннее содержимое
Для использования файлов, которые часто записываются и считываются приложением (например, временные файлы данных), или статических файлов, видимых только для вашего приложения, вы можете подключить общие папки службы хранилища Azure в качестве постоянных томов. Дополнительные сведения см. в статье "Создание и использование тома с Файлы Azure" в Служба Azure Kubernetes (AKS).
Определение того, использует ли приложение запланированные задания
Запланированные задания, такие как задачи Планировщика Поваренса или задания unix cron, не должны использоваться с Служба Azure Kubernetes (AKS). Служба Azure Kubernetes не будет препятствовать развертыванию приложения, содержащего запланированные задачи. Но если приложение масштабируется, одно запланированное задание может выполняться несколько раз в течение указанного периода. Это может привести к нежелательным последствиям.
Определение того, нужно ли подключаться к локальной среде
Если вашему приложению требуется доступ к какой-либо из локальных служб, вам необходимо подготовить одну из служб подключения Azure. Дополнительные сведения см. в статье Выбор решения для подключения локальной сети к Azure. Кроме того, необходимо выполнить рефакторинг приложения, чтобы использовать общедоступные API-интерфейсы, предоставляемые локальными ресурсами.
Определение того, используются ли очереди или разделы Java Message Service (JMS)
Если приложение использует очереди или разделы JMS, их необходимо перенести на внешний сервер JMS. Использование Служебной шины Azure и Расширенного протокола управления очередью сообщений (AMQP) — это подходящая стратегия миграции для тех, кто работает с JMS. Дополнительные сведения см. в разделе "Использование службы сообщений Java 1.1" с Служебная шина Azure standard и AMQP 1.0.
Если постоянные хранилища JMS настроены, вам нужно записать их конфигурацию и применить ее после миграции.
Определение того, использует ли приложение API, зависящие от WebSphere
Если приложение использует API, зависящие от WebSphere, необходимо выполнить рефакторинг для удаления этих зависимостей. Например, если вы применили класс, упомянутый в спецификации по API, IBM WebSphere Application Server (выпуск 9.0), значит вы использовали API WebSphere в приложении.
Определение того, использует ли приложение компоненты Entity Bean или bean-компоненты CMP в стиле EJB 2.x
Если ваше приложение использует компоненты Entity Bean или bean-компоненты CMP в стиле EJB 2.x, необходимо выполнить рефакторинг приложения, чтобы удалить эти зависимости.
Определение того, используется ли клиент приложения Java EE
Если у вас есть клиентские приложения, подключающиеся к серверному приложению с помощью клиента приложения Java EE, необходимо выполнить рефакторинг как клиентских приложений, так и серверного приложения для использования API HTTP.
Определение того, содержит ли приложение код, зависящий от ОС
Если приложение содержит любой код с зависимостями в ос узла, необходимо рефакторинговать его, чтобы удалить эти зависимости. Например, может потребоваться заменить любое использование / или \ в пути к файловой системе или File.SeparatorPaths.get , если ваше приложение работает в Windows.
Определение того, используются ли таймеры EJB
Если приложение использует таймеры EJB, необходимо убедиться, что код таймера EJB может активироваться каждым экземпляром WildFly независимо друг от друга. Эта проверка необходима, так как в сценарии развертывания Службы Kubernetes Azure каждый таймер EJB будет активироваться в собственном экземпляре WildFly.
Определение того, используются ли соединители JCA
Если приложение использует соединители JCA, нужно проверить, можно ли использовать такой соединитель в WildFly. Если же реализация JCA связана с WebSphere, необходимо выполнить рефакторинг приложения, чтобы удалить эту зависимость. Если это возможно, добавьте JAR в путь к классу сервера и поместите необходимые файлы конфигурации в нужное расположение в каталогах сервера WildFly, чтобы обеспечить доступность.
Определение того, используется ли JAAS
Если приложение использует JAAS, необходимо определить настройки JAAS. Если используется база данных, ее можно преобразовать в домен JAAS в WildFly. Если используется пользовательская реализация, необходимо проверить, можно ли использовать ее в WildFly.
Определение того, использует ли приложение адаптер ресурсов
Если приложению требуется адаптер ресурсов, он должен быть совместим с WildFly. Определите, хорошо ли работает адаптер ресурсов в отдельном экземпляре WildFly, развернув его на сервере и правильно настроив. Если адаптер ресурсов работает правильно, добавьте JAR в путь к классу сервера образа Docker и поместите необходимые файлы конфигурации в нужное расположение в каталогах сервера WildFly, чтобы обеспечить доступность.
Определение того, состоит ли приложение из нескольких WAR-файлов
Если приложение состоит из нескольких WAR-файлов, их следует рассматривать как отдельные приложения, как описано в этом руководстве.
Определение того, упаковано ли приложение как EAR-файл
Если приложение упаковано как EAR-файл, обязательно проверьте файлы application.xml и application-bnd.xml, определив их конфигурации.
Примечание
Если вы хотите масштабировать каждую из веб-приложений независимо для лучшего использования ресурсов Служба Azure Kubernetes (AKS), следует разбить EAR на отдельные веб-приложения.
Определение всех внешних процессов и управляющих программ, запущенных на рабочих серверах
Если за пределами сервера приложений выполняются какие-либо процессы (например, управляющие программы мониторинга), вам нужно будет удалить их или перенести в другое расположение.
Тестирование на месте
Прежде чем создавать образы контейнеров, перенесите приложение в JDK и версии WildFly для использования в AKS. Тщательно протестируйте приложение, чтобы обеспечить совместимость и высокую производительность.
Миграция
Подготовка Реестра контейнеров Azure и Службы Kubernetes Azure
Используйте следующие команды, чтобы создать Реестр контейнеров и кластер Azure Kubernetes, субъект-служба которого имеет роль читателя в реестре. Не забудьте выбрать соответствующую модель сети в соответствии с требованиями к сети кластера.
az group create \
--resource-group $resourceGroup \
--location eastus
az acr create \
--resource-group $resourceGroup \
--name $acrName \
--sku Standard
az aks create \
--resource-group $resourceGroup \
--name $aksName \
--attach-acr $acrName \
--network-plugin azure
Создание образа Docker для WildFly
Чтобы создать Dockerfile, вам потребуется следующее:
поддерживаемый пакет JDK;
установленная версия WildFly;
среда выполнения JVM;
способ передачи переменных среды (если применимо).
Кроме того, потребуется обновить скрипт запуска, используемый для начальной загрузки WildFly. Этот скрипт перед запуском сервера должен импортировать сертификаты в хранилище ключей, используемое WildFly.
Настройка источников данных
Чтобы настроить WildFly для доступа к источнику данных, необходимо добавить JAR-файл драйвера JDBC в образ Docker, а затем выполнить соответствующие команды интерфейса командной строки JBoss. Эти команды должны настроить источник данных при создании образа Docker.
Следующие шаги содержат инструкции для PostgreSQL, MySQL и SQL Server.
Распакуйте загруженный архив, чтобы получить JAR-файл драйвера.
Создайте файл (например, с именем module.xml), и добавьте следующую разметку. Замените заполнитель <module name> (включая угловые скобки) на org.postgres для PostgreSQL, на com.mysql для MySQL или на com.microsoft для SQL Server. Замените <JDBC .jar file path> именем JAR-файла из предыдущего шага, включая полный путь к расположению, в которое будет помещен файл в образе Docker, например в /opt/database.
Создайте файл (например, с именем datasource-commands.cli), и добавьте следующий код. Замените <JDBC .jar file path> значением, использованным на предыдущем шаге. Замените <module file path> именем файла и путем из предыдущего шага, например /opt/database/module.xml.
Примечание
Корпорация Майкрософт рекомендует использовать самый безопасный поток проверки подлинности. Поток проверки подлинности, описанный в этой процедуре, например для баз данных, кэшей, сообщений или служб ИИ, требует очень высокой степени доверия к приложению и несет риски, не присутствующих в других потоках. Используйте этот поток, только если более безопасные параметры, такие как управляемые удостоверения для бессерверных или бессерверных подключений, не являются жизнеспособными. Для локальных операций компьютера предпочитайте удостоверения пользователей для бессерверных или бессерверных подключений.
Обновите конфигурацию источника данных JTA для приложения:
Откройте файл src/main/resources/META-INF/persistence.xml для приложения и найдите элемент <jta-data-source>. Замените его содержимое, как показано ниже:
Определите используемые адреса DATABASE_CONNECTION_URL, так как они отличаются для каждого сервера базы данных и отличаются от указанных на портале Azure. Указанные здесь форматы URL-адресов являются обязательными при использовании WildFly:
jdbc:postgresql://<database server name>:5432/<database name>?ssl=true
jdbc:mysql://<database server name>:3306/<database name>?ssl=true\&useLegacyDatetimeCode=false\&serverTimezone=GMT
jdbc:sqlserver://<database server name>:1433;database=<database name>;user=<admin name>;password=<admin password>;encrypt=true;trustServerCertificate=false;hostNameInCertificate=*.database.windows.net;loginTimeout=30;
При создании развертывания YAML на более позднем этапе потребуется передать с соответствующими значениями следующие переменные среды: DATABASE_CONNECTION_URL, DATABASE_SERVER_ADMIN_FULL_NAME и DATABASE_SERVER_ADMIN_PASSWORD.
Примечание
Корпорация Майкрософт рекомендует использовать самый безопасный поток проверки подлинности. Поток проверки подлинности, описанный в этой процедуре, например для баз данных, кэшей, сообщений или служб ИИ, требует очень высокой степени доверия к приложению и несет риски, не присутствующих в других потоках. Используйте этот поток, только если более безопасные параметры, такие как управляемые удостоверения для бессерверных или бессерверных подключений, не являются жизнеспособными. Для локальных операций компьютера предпочитайте удостоверения пользователей для бессерверных или бессерверных подключений.
Дополнительные сведения о настройке подключения к базе данных с помощью WildFly см. в статьях для PostgreSQL, MySQL или SQL Server.
Настройка ресурсов JNDI
Чтобы настроить каждый ресурс JNDI для WildFly, обычно необходимо выполнить следующие действия.
Загрузите необходимые JAR-файлы и скопируйте их в образ Docker.
Создайте файл WildFly module.xml, ссылающийся на эти JAR-файлы.
Создайте конфигурацию, необходимую для определенного ресурса JNDI.
Создайте скрипт командной строки JBoss, который будет использоваться во время сборки Docker для регистрации ресурса JNDI.
Добавьте все это в Dockerfile.
Передайте соответствующие переменные среды в развертывание YAML.
В приведенном ниже примере показаны шаги, необходимые для создания ресурса JNDI для подключения JMS к служебной шине Azure.
Распакуйте загруженный архив, чтобы получить JAR-файлы.
Создайте файл (например, с именем module.xml), и добавьте следующую разметку в /opt/servicebus. Убедитесь, что номера версий JAR-файлов совпадают с именами JAR-файлов в предыдущем шаге.
При создании развертывания YAML на более позднем этапе потребуется передать с соответствующими значениями следующие переменные среды: MDB_CONNECTION_FACTORY, DEFAULT_SBNAMESPACE, SB_SAS_POLICY, SB_SAS_KEY, MDB_QUEUE, SB_QUEUE, MDB_TOPIC и SB_TOPIC.
В этих примерах переменная среды MY_ACR содержит имя Реестра контейнеров Azure, а переменная MY_APP_NAME содержит имя веб-приложения, используемого в Реестре контейнеров Azure.
Создание WAR-файла:
mvn package
Войдите в Реестр контейнеров Azure:
az acr login --name ${MY_ACR}
Сборка и передача образа:
az acr build --image ${MY_ACR}.azurecr.io/${MY_APP_NAME} --file src/main/docker/Dockerfile .
Кроме того, с помощью Docker CLI можно сначала создать и протестировать образ локально, как показано в следующих командах. Такой подход упрощает тестирование и дополнительную настройку образа перед первым развертыванием в ACR. Однако для этого необходимо установить Docker CLI и убедиться, что управляющая программа Docker запущена.
Если ваше приложение должно быть доступным за пределами внутренней или виртуальной сети, требуется общедоступный статический IP-адрес. Этот IP-адрес следует подготовить в группе ресурсов узла кластера, как показано в следующем примере:
export nodeResourceGroup=$(az aks show \
--resource-group $resourceGroup \
--name $aksName \
--query 'nodeResourceGroup' \
--output tsv)
export publicIp=$(az network public-ip create \
--resource-group $nodeResourceGroup \
--name applicationIp \
--sku Standard \
--allocation-method Static \
--query 'publicIp.ipAddress' \
--output tsv)
echo "Your public IP address is ${publicIp}."
Включите внешние параметры в качестве переменных среды. См. сведения об определении переменных среды для контейнера. Не включайте секреты (например, пароли, ключи API и строки подключения JDBC). Они описаны в следующих разделах.
Не забудьте включить параметры памяти и ЦП при создании YAML развертывания, чтобы контейнеры имели правильный размер.
Настройка постоянного хранилища
Если для работы приложения требуется энергонезависимое хранилище, настройте один или несколько постоянных томов.
После переноса приложения в Azure Kubernetes Service нужно убедиться, что оно работает правильно. Выполнив проверку, можете применить некоторые рекомендации, которые помогут сделать ваше приложение более удобным для использования в облаке.
Вы также можете добавить диаграммы Helm для приложения. Чарты Helm позволяют параметризировать развертывание приложения для использования и настройки различными клиентами.
Включите мониторинг Azure для этого кластера. Дополнительные сведения см. в разделе "Включение мониторинга для кластеров Kubernetes". Это позволяет Azure Monitor получать журналы контейнеров, отслеживать использование и т. д.
Вы можете предоставить метрики конкретного приложения через Prometheus. Prometheus — это платформа метрик с открытым кодом, широко используемая в сообществе Kubernetes. Вы можете настроить метрики Prometheus в Azure Monitor, чтобы не размещать собственный сервер Prometheus. Так вы включите агрегирование метрик из приложений и автоматическое реагирование или эскалацию при возникновении аномальных условий. Дополнительные сведения см. в разделе "Включить Prometheus" и "Grafana".
Убедитесь, что в файле развертывания указано, как выполняются последовательные обновления. Дополнительные сведения см. в статье Rolling Update Deployment (Развертывание последовательного обновления) в документации по Kubernetes.
Для дальнейшей оптимизации производительности вы можете отслеживать размер кэша кода и добавить параметры JVM -XX:InitialCodeCacheSize и -XX:ReservedCodeCacheSize в Dockerfile. Дополнительные сведения см. в разделе Codecache Tuning (Настройка параметра Codecache) в документации Oracle.