Поделиться через

Перенос приложений WebLogic Server в WildFly на Служба Azure Kubernetes

  • Статья

В этом руководстве описывается, что следует учитывать при переносе существующего приложения WebLogic Server для запуска в WildFly в контейнере Служба Azure Kubernetes.

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

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

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

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

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

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

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

До появления таких технологических решений "конфигурация как услуга", как 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.

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

Если работа приложения зависит от репликации сеансов с помощью модуля Oracle Coherence*Web или без него, у вас есть два варианта:

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

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

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

  • имя источника данных;
  • конфигурация пула подключений;
  • путь к 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, определив их конфигурации.

Примечание.

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

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

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

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

Для работы WildFly в Службе Azure Kubernetes требуется определенная версия Java, поэтому вам нужно убедиться, может ли приложение правильно работать с этой поддерживаемой версией.

Примечание.

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

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

java -version

См. сведения о том, какую версию следует использовать для запуска WildFly.

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

Запланированные задания, такие как задачи Планировщика Поваренса или задания unix cron, не должны использоваться с Служба Azure Kubernetes (AKS). Служба Azure Kubernetes не будет препятствовать развертыванию приложения, содержащего запланированные задачи. Но если приложение масштабируется, одно запланированное задание может выполняться несколько раз в течение указанного периода. Это может привести к нежелательным последствиям.

Чтобы выполнить запланированные задания в кластере AKS, определите требуемые задания Kubernetes CronJobs. См. сведения о выполнении автоматизированных задач с помощью CronJob.

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

Если вы используете средство разработки скриптов WebLogic (WLST) для выполнения развертывания, вам потребуется оценить, что это делает. Если WLST изменяет любые параметры (среда выполнения) приложения в рамках развертывания, убедитесь, что эти параметры соответствуют одному из следующих параметров:

  • Параметры внешние в качестве параметров приложения.
  • Параметры внедрены в приложение.
  • Параметры используют интерфейс командной строки JBoss во время развертывания.

Если WLST делает больше, чем упоминалось выше, у вас будет дополнительная работа во время миграции.

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

Если приложение использует интерфейсы API, зависящие от WebLogic, необходимо выполнить рефакторинг для удаления этих зависимостей. Например, если вы применили класс, упомянутый в справочнике по API Java для Oracle WebLogic Server, значит в вашем приложении используется API, зависящий от WebLogic. Для удаления ссылки потребуется рефакторинг.

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

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

Определение того, используется ли клиент приложения Java EE

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

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

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

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

Если приложение использует таймеры EJB, необходимо убедиться, что код таймера EJB может активироваться каждым экземпляром WildFly независимо друг от друга. Эта проверка необходима, так как в сценарии развертывания Службы Kubernetes Azure каждый таймер EJB будет активироваться в собственном экземпляре WildFly.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Скорее всего, вы развернули приложение на нескольких серверах WebLogic Server для обеспечения высокой доступности. Служба Azure Kubernetes может масштабироваться, но если вы использовали API кластера WebLogic, необходимо рефакторинг кода, чтобы исключить использование этого API.

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

Прежде чем создавать образы контейнеров, перенесите приложение в 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;
  • способ передачи переменных среды (если применимо).

Затем можно выполнить действия, описанные в следующих разделах, там, где это применимо. В качестве отправной точки для работы с Dockerfile и веб-приложения можно использовать репозиторий для быстрого начала работы с контейнерами WildFly.

Настройка хранилища ключей FlexVolume

Создайте хранилище ключей в Azure и укажите все необходимые секреты. Дополнительные сведения см . в кратком руководстве по настройке и извлечению секрета из Azure Key Vault с помощью Azure CLI. Затем настройте хранилище ключей FlexVolume, чтобы сделать эти секреты доступными для групп pod.

Кроме того, потребуется обновить скрипт запуска, используемый для начальной загрузки WildFly. Этот скрипт перед запуском сервера должен импортировать сертификаты в хранилище ключей, используемое WildFly.

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

Чтобы настроить WildFly для доступа к источнику данных, необходимо добавить JAR-файл драйвера JDBC в образ Docker, а затем выполнить соответствующие команды интерфейса командной строки JBoss. Эти команды должны настроить источник данных при создании образа Docker.

Следующие шаги содержат инструкции для PostgreSQL, MySQL и SQL Server.

  1. Загрузите драйвер JDBC для PostgreSQL, MySQL или SQL Server.

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

  2. Создайте файл (например, с именем module.xml), и добавьте следующую разметку. Замените заполнитель <module name> (включая угловые скобки) на org.postgres для PostgreSQL, на com.mysql для MySQL или на com.microsoft для SQL Server. Замените <JDBC .jar file path> именем JAR-файла из предыдущего шага, включая полный путь к расположению, в которое будет помещен файл в образе Docker, например в /opt/database.

    <?xml version="1.0" ?>
<module xmlns="urn:jboss:module:1.1" name="<module name>">
    <resources>
       <resource-root path="<JDBC .jar file path>" />
    </resources>
    <dependencies>
        <module name="javax.api"/>
        <module name="javax.transaction.api"/>
    </dependencies>
