Перенос приложений Tomcat в приложения контейнеров Azure

Статья
05/30/2023

В этом руководстве описывается, что следует учитывать при переносе существующего приложения Tomcat для запуска в приложениях контейнеров Azure (ACA).

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

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

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

Внешние ресурсы, такие как источники данных, брокеры сообщений 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Для работы MemoryRealm требуется сохраненный XML-файл. В ACA необходимо добавить этот файл в образ контейнера или отправить его в общее хранилище, которое становится доступным для контейнеров. (Дополнительные сведения см. в разделе Определение раздела механизма сохраняемости сеанса.) Параметр pathName должен быть изменен соответствующим образом.

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

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

Перед созданием образов контейнеров перенесите приложение в JDK и Tomcat, которые планируется использовать в ACA. Тщательно протестируйте приложение, чтобы обеспечить совместимость и высокую производительность.

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

В ходе предварительной миграции будут определены секреты и внешние зависимости, такие как источники данных, в файлах 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}"
/>

Миграция

Примечание.

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

Подготовка артефактов развертывания

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

Добавление ресурсов JNDI

Измените server.xml , чтобы добавить ресурсы, подготовленные на этапах предварительной миграции, например источники данных, как показано в следующем примере:

<!-- Global JNDI resources
      Documentation at /docs/jndi-resources-howto.html
-->
<GlobalNamingResources>
    <!-- Editable user database that can also be used by
         UserDatabaseRealm to authenticate users
    -->
    <Resource name="UserDatabase" auth="Container"
              type="org.apache.catalina.UserDatabase"
              description="User database that can be updated and saved"
              factory="org.apache.catalina.users.MemoryUserDatabaseFactory"
              pathname="conf/tomcat-users.xml"
               />

    <!-- Migrated datasources here: -->
    <Resource
        name="jdbc/dbconnection"
        type="javax.sql.DataSource"
        url="${postgresdb.connectionString}"
        driverClassName="org.postgresql.Driver"
        username="${postgresdb.username}"
        password="${postgresdb.password}"
    />
    <!-- End of migrated datasources -->
</GlobalNamingResources>

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

Сборка и отправка образа

Самый простой способ создания и отправки образа в Реестр контейнеров Azure (ACR) для использования ACA — использовать az acr build команду. Для выполнения этой команды устанавливать Docker на компьютере не нужно. Например, если у вас есть Dockerfile из репозитория tomcat-container-quickstart и пакета пакета приложения petclinic.war в текущем каталоге, можно создать образ контейнера в ACR с помощью следующей команды:

az acr build \
    --registry $acrName \
    --image "${acrName}.azurecr.io/petclinic:{{.Run.ID}}" 
    --build-arg APP_FILE=petclinic.war \
    --build-arg SERVER_XML=prod.server.xml .

Можно опустить параметр --build-arg APP_FILE..., если WAR-файл называется ROOT.war. Можно опустить параметр --build-arg SERVER_XML..., если XML-файл сервера называется server.xml. Оба файла должны находиться в том же каталоге, что и Dockerfile.

Кроме того, можно использовать ИНТЕРФЕЙС командной строки Docker для локальной сборки образа с помощью следующих команд. Такой подход упрощает тестирование и дополнительную настройку образа перед первым развертыванием в ACR. Но для этого нужно установить Docker CLI и запустить управляющую программу Docker.

# Build the image locally.
sudo docker build . --build-arg APP_FILE=petclinic.war -t "${acrName}.azurecr.io/petclinic:1"

# Run the image locally.
sudo docker run -d -p 8080:8080 "${acrName}.azurecr.io/petclinic:1"

# You can now access your application with a browser at http://localhost:8080.

# Sign in to ACR.
sudo az acr login --name $acrName

# Push the image to ACR.
sudo docker push "${acrName}.azurecr.io/petclinic:1"

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

Развертывание на платформе "Контейнеры приложений Azure"

В следующей команде представлен пример развертывания:

az containerapp create \
    --resource-group <RESOURCE_GROUP> \
    --name <APP_NAME> \
    --environment <ENVIRONMENT_NAME> \
    --image <IMAGE_NAME> \
    --target-port 8080 \
    --ingress 'external' \
    --registry-server <REGISTRY_SERVER> \
    --min-replicas 1

Более подробное краткое руководство см . в кратком руководстве по развертыванию первого приложения контейнера.

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

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

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