Перенос приложений Tomcat в Tomcat в Службе приложений Azure

  • Статья

Узнайте, что следует учитывать при переносе существующего приложения Tomcat для запуска в Службе приложений Azure с использованием Tomcat 9.0.

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

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

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

Переход на поддерживаемую платформу

В Службе приложений доступны некоторые версии Tomcat на основе определенных версий Java. Чтобы обеспечить совместимость, перенесите приложение в одну из поддерживаемых версий Tomcat и Java в текущей среде, прежде чем переходить к остальным действиям. Обязательно полностью протестируйте готовую конфигурацию. Используйте в этих тестах последний стабильный выпуск дистрибутива Linux.

Примечание.

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

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

java -version

В службе приложение Azure двоичные файлы для Java 8 предоставляются из Eclipse Temurin. Для Java 11, 17 и всех будущих выпусков Java Служба приложений предоставляет Microsoft Build of OpenJDK. Эти двоичные файлы доступны для бесплатного скачивания на следующих сайтах:

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

${CATALINA_HOME}/bin/version.sh

Чтобы получить текущую версию, поддерживаемую в Службе приложений Azure, скачайте Tomcat 9 в зависимости от того, какую версию вы планируете использовать в Службе приложений Azure.

Проверка внешних ресурсов

Внешние ресурсы, такие как источники данных, брокеры сообщений JMS и другие, внедряются с помощью API JNDI (Java Naming and Directory Interface). Возможно, для некоторых из этих ресурсов потребуется выполнить перенос или перенастройку.

В приложении

Проверьте файл META-INF/context.xml. Найдите элементы <Resource> в элементе <Context>.

На серверах приложений

Проверьте файлы $CATALINA_BASE/conf/context.xml и $CATALINA_BASE/conf/server.xml, а также файлы с расширением .xml в каталогах $CATALINA_BASE/conf/[имя_модуля]/[имя_узла].

В файлах context.xml для описания ресурсов JNDI будут использоваться элементы <Resource> в элементе <Context> верхнего уровня.

В файлах server.xml для описания ресурсов JNDI будут использоваться элементы <Resource> в элементе <GlobalNamingResources>.

Источники данных

Источники данных — это ресурсы JNDI с атрибутом type, для которого задано значение javax.sql.DataSource. Для каждого источника данных запишите следующие сведения:

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

Дополнительные сведения см. в руководстве по использованию источника данных JNDI в документации по Tomcat.

Другие связанные внешние ресурсы

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

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

Пароли и защищенные строки

Проверьте все свойства и файлы конфигурации на рабочих серверах на наличие секретных строк и паролей. Обязательно проверьте файлы server.xml и context.xml в каталоге $CATALINA_BASE/conf. Кроме того, в приложении есть файлы конфигурации, содержащие пароли или учетные данные. К ним может относиться файл META-INF/context.xml, а для приложений Spring Boot — файлы application.properties и application.yml.

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

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

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

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

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

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

Если ваше приложение сейчас обслуживает статическое содержимое, вам потребуется альтернативное расположение для этого статического содержимого. Вы можете переместить статическое содержимое в хранилище 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 к файловой системе Службы приложений. См. сведения в руководстве по обработке содержимого из службы хранилища Azure в Службе приложений в Linux.

Определение механизма сохранения сеанса

Чтобы узнать, какой используется диспетчер сохраняемости сеансов, изучите файлы context.xml в приложении и конфигурации Tomcat. Найдите элемент <Manager> и запишите значение атрибута className.

Встроенные реализации PersistentManager, например StandardManager или FileStore, не предназначены для использования с распределенной, масштабируемой платформой, такой как Служба приложений. Так как Служба приложений может распределять нагрузку между несколькими экземплярами и прозрачно перезапускать любой экземпляр в любое время, не рекомендуется сохранять изменяющееся состояние в файловой системе.

Если требуется сохранение сеанса, необходимо использовать альтернативную реализацию PersistentManager, которая будет выполнять запись во внешнее хранилище данных, например VMware Tanzu Session Manager с Redis Cache. См. сведения о том, как использовать Redis в качестве кэша сеансов с Tomcat.

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

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

Особые случаи

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

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

Запланированные задания, такие как задачи планировщика Quartz или задания Cron, нельзя использовать со Службой приложений. Служба приложений не будет препятствовать развертыванию приложения, содержащего запланированные внутренние задачи. Но если приложение масштабируется, одно запланированное задание может выполняться несколько раз в течение указанного периода. Это может привести к нежелательным последствиям.

Проверьте все запланированные задания на сервере приложений или за его пределами.

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

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

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

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

Чтобы определить, использует ли приложение кластеризацию, найдите элемент <Cluster> в элементах <Host> или <Engine> в файле server.xml.

Определение того, используются ли соединители, отличающиеся от HTTP

Служба приложений позволяет использовать только один соединитель HTTP. Если для работы приложения требуются дополнительные соединители, например соединитель AJP, не используйте Службу приложений.

Чтобы определить соединители HTTP, используемые приложением, найдите элементы <Connector> в файле server.xml в конфигурации Tomcat.

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

Для работы MemoryRealm требуется сохраненный XML-файл. В Службе приложений Azure передайте этот файл в каталог /home, его подкаталог или в подключенное хранилище. Затем измените параметр pathName соответствующим образом.

Чтобы определить, используется ли сейчас MemoryRealm, изучите файлы server.xml и context.xml и найдите элементы <Realm>, в которых для атрибута className задано значение org.apache.catalina.realm.MemoryRealm.

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

