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

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

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

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

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

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

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

Замечание

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

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

java -version

В службе приложение Azure двоичные файлы для Java 8 предоставляются из Eclipse Temurin. Для Java 11, 17 и всех будущих выпусков 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.yml:

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 см. в документации по компонентам Spring для IBM MQ.

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

Определите все используемые внешние кэши. 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>

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Миграция

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

Убедитесь, что все координаты внешних ресурсов (например, строки подключения к базе данных) и другие настраиваемые параметры можно считывать из переменных среды. Если вы переносите приложение 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, чтобы создать веб-приложение и развернуть его. Для получения дополнительной информации см. в разделе «Быстрый старт: Создание приложения Java в службе приложений Azure».

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

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

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

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

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

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

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

После этого вам нужно будет привязать 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 рекомендуется использовать триггер таймера для Функций Azure. Переносить сам код задания в функцию не нужно. Функция может просто вызвать URL-адрес в приложении, чтобы активировать задание. Если такие выполнения заданий должны быть динамически вызываемыми и (или) централизованно отслеживаемыми, попробуйте использовать Spring Batch.

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

Замечание

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

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

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

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

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

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

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

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

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