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

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

  • Статья

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

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

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

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

Первым шагом в успешной миграции приложения WLS в Azure является выбор наиболее подходящего целевого объекта миграции. WLS работает хорошо на виртуальных машинах Azure или Служба Azure Kubernetes (AKS). Целевой объект виртуальной машины — самый простой выбор, так как он больше всего похож на локальное развертывание. Интерфейс администрирования и развертывания для виртуальных машин очень аналогичен тому, что у вас есть в локальной среде. Компромисс для этой простоты является экономической стоимостью. Как правило, затраты на минуту решения на основе виртуальных машин выше по сравнению с AKS. Хотя решение на основе AKS стоит меньше для запуска, необходимо ограничить приложение в соответствии с требованиями AKS. Если минимизация изменений является самым важным фактором для усилий по миграции, рассмотрите возможность миграции на основе виртуальной машины. В этом случае см. статью "Миграция приложений WebLogic в Azure Виртуальные машины". Если вы можете терпеть преобразование приложения в Kubernetes для снижения затрат на среду выполнения, рассмотрите возможность миграции на основе AKS. В этом случае перейдите к Служба Azure Kubernetes приложениям WebLogic Server для миграции.

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

Когда вы решили, что AKS является подходящим целевым объектом развертывания, необходимо принять, что оператор Oracle WLS Kubernetes (оператор) является единственным способом запуска WLS в Kubernetes. После принятия этого факта необходимо решить, является ли предварительно созданное предложение Azure Marketplace хорошим отправным пунктом. Ниже приведены некоторые сведения о предварительно созданном предложении Azure Marketplace.

  • Oracle и Корпорация Майкрософт создали это предложение, чтобы быстро подготовить WLS в AKS с помощью модели в домашнем типе исходного источника домена image . Эта концепция подробно описана далее в этой статье.
  • На высоком уровне предложение автоматизирует следующие шаги.
    • При необходимости примите существующее развертывание WAR или EAR.
    • Заключите его в контейнер с помощью средства "Образ WebLogic" (WIT). Дополнительные сведения см. в статье WebLogic Image Tool в документации Oracle.
    • Установите и настройте оператор WebLogic Kubernetes в AKS.
    • Используйте оператор для выполнения всего действия. Оператор вызывает средство развертывания WebLogic (WDT) для создания среды WebLogic и выполнения операций жизненного цикла домена в повторяемом режиме на основе модели метаданных. Дополнительные сведения см. в статье "Средство развертывания WebLogic" в документации Oracle.
  • Хотя предварительно созданное предложение обеспечивает множество интеграции служб Azure, таких как Шлюз приложений, эластичное ведение журнала, интеграция базы данных и многое другое, это делает множество упрощенных предположений. Эти предположения делают предложение не столь гибким, как мастеринг и использование оператора самостоятельно.

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

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

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

Сначала необходимо понять концепцию домена WLS. Домен — это логическая группа ресурсов WLS. Каноническое определение домена WLS см . в документации Oracle. Запуск WLS в AKS требует принятия решения о том, как AKS работает с доменами. Различные варианты называются "типом источника домашнего домена". Оператор Kubernetes WLS поддерживает три варианта типа источника домашнего домена. Предварительно созданное предложение Azure Marketplace использует первый из них в этой таблице.

Тип источника домашнего домена Description Положительные аспекты Отрицательные аспекты
Модель на изображении WLS и приложения находятся на образе контейнера, и все остальное хранится вне этого образа. Поддерживается предварительно созданным предложением. Документирован как официальный пример; см. Oracle. В большинстве случаев используется WDT. Большинство вариантов cloud-native. Простейшая интеграция CI/CD. Самая большая кривая обучения.
Домен в PV Домен находится на постоянном томе Kubernetes. Концептуально похоже на выполнение на виртуальных машинах. Консоль WLS можно использовать для внесения изменений и сохранения этих изменений при перезапуске pod AKS. Документирован как официальный пример; см. Oracle. Некоторые проблемы, связанные с NFS, необходимо устранить. Дополнительные сведения см. в статье Oracle. Этот подход является наименее "облачным" методом; состояние находится полностью за пределами кластера AKS.
Домен в образе Домен находится в образе контейнера. Приложения содержатся в образе контейнера, наложенном на образ домена. Более "облачная", чем домен в PV. Проще для CI/CD. Не удается использовать консоль WLS. Должен поддерживать больше образов контейнеров.

