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


Перенос приложений Spring Boot в Azure App Service

В этом руководстве описывается, что следует учитывать при переносе существующего приложения Spring Boot в Azure App Service.

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

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

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

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

Замечание

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

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

java -version

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

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

Определите внешние ресурсы, в том числе источники данных, брокеры сообщений JMS и URL-адреса других служб. В приложениях Spring Boot обычно можно найти конфигурацию для таких ресурсов в папке src/main/directory в файле, обычно называемом application.properties или application.yml. Кроме того, проверьте переменные среды рабочего развертывания для любых соответствующих параметров конфигурации.

Базы данных

Для приложения Spring Boot строки подключения обычно отображаются в файлах конфигурации при зависимости от внешней базы данных. Ниже приведен пример из файла application.properties :

spring.datasource.url=jdbc:mysql://localhost:3306/mysql_db
spring.datasource.username=dbuser
spring.datasource.driver-class-name=com.mysql.jdbc.Driver

Ниже приведен пример из файла application.yaml :

spring:
  data:
    mongodb:
      uri: mongodb://mongouser:deepsecret@mongoserver.contoso.com:27017

Дополнительные сценарии настройки см. в документации по Spring Data.

Брокеры сообщений JMS

Определите брокеров, используемых в файле манифеста сборки (как правило, в файле pom.xml или build.gradle), для поиска соответствующих зависимостей.

Например, приложение Spring Boot с помощью ActiveMQ обычно будет содержать эту зависимость в файле pom.xml :

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-activemq</artifactId>
</dependency>

Приложения Spring Boot, использующие коммерческие брокеры, обычно содержат зависимости непосредственно от библиотек драйверов JMS брокеров. Ниже приведен пример из файла build.gradle :

    dependencies {
      ...
      compile("com.ibm.mq:com.ibm.mq.allclient:9.4.0.5")
      ...
    }

Когда вы выявите используемого брокера или брокеров, найдите соответствующие параметры. В приложениях Spring Boot их обычно можно найти в файлах application.properties и application.yml в каталоге приложений.

Замечание

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

Ниже приведен пример ActiveMQ из файла application.properties :