</module>

  3. Создайте файл (например, с именем datasource-commands.cli), и добавьте следующий код. Замените <JDBC .jar file path> значением, использованным на предыдущем шаге. Замените <module file path> именем файла и путем из предыдущего шага, например /opt/database/module.xml.

    Примечание.

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

    batch
module add --name=org.postgres --resources=<JDBC .jar file path> --module-xml=<module file path>
/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=$DATABASE_CONNECTION_URL --user-name=$DATABASE_SERVER_ADMIN_FULL_NAME --password=$DATABASE_SERVER_ADMIN_PASSWORD --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
reload
run batch
shutdown

  4. Обновите конфигурацию источника данных JTA для приложения:

    Откройте файл src/main/resources/META-INF/persistence.xml для приложения и найдите элемент <jta-data-source>. Замените его содержимое, как показано ниже:

    <jta-data-source>java:jboss/datasources/postgresDS</jta-data-source>

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

    RUN /bin/bash -c '<WILDFLY_INSTALL_PATH>/bin/standalone.sh --start-mode admin-only &' && \
sleep 30 && \
<WILDFLY_INSTALL_PATH>/bin/jboss-cli.sh -c --file=/opt/database/datasource-commands.cli && \
sleep 30

  6. Определите используемые адреса DATABASE_CONNECTION_URL, так как они отличаются для каждого сервера базы данных и отличаются от указанных на портале Azure. Указанные здесь форматы URL-адресов являются обязательными при использовании WildFly:

    jdbc:postgresql://<database server name>:5432/<database name>?ssl=true

  7. При создании развертывания YAML на более позднем этапе потребуется передать с соответствующими значениями следующие переменные среды: DATABASE_CONNECTION_URL, DATABASE_SERVER_ADMIN_FULL_NAME и DATABASE_SERVER_ADMIN_PASSWORD.

Примечание.

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

Дополнительные сведения о настройке подключения к базе данных с помощью WildFly см. в статьях для PostgreSQL, MySQL или SQL Server.

Настройка ресурсов JNDI

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

  1. Загрузите необходимые JAR-файлы и скопируйте их в образ Docker.
  2. Создайте файл WildFly module.xml, ссылающийся на эти JAR-файлы.
  3. Создайте конфигурацию, необходимую для определенного ресурса JNDI.
  4. Создайте скрипт командной строки JBoss, который будет использоваться во время сборки Docker для регистрации ресурса JNDI.
  5. Добавьте все это в Dockerfile.
  6. Передайте соответствующие переменные среды в развертывание YAML.

В приведенном ниже примере показаны шаги, необходимые для создания ресурса JNDI для подключения JMS к служебной шине Azure.

  1. Загрузите поставщик JMS для Apache Qpid

    Распакуйте загруженный архив, чтобы получить JAR-файлы.

  2. Создайте файл (например, с именем module.xml), и добавьте следующую разметку в /opt/servicebus. Убедитесь, что номера версий JAR-файлов совпадают с именами JAR-файлов в предыдущем шаге.

    <?xml version="1.0" ?>
<module xmlns="urn:jboss:module:1.1" name="org.jboss.genericjms.provider">
 <resources>
  <resource-root path="proton-j-0.31.0.jar"/>
  <resource-root path="qpid-jms-client-0.40.0.jar"/>
  <resource-root path="slf4j-log4j12-1.7.25.jar"/>
  <resource-root path="slf4j-api-1.7.25.jar"/>
  <resource-root path="log4j-1.2.17.jar"/>
  <resource-root path="netty-buffer-4.1.32.Final.jar" />
  <resource-root path="netty-codec-4.1.32.Final.jar" />
  <resource-root path="netty-codec-http-4.1.32.Final.jar" />
  <resource-root path="netty-common-4.1.32.Final.jar" />
  <resource-root path="netty-handler-4.1.32.Final.jar" />
  <resource-root path="netty-resolver-4.1.32.Final.jar" />
  <resource-root path="netty-transport-4.1.32.Final.jar" />
  <resource-root path="netty-transport-native-epoll-4.1.32.Final-linux-x86_64.jar" />
  <resource-root path="netty-transport-native-kqueue-4.1.32.Final-osx-x86_64.jar" />
  <resource-root path="netty-transport-native-unix-common-4.1.32.Final.jar" />
  <resource-root path="qpid-jms-discovery-0.40.0.jar" />
 </resources>
 <dependencies>
  <module name="javax.api"/>
  <module name="javax.jms.api"/>
 </dependencies>
</module>

  3. Создайте файл jndi.properties в /opt/servicebus.

    connectionfactory.${MDB_CONNECTION_FACTORY}=amqps://${DEFAULT_SBNAMESPACE}.servicebus.windows.net?amqp.idleTimeout=120000&jms.username=${SB_SAS_POLICY}&jms.password=${SB_SAS_KEY}