Внимание

Если выбрать домен в исходном типе PV, настоятельно рекомендуется использовать NFS вместо S МБ. NFS развивался от операционной системы UNIX и других вариантов, таких как GNU/Linux. По этой причине при использовании NFS с такими технологиями контейнеров, как Docker, скорее всего, возникают проблемы с одновременными чтением и блокировкой файлов.

Обязательно включите NFS версии 4.1. Версии ниже версии 4.1 будут иметь проблемы.

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

Сведения о предварительно созданном предложении Azure Marketplace см. в кратком руководстве по развертыванию webLogic Server на Служба Azure Kubernetes с помощью портал Azure. Справочную документацию по предварительно созданному предложению Azure Marketplace см. в статье Oracle.

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

Теперь, когда вы познакомились с различными способами обработки доменов WLS в AKS, вы можете выбрать, следует ли использовать предварительно созданное предложение Azure Marketplace или сделать это самостоятельно с помощью оператора напрямую.

Определение совместимости с версией WebLogic

Существующая версия WLS должна быть одной из версий, поддерживаемых оператором. Oracle поддерживает эти версии в реестре контейнеров Oracle (OCR). Чтобы просмотреть список поддерживаемых версий, выполните следующие действия.

  1. Посетите веб-сайт Реестра контейнеров Oracle и войдите в систему. Дополнительные сведения см. в разделе https://container-registry.oracle.com/.
  2. Если у вас есть право на поддержку, выберите по промежуточному слоям, а затем найдите weblogic_cpu. Выберите weblogic_cpu.
  3. Если у вас нет прав на поддержку из Oracle, выберите по промежуточному слоям, а затем найдите веб-службу. Выберите weblogic.

Примечание.

Получите право на поддержку от Oracle, прежде чем перейти в рабочую среду. Сбой этого приводит к выполнению небезопасных образов, которые не исправлены для критических ошибок безопасности. Дополнительные сведения о критических обновлениях исправлений Oracle см. в разделе "Критически важные исправления" Обновления, "Оповещения системы безопасности" и "Бюллетени".

Предварительно созданное предложение Azure Marketplace позволяет выбирать образы WLS из OCR и Реестр контейнеров Azure (ACR), поэтому неявно поддерживает все версии, доступные в OCR. Если вы направляете предложение на извлечение образа из ACR, убедитесь, что оно является производным от одной из поддерживаемых версий, перечисленных в OCR.

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

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

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

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

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

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

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

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

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

После создания твердой инвентаризации сертификатов их можно установить непосредственно с предварительно созданным предложением Azure Marketplace. Дополнительные сведения см. в разделе "Конфигурация TLS/SSL". Если оператор используется непосредственно, см. раздел "Обновление внешних сертификатов оператора".

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

При использовании всех путей миграции в WebLogic в Azure требуется определенная соответствующая версия Java. Вам нужно проверить, может ли приложение правильно работать с этой поддерживаемой версией.

Примечание.

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

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

java -version

Примечание.

При миграции на виртуальные машины Azure на виртуальных машинах Azure требования к определенным версиям Java определяются предварительно установленным Java на виртуальных машинах. При миграции в WLS в AKS определенная версия Java определяется выбранным образом контейнера. Существует широкий спектр вариантов, но все они используют Oracle JDK.

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

Проверьте все ресурсы JNDI. Например, у источников данных, таких как базы данных, может быть связанное имя JNDI, которое позволяет JPA правильно привязывать экземпляры EntityManager к определенной базе данных. См. сведения о ресурсах и базах данных JNDI в описании источников данных WebLogic Server в документации по Oracle. Для других ресурсов, связанных с JNDI, таких как брокеры сообщений JMS, может потребоваться выполнить миграцию или перенастройку. Дополнительные сведения о конфигурации JMS см. в статье Oracle WebLogic Server 12.2.1.4.0.