Служба приложений выполянет загрузку сеансов за пределами среды выполнения Tomcat, поэтому вы не можете использовать отслеживание сеансов SSL. Используйте другой режим отслеживания сеансов (COOKIE или URL). Если требуется применить отслеживание сеансов SSL, не используйте Службу приложений.

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

Если используется AccessLogValve, укажите для параметра directory значение /home/LogFiles или любой подкаталог этой папки.

Миграция

Параметризация конфигурации

На этапе предварительной миграции вы наверняка нашли некоторые секреты и внешние зависимости, например источники данных, в файлах server.xml и context.xml. Для каждого определенного элемента измените имя пользователя, пароль, строку подключения или URL-адрес на переменную среды.

Например, предположим, что файл context.xml содержит следующий элемент:

<Resource
    name="jdbc/dbconnection"
    type="javax.sql.DataSource"
    url="jdbc:postgresql://postgresdb.contoso.com/wickedsecret?ssl=true"
    driverClassName="org.postgresql.Driver"
    username="postgres"
    password="t00secure2gue$$"
/>

В этом случае его можно изменить, как показано в следующем примере.

<Resource
    name="jdbc/dbconnection"
    type="javax.sql.DataSource"
    url="${postgresdb.connectionString}"
    driverClassName="org.postgresql.Driver"
    username="${postgresdb.username}"
    password="${postgresdb.password}"
/>

Чтобы обеспечить подстановку параметров для любого файла context.xml в папке META-INF внутри развернутого WAR-файла , обязательно задайте CATALINA_OPTS переменную среды, как показано в следующем примере:

export CATALINA_OPTS="-Dorg.apache.tomcat.util.digester.PROPERTY_SOURCE=org.apache.tomcat.util.digester.EnvironmentPropertySource"

Подготовка плана службы приложений

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

Примечание.

Если вы намерены использовать промежуточное или раннее развертывание либо слоты развертывания, план службы приложений должен учитывать эту дополнительную емкость. Для приложений Java рекомендуется использовать план уровня "Премиум" или выше. См. сведения о том, как настраивать промежуточные среды в Службе приложений Azure.

Затем создайте план службы приложений. См. сведения о том, как управлять планом службы приложений в Azure.

Создание и развертывание веб-приложений

Для каждого WAR-файла, развернутого на сервере Tomcat, необходимо создать веб-приложение в плане службы приложений, выбрав версию Tomcat в качестве стека времени выполнения.

Примечание.

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

Приложения Maven

Если приложение создано на основе POM-файла Maven, используйте подключаемый модуль веб-приложения для Maven, чтобы создать и развернуть веб-приложение.

Приложения, отличающиеся от Maven

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

Создав веб-приложение, разверните его, используя один из доступных механизмов развертывания.

Перенос параметров среды выполнения JVM

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

Указание секретов

Чтобы сохранить все секреты, относящиеся к вашему приложению, используйте параметры приложения. Либо используйте Azure Key Vault, если вы планируете применять одни и те же секреты в нескольких приложениях или реализовать политики для точного управления доступом и возможности аудита.

Настройка личного домена и SSL

Если приложение будет отображаться в личном домене, вам нужно будет сопоставить с ним веб-приложение. Дополнительные сведения см. в статье Сопоставление существующего настраиваемого DNS-имени со Службой приложений Azure.

После этого вам нужно будет привязать SSL-сертификат для этого домена к веб-приложению в Службе приложений. См. руководство по защите пользовательского DNS-имени с помощью привязки SSL в Службе приложений Azure.

Импорт сертификатов внутренних серверов

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

Перенос источников данных, библиотек и ресурсов JNDI

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

Дополнительные инструкции по источникам данных JNDI см. в следующих разделах этого руководства в документации по Tomcat:

Перенесите все дополнительные зависимости classpath уровня сервера, выполнив те же действия, что и для JAR-файлов источников данных.

Перенесите все дополнительные общие ресурсы JDNI уровня сервера.

Примечание.

Если вы используете рекомендуемую архитектуру "один WAR-файл на одно веб-приложение", перенесите библиотеки classpath и ресурсы JNDI на уровне сервера в приложение. Это значительно упростит управление компонентами и изменениями.

Перенос оставшейся конфигурации

Когда вы выполните инструкции из предыдущего раздела, настраиваемая конфигурация сервера должна будет находится в папке /home/tomcat/conf.

Завершите миграцию, скопировав все дополнительные конфигурации (например, realms и JASPIC).

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

Для выполнения запланированных заданий в Azure рекомендуется использовать триггер таймера для Функций Azure. Переносить сам код задания в функцию не нужно. Функция может просто вызвать URL-адрес в приложении, чтобы активировать задание. Если такие выполнения заданий должны быть динамически вызываемыми и (или) централизованно отслеживаемыми, попробуйте использовать Spring Batch.

Либо создайте приложение логики с триггером повторения для вызова URL-адреса без необходимости писать код за пределами приложения. См. сведения об Azure Logic Apps, а также руководство по созданию, планированию и выполнению повторяющихся задач и рабочих процессов с помощью триггера повторения в Azure Logic Apps.

Примечание.

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

Перезапуск и тест состояния

Наконец, перезапустите веб-приложение, чтобы применить все изменения конфигурации. После завершения перезагрузки убедитесь, что приложение работает правильно.

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

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

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