queue.${MDB_QUEUE}=${SB_QUEUE}
topic.${MDB_TOPIC}=${SB_TOPIC}

  4. Создайте файл (например, с именем servicebus-commands.cli), и добавьте следующий код.

    batch
/subsystem=ee:write-attribute(name=annotation-property-replacement,value=true)
/system-property=property.mymdb.queue:add(value=myqueue)
/system-property=property.connection.factory:add(value=java:global/remoteJMS/SBF)
/subsystem=ee:list-add(name=global-modules, value={"name" => "org.jboss.genericjms.provider", "slot" =>"main"}
/subsystem=naming/binding="java:global/remoteJMS":add(binding-type=external-context,module=org.jboss.genericjms.provider,class=javax.naming.InitialContext,environment=[java.naming.factory.initial=org.apache.qpid.jms.jndi.JmsInitialContextFactory,org.jboss.as.naming.lookup.by.string=true,java.naming.provider.url=/opt/servicebus/jndi.properties])
/subsystem=resource-adapters/resource-adapter=generic-ra:add(module=org.jboss.genericjms,transaction-support=XATransaction)
/subsystem=resource-adapters/resource-adapter=generic-ra/connection-definitions=sbf-cd:add(class-name=org.jboss.resource.adapter.jms.JmsManagedConnectionFactory, jndi-name=java:/jms/${MDB_CONNECTION_FACTORY})
/subsystem=resource-adapters/resource-adapter=generic-ra/connection-definitions=sbf-cd/config-properties=ConnectionFactory:add(value=${MDB_CONNECTION_FACTORY})
/subsystem=resource-adapters/resource-adapter=generic-ra/connection-definitions=sbf-cd/config-properties=JndiParameters:add(value="java.naming.factory.initial=org.apache.qpid.jms.jndi.JmsInitialContextFactory;java.naming.provider.url=/opt/servicebus/jndi.properties")
/subsystem=resource-adapters/resource-adapter=generic-ra/connection-definitions=sbf-cd:write-attribute(name=security-application,value=true)
/subsystem=ejb3:write-attribute(name=default-resource-adapter-name, value=generic-ra)
run-batch
reload
shutdown

  5. Добавьте следующий код в Dockerfile, чтобы при сборке образа Docker создавался источник JNDI.

    RUN /bin/bash -c '<WILDFLY_INSTALL_PATH>/bin/standalone.sh --start-mode admin-only &' && \
sleep 30 && \
<WILDFLY_INSTALL_PATH>/bin/jboss-cli.sh -c --file=/opt/servicebus/servicebus-commands.cli && \
sleep 30

  6. При создании развертывания YAML на более позднем этапе потребуется передать с соответствующими значениями следующие переменные среды: MDB_CONNECTION_FACTORY, DEFAULT_SBNAMESPACE, SB_SAS_POLICY, SB_SAS_KEY, MDB_QUEUE, SB_QUEUE, MDB_TOPIC и SB_TOPIC.

Проверка конфигурации WildFly

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

Сборка и передача образа Docker в Реестр контейнеров Azure

После создания Dockerfile необходимо создать образ Docker и опубликовать его в Реестре контейнеров Azure.

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

В этих примерах переменная среды 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 запущена.

Сборка образа:

docker build -t ${MY_ACR}.azurecr.io/${MY_APP_NAME}

Локальный запуск образа:

docker run -it -p 8080:8080 ${MY_ACR}.azurecr.io/${MY_APP_NAME}

Теперь вы можете получить доступ к приложению по адресу http://localhost:8080.

Войдите в Реестр контейнеров Azure:

az acr login --name ${MY_ACR}

Передача образа в Реестр контейнеров Azure:

docker push ${MY_ACR}.azurecr.io/${MY_APP_NAME}

Более подробные сведения о создании и хранении образов контейнеров в Azure см. в модуле Создание и хранение образов контейнеров с помощью службы "Реестр контейнеров Azure".

Подготовка общедоступного IP-адреса

Если ваше приложение должно быть доступным за пределами внутренней или виртуальной сети, требуется общедоступный статический 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}."

Развертывание в службе Azure Kubernetes (AKS)

Создайте и примените файлы YAML Kubernetes. Дополнительные сведения см. в кратком руководстве по развертыванию кластера Служба Azure Kubernetes (AKS) с помощью Azure CLI. Если вы создаете внешний балансировщик нагрузки для приложения и контроллера входящего трафика, обязательно укажите IP-адрес (см. предыдущий раздел) в качестве LoadBalancerIP.

Включите внешние параметры в качестве переменных среды. См. сведения об определении переменных среды для контейнера. Не включайте секреты (например, пароли, ключи API и строки подключения JDBC). Они описаны в следующих разделах.

Не забудьте включить параметры памяти и ЦП при создании YAML развертывания, чтобы контейнеры имели правильный размер.

Настройка постоянного хранилища

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

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

Чтобы выполнить запланированные задания в кластере AKS, определите требуемые задания Kubernetes CronJobs. См. сведения о выполнении автоматизированных задач с помощью CronJob.

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

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

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