Если вы используете предварительно созданное предложение Azure Marketplace, набор ресурсов JNDI, которые можно настроить во время развертывания, ограничен тем, что поддерживает предложение. Выполните поиск JNDI в документации по предложению. Если вы используете оператор напрямую, ресурсы JDNI можно определить в зависимости от выбранного типа источника домена. Для домена в PV их можно задать обычным способом с помощью WLST или консоли администрирования. Сведения о домене в образе или модели в изображении см. в стандартных переопределениях.

Инспекция конфигурации домена

Основной единицей конфигурации на сервере WebLogic Server является домен. Следовательно, файл config.xml содержит множество конфигураций, которые необходимо внимательно проверить перед миграцией. Файл содержит ссылки на дополнительные XML-файлы, которые хранятся в подкаталогах. Oracle рекомендует использовать консоль администрирования для настройки управляемых объектов и служб WebLogic Server, а также включить для сервера WebLogic Server поддержку файла config.xml. См. сведения о файлах конфигурации домена.

В приложении

Проверьте файлы WEB-INF/weblogic.xml и (или) WEB-INF/web.xml.

Предварительно созданное предложение Azure Marketplace автоматически создает ресурс домена. Если вы используете оператор напрямую, вы можете полностью настроить способ представления домена. Полные сведения см. в разделе "Ресурс домена".

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

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

  • Coherence*Web может выполняться параллельно с WebLogic Server на виртуальных машинах Azure, но такой вариант нужно настроить вручную после подготовки предложения. Coherence также может выполняться на виртуальных машинах Azure отдельно, но и этот вариант нужно настроить вручную после подготовки предложения.
  • Выполните рефакторинг приложения, чтобы использовать базу данных для управления сеансами.
  • Выполните рефакторинг приложения, чтобы перенести сеанс в службу Redis Azure. См. сведения на странице с ценами на Azure Cache for Redis.

Для всех этих вариантов рекомендуется указать, как именно WebLogic выполняет репликацию состояния сеанса HTTP. См. руководство по репликации состояния сеанса HTTP в документации Oracle.

Предварительно созданное предложение Azure Marketplace поддерживает сходство сеансов с помощью контроллера входящего трафика Шлюз приложений. При развертывании предложения выберите "Включить сходство на основе файлов cookie". Найдите сходство на основе файлов cookie в документации по предложению.

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

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

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

См. руководство по использованию драйверов JDBC с WebLogic Server.

Предварительно созданное предложение Azure Marketplace поддерживает наиболее популярные базы данных. Дополнительные сведения см. в разделе "База данных". Для домена в PV их можно задать обычным способом с помощью WLST или консоли администрирования. Сведения о домене в образе или модели в изображении см. в стандартных переопределениях.

Определение того, была ли настроена платформа WebLogic

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

  • Были ли изменены скрипты запуска? Эти скрипты включают setDomainEnv, commEnv, startWebLogic и stopWebLogic.
  • Есть ли какие-либо определенные параметры, передаваемые в виртуальную машину Java?
  • Есть ли JAR-файлы, включенные в путь к классу сервера?

Эти настройки необходимо записать в образе контейнера, выполняемом AKS. Для предварительно созданного предложения Azure Marketplace такие настройки лучше всего обрабатываются путем создания пользовательского образа контейнера и его доступности в Реестр контейнеров Azure, а затем указания на этот реестр во время развертывания. Дополнительные сведения см. в разделе "Выбор изображения". Если оператор используется напрямую, см . переменные среды JVM и среды параметров Java.

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

Если жизненный цикл приложения предполагает управление на основе REST, вам нужно определить, какие порты используются для доступа к REST API и как они проходят проверку подлинности и предоставляются. После миграции необходимо убедиться, что эти порты и механизмы проверки подлинности предоставлены, чтобы жизненный цикл приложения соответствовал тому, который был до миграции. См. руководство по администрированию сервера Oracle WebLogic Server с помощью служб управления RESTful.

Единственный тип источника домашнего домена, в котором имеет смысл продолжать использовать управление с помощью REST, — домен в PV. Его можно использовать с другими исходными типами домена, но внесенные изменения являются временными и не сохраняются во время перезапусков pod.

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

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

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

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

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

Если вы используете Oracle Message Broker, можете перенести это программное обеспечение на виртуальные машины Azure и использовать его как есть.

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

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

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

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

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