spring.activemq.brokerurl=broker:(tcp://localhost:61616,network:static:tcp://remotehost:61616)?persistent=false&useJmx=true
spring.activemq.user=admin
spring.activemq.password=<password>

Дополнительные сведения о конфигурации ActiveMQ см. в документации по обмену сообщениями Spring Boot.

Ниже приведен пример IBM MQ из файла application.yaml :

ibm:
  mq:
    queueManager: qm1
    channel: dev.ORDERS
    connName: localhost(14)
    user: admin
    password: <password>

Дополнительные сведения о конфигурации IBM MQ см. в документации по компонентам IBM MQ Spring.

Определение внешних кэшей

Определите все используемые внешние кэши. Redis часто используется через Spring Data Redis. См. документацию 'Spring Data Redis' для получения информации о конфигурации.

Определите, кэшируются ли данные сеанса с помощью Spring Session, и выполните поиск соответствующей конфигурации (в Java или XML).

Поставщики идентификационных услуг

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

Все прочие внешние ресурсы

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

Инвентаризация секретов

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

Проверьте наличие секретных строк и паролей во всех свойствах и файлах конфигурации, а также всех переменных среды в рабочих развертываниях. В приложении Spring Boot такие строки, скорее всего, будут найдены в application.properties или application.yml.

Сертификаты складского учета

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

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

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

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

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

Если приложение в настоящее время обслуживает статическое содержимое, для него требуется альтернативное расположение. Следует рассмотреть возможность перемещения статического содержимого в Azure Blob Storage и добавления Azure Front Door для быстрого скачивания глобально. Дополнительные сведения см. в разделе Статическое размещение веб-сайтов в Azure Storage и Интеграция учетной записи Azure Storage с Azure Front Door.

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

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

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

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

Инвентаризация запланированных заданий внутри или вне процесса приложения.

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

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

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

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

Определение обработки запросов, отличных от HTTP- или нескольких портов

Служба приложений поддерживает только одну конечную точку HTTP на одном порту. Если приложение прослушивает несколько портов или принимает запросы с помощью протоколов, отличных от ПРОТОКОЛА HTTP, не используйте Azure App Service.

Миграция

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

Убедитесь, что все координаты внешних ресурсов (например, строки подключения к базе данных) и другие настраиваемые параметры можно считывать из переменных среды. Если вы переносите приложение Spring Boot, все параметры конфигурации уже должны быть внешними. Дополнительные сведения см. в разделе внешней конфигурации документации Spring Boot.

Ниже приведен пример, который ссылается на SERVICEBUS_CONNECTION_STRING переменную среды из файла application.properties :

spring.jms.servicebus.connection-string=${SERVICEBUS_CONNECTION_STRING}
spring.jms.servicebus.topic-client-id=contoso1
spring.jms.servicebus.idle-timeout=10000

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

В списке доступных планов обслуживания выберите план, спецификации которого соответствуют или превышают характеристики текущего производственного оборудования.

Замечание

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

Создайте план службы приложений.

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

Вам потребуется создать веб-приложение в плане службы приложений (выбрав "Java SE" в качестве стека среды выполнения) для каждого исполняемого JAR-файла, который вы планируете запустить.

Приложения Maven

Если ваше приложение построено на основе POM-файла Maven, используйте плагин для Webapp в Maven, чтобы создать веб-приложение и развернуть его. Дополнительные сведения см. в разделе Quickstart: создание приложения Java на Azure App Service.

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

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

После создания веб-приложения используйте один из доступных механизмов развертывания для развертывания приложения. Если возможно, ваше приложение должно быть загружено в /home/site/wwwroot/app.jar. Если вы не хотите переименовать JAR-файл в app.jar, можно отправить скрипт оболочки с помощью команды для запуска JAR-файла. Затем вставьте полный путь к этому скрипту в текстовое поле "Файл запуска " в разделе "Конфигурация" портала. Скрипт запуска выполняется не в том каталоге, в который он помещен. Поэтому всегда используйте абсолютные пути для ссылки на файлы в скрипте запуска (например: java -jar /home/myapp/myapp.jar).

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

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

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

Если ваше приложение будет отображаться на пользовательском домене, вам нужно будет сопоставить с ним ваше веб-приложение. Вы можете найти более подробную информацию в документе Руководство: как сопоставить существительное пользовательское DNS-имя с Azure App Service.

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

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

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

Перенос координат внешних ресурсов и других параметров

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

Замечание

Для всех параметров приложения Spring Boot, параметризованных переменными в разделе "Параметризация конфигурации ", эти переменные среды должны быть определены в конфигурации приложения. Все параметры приложения Spring Boot, не заданные явно через переменные среды, все равно могут быть переопределены с помощью конфигурации приложения. Рассмотрим пример.

spring.jms.servicebus.connection-string=${CUSTOMCONNSTR_SERVICE_BUS}
spring.jms.servicebus.topic-client-id=contoso1
spring.jms.servicebus.idle-timeout=1800000

Конфигурация приложения службы приложений

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

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

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

Замечание

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

Мигрировать и включить поставщика удостоверений

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

  • Если поставщик удостоверений Microsoft Entra ID, изменения не должны быть необходимы.
  • Если поставщик удостоверений — это локальный лес Active Directory, рассмотрите возможность реализации гибридного решения удостоверения с Microsoft Entra ID. Дополнительные сведения см. в документации по гибридной идентификации.
  • Если поставщик удостоверений является другим локальным решением, например PingFederate, обратитесь к разделу Пользовательская установка Microsoft Entra Connect, чтобы настроить федерацию с Microsoft Entra ID. Рассмотрите возможность использования Spring Security для подключения поставщика удостоверений через OAuth2/OpenID Connect или SAML.

Перезапуск и смоук-тест

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

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

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

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