Если вы использовали пакеты OSGi, добавленные на сервер WebLogic Server, вам нужно будет добавить аналогичные JAR-файлы непосредственно в приложение.

Их можно включить в war или EAR, предоставленные в предварительно созданное предложение Azure Marketplace или напрямую с помощью оператора.

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

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

WLS в AKS работает в Oracle Linux. Любой код, зависящий от ОС, должен быть совместим с Oracle Linux. Чтобы узнать, как обнаруживать определенные сведения о ОС, выполните действия, описанные в разделе "Определение совместимости версии WebLogic".

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

Если приложение использует Oracle Service Bus (OSB), необходимо определить настройки этой службы. См. руководство по установке Oracle Service Bus.

OSB не поддерживается непосредственно в предварительно созданном предложении Azure Marketplace. Если необходимо использовать OSB, необходимо использовать оператор напрямую.

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

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

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

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

Предварительно созданное предложение Azure Marketplace поддерживает WAR и EAR. С помощью оператора также поддерживается waRs и EAR.

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

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

Определение того, используется ли WebLogic Scripting Tool (WLST)

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

Единственным типом источника домашнего домена, совместимым с использованием WLST, является домен в PV. Дополнительные сведения см. в разделе "Дом домена" на ПВ.

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

Kubernetes занимается файловыми системами с постоянными томами (PV). Подключение постоянных томов поддерживается в предварительно созданном предложении Azure Marketplace и при использовании оператора напрямую. Если вы используете домен в PV, файловая система является центральным аспектом конфигурации.

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

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

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

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

Определение топологии сети

Текущий набор предложений Azure Marketplace — это отправная точка для миграции. Если предложение охватывает не все аспекты архитектуры, которую вы хотите перенести, вам нужно воспроизвести в Azure топологию сети существующего развертывания, даже после развертывания базового предложения на основе одного из шаблонов решений.

Хотя это очень обширная тема, следующие ресурсы помогут вам спланировать миграцию:

  • Список общих статей, которые имеют отношение к переносу топологии сети в Azure: Fast Track Deployment Guide (Руководство по развертыванию Fast Track).
  • Рекомендации по кластеризации, которая влияет на топологию сети: WebLogic Server Clustering (Кластеризация WebLogic Server).
  • Так как источники данных в системе WebLogic представляют собой отдельные серверы, их необходимо учитывать при анализе топологии сети: Источники данных в WebLogic Server.
  • Источники служб сообщений также являются отдельными серверами: Обмен сообщениями в WebLogic Server.
  • Балансировка нагрузки В следующем документе описана балансировка нагрузки на стороне WebLogic Server: Load Balancing in a Cluster (Балансировка нагрузки в кластере).

Учетная запись для использования адаптеров JCA и адаптеров ресурсов

Если развертывание зависит от адаптеров ресурсов, наиболее поддерживаемым вариантом является домен дома в PV.

Учетная запись для использования настраиваемых поставщиков услуг безопасности и JAAS

Если приложение использует JAAS, убедитесь, что конфигурация поставщиков безопасности правильно перенесена. См. руководство по настройке поставщиков услуг безопасности WebLogic Security в документации по Oracle.

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

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

Оператор обрабатывает кластеризация для всех возможных способов запуска WLS в AKS.

Проверка кластеризация EJB

Если приложение использует локальный EJB, необходимо перенести их в кластеризованный EJB. Дополнительные сведения см. в разделе Clustered и local EJB.

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

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

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

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

Определение необходимости нескольких образов контейнеров

Домен WebLogic Server может содержать несколько кластеров. Например, многоуровневое приложение может быть представлено в одном домене, но имеет два кластера, например frontend и backend. Это полезно, чтобы иметь возможность обновлять интерфейс, не обновляя серверную часть, и наоборот. Однако при использовании типа источника домена "Модель в домене образа " весь домен представлен в одном образе контейнера. Для размещения этого варианта использования необходимо разделить кластеры на собственные домены, каждый из которых имеет собственный образ контейнера. Оператор может управлять несколькими доменами в нескольких пространствах имен. Дополнительные сведения см. в разделе "Выбор стратегии выбора пространства имен домена"

Внедрение нескольких доменов может привести к проблемам доступа T3 между доменами. Чтобы устранить эти проблемы, включите пользовательский канал, как описано в разделе "Определение необходимости включения доступа к неизвестному узлу".

Определение необходимости включения доступа к неизвестному узлу

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

  • Разрешить доступ T3 от внешних клиентов за пределами AKS к кластерам WLS в AKS через пользовательский канал.
  • Разрешить доступ T3 между различными доменами WLS в AKS через пользовательский канал.

Дополнительные сведения о исправлении см. в руководстве по использованию поиска исправлений в my Oracle Support(MOS) и поиске исправлений 30656708.

После применения исправления см. раздел "Включение доступа к неизвестному узлу".

Миграция

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

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

Чтобы открыть предложение в портал Azure, см. раздел https://aka.ms/wlsaks. Нажмите кнопку "Создать", а затем следуйте инструкциям в документации по предложению. Используйте сведения, собранные на предыдущих шагах, чтобы помочь в заполнении полей предложения.

Миграция доменов

После подготовки предложения выведите домен, выполнив следующие действия.

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

  1. В левом верхнем углу любой страницы портала в боковом меню выберите Группы ресурсов.

  2. В поле Фильтр для любого поля введите первые несколько символов ранее созданной группы ресурсов. Если вы следовали рекомендации по созданию имени, введите свои инициалы, а затем выберите соответствующую группу ресурсов.

  3. В области навигации слева в разделе Параметры выберите "Развертывания", чтобы просмотреть упорядоченный список развертываний в этой группе ресурсов с последним первым.

  4. Прокрутите до самой старой записи в этом списке. Эта запись соответствует развертыванию, начатому в предыдущем разделе. Выберите самое старое развертывание, как показано на следующем снимке экрана.

    Снимок экрана: портал Azure с списком развертываний группы ресурсов.

  5. На левой панели выберите "Выходные данные". В этом списке показаны выходные значения из развертывания. Полезные сведения включаются в выходные данные. Мы заинтересованы в выходных данных, которые позволяют нам проверять домен и взаимодействовать с оператором. Другие значения в выходных данных подробно описаны в руководстве пользователя WebLogic для AKS.

  6. Найдите выходные данные с именем shellCmdtoConnectAks. Вставьте значение выходных данных в оболочку Bash и выполните команду. Эта команда позволяет использоватьkubectl, как описано в Подключение кластера.

  7. Найдите выходные данные с именем shellCmdtoOutputWlsDomainYaml. Вставьте значение выходных данных в оболочку Bash и выполните команду. Эта команда выводит ресурс домена в виде файла YAML.

  8. Теперь, когда у вас есть домен YAML текущего развертывания, вы можете применить знания в развертывании файлов YAML ресурсов домена и ознакомиться с этим руководством для получения дополнительных сведений о том, как перенести домены. Это руководство требует адаптации к способу выполнения действий Kubernetes, но это все еще полезно знать о.

Учет хранилищ ключей

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

Подключение источников JMS

Подключившись к базам данных, вы можете настроить JMS согласно руководству по администрированию ресурсов JMS для сервера Oracle WebLogic Server с помощью Fusion Middleware.

Учетная запись для ведения журнала

Не удается сделать облако без ведения журнала. Оператор предоставляет примеры для использования Elasticsearch и Kibana. Дополнительные сведения см . в документации по оператору. Azure обеспечивает большую поддержку Elastic. Полные сведения см. в статье "Что такое интеграция Elastic с Azure?". Вы можете объединить знания в этих двух ресурсах, чтобы обеспечить решение для ведения журналов, оптимизированное для Azure для WLS в AKS.

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

Независимо от того, хотите ли вы предоставить WAR или EAR-файл во время развертывания, необходимо обновить приложение с помощью CI/CD. В документации по оператору приведен пример, в который показано, как выполнить это обновление. Дополнительные сведения см. в обновлении 3. Другие примеры обновлений относятся к миграции и стоит изучить.

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

При тестировании приложений в контейнере должны быть доступными новые серверы, работающие в Azure. Как и для CI/CD, здесь важно настроить правила безопасности сети, открывающие доступ к приложениям, развернутым в Azure, для тестирования. Дополнительные сведения см. в разделе Группы безопасности сети.

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

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