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

Статья
10/01/2024

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

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

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

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

Перенос приложений на базе исполняемых JAR-файлов в контейнеры в Службе Azure Kubernetes (руководство ожидается)
Перенос приложений на базе исполняемых JAR-файлов в Виртуальные машины Azure (руководство ожидается)

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

Определение локального состояния

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

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

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

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

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

Кэш Azure для Redis
Azure Cosmos DB
Другая внешняя база данных, например SQL Azure, База данных Azure для MySQL или База данных Azure для PostgreSQL.
служба хранилища Azure, используемый для хранения неструктурированных данных или даже сериализованных объектов.

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

Найдите все экземпляры, из которых выполняется чтение и (или) запись в локальной файловой системе. Найдите все фрагменты, из которых записываются и считываются временные файлы, файлы с коротким и длительным сроком хранения.

Приложения контейнеров Azure предлагают несколько типов хранилища. Эфемерное хранилище может считывать и записывать временные данные и быть доступными для запущенного контейнера или реплики. Файл Azure предоставляет постоянное хранилище и может использоваться для нескольких контейнеров. Дополнительные сведения см. в статье "Использование подключений к хранилищу в приложениях контейнеров Azure".

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

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

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

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

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

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

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

Если вы создаете Dockerfile вручную и развертываете контейнерное приложение в приложениях контейнеров Azure, вы полностью управляете развертыванием, включая версии JRE/JDK.

Для развертывания из артефактов приложения контейнеров Azure также предлагает определенные версии Java (8, 11, 17 и 21) и определенные версии компонентов Spring Boot и Spring Cloud. Чтобы обеспечить совместимость, сначала перенесите приложение в одну из поддерживаемых версий Java в текущей среде, прежде чем переходить к другим задачам по переносу. Обязательно полностью протестируйте готовую конфигурацию. Используйте в этих тестах последний стабильный выпуск дистрибутива Linux.

Примечание.

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

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

java -version

Поддерживаемые версии Java, Spring Boot и Spring Cloud, а также инструкции по обновлению см. в обзоре Java в приложениях контейнеров Azure.

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

Эфемерное приложение, например задания unix cron или краткосрочные приложения на основе платформы Spring Batch, должно выполняться в качестве задания в приложениях контейнеров Azure. Дополнительные сведения см. в разделе "Задания" в приложениях контейнеров Azure. Если приложение является длительным приложением и регулярно выполняет задачи с помощью платформы планирования, такой как Android или Spring Batch, приложения контейнеров Azure могут размещать это приложение. Однако приложение должно обрабатывать масштабирование соответствующим образом, чтобы избежать условий гонки, когда одни и те же экземпляры приложений выполняются более одного раза в запланированный период во время горизонтального масштабирования или последовательного обновления.

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

Определение версий Spring Boot

Изучите зависимости каждого переносимого приложения, чтобы определить его версию Spring Boot.

Maven

В проектах Maven версию Spring Boot обычно можно узнать в элементе <parent> файл POM:

    <parent>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-parent</artifactId>
        <version>3.3.3</version>
        <relativePath/> <!-- lookup parent from repository -->
    </parent>

Gradle

В проектах Gradle версию Spring Boot обычно можно узнать в элементе в разделе plugins. Она указана в качестве версии подключаемого модуля org.springframework.boot.

plugins {
  id 'org.springframework.boot' version '3.3.3'
  id 'io.spring.dependency-management' version '1.1.6'
  id 'java'
}

Для любых приложений, использующих версии Spring Boot до 3.x, следуйте руководству по миграции Spring Boot 2.0 или руководству по миграции Spring Boot 3.0, чтобы обновить их до поддерживаемой версии Spring Boot. Поддерживаемые версии см. в версиях Spring Boot и Spring Cloud.

Определение решений по объединению журналов

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

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

Определите все агенты управления производительностью приложений, используемые приложениями. Приложения контейнеров Azure не поддерживают встроенную поддержку интеграции APM. Необходимо подготовить образ контейнера или интегрировать средство APM непосредственно в код. Если вы хотите измерить производительность приложения, но еще не интегрировать APM, рассмотрите возможность использования приложение Azure Insights. Дополнительные сведения см. в разделе "Миграция ".

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

Определите внешние ресурсы, в том числе источники данных, брокеры сообщений JMS и URL-адреса других служб. В приложениях Spring Boot обычно можно найти конфигурацию таких ресурсов в папке src/main/resources в файле, обычно называемом 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=tryandguess

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

Вот пример IBM MQ из файла application.yaml:

ibm:
  mq:
    queueManager: qm1
    channel: dev.ORDERS
    connName: localhost(14)
    user: admin
    password: big$ecr3t

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

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

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

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

Поставщики удостоверений

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

Конфигурация OAuth2 описана в справочных материалах по безопасности в Spring.
Сведения о настройке Auth0 в Spring Security см. в документации по Auth0 для Spring Security.
Сведения о настройке PingFederate в Spring Security см. в инструкциях по PingFederate для Auth0.

Поиск клиентов, которые используют нестандартный порт

Приложения контейнеров Azure позволяют предоставлять порт в соответствии с конфигурацией ресурсов azure Container Apps. Например, приложение Spring Boot прослушивает порт 8080 по умолчанию, но его можно задать с server.port переменной SERVER_PORT среды или переменной среды по мере необходимости.

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

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

Источники и секреты конфигурации инвентаризации

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

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

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

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

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

Инспекция архитектуры развертывания

Документирование требований к оборудованию для каждой службы

Задокументируйте следующие сведения о приложении Spring Boot:

Количество выполняемых экземпляров.
Количество ЦП, выделенных для каждого экземпляра.
Объем RAM, выделенный для каждого экземпляра.

Документирование георепликации и распространения

Определите, распределены ли экземпляры приложения Spring Boot между несколькими регионами или центрами обработки данных. Задокументируйте требования к бесперебойной работе или соглашение об уровне обслуживания для приложений, которые вы переносите.

Миграция

Создание среды приложений контейнеров Azure и развертывание приложений

Подготовка экземпляра приложений контейнеров Azure в подписке Azure. Его безопасная среда размещения создается вместе с ней. Дополнительные сведения см. в статье Краткое руководство. Развертывание первого приложения-контейнера с помощью портала Azure.

Настройка записи журналов в консоль и параметров диагностики

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

После развертывания приложения в приложениях контейнеров Azure можно настроить параметры ведения журнала в среде "Приложения контейнеров" для определения одного или нескольких назначений журналов. Эти назначения могут включать Azure Monitor Log Analytics, Концентратор событий Azure или даже другие сторонние решения для мониторинга. Кроме того, вы можете отключить данные журнала и просматривать журналы только во время выполнения. Подробные инструкции по настройке см. в параметрах хранилища журналов и мониторинга в приложениях контейнеров Azure.

Настройка постоянного хранилища

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

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

Приложения контейнеров Azure поддерживают безопасный обмен данными между приложениями. Приложению не нужно управлять процессом установления безопасного взаимодействия. Вы можете отправить частный сертификат в приложения контейнеров Azure или использовать бесплатный управляемый сертификат, предоставляемый приложениями контейнеров Azure. Использование Azure Key Vault для управления сертификатами рекомендуется. Дополнительные сведения см. в разделе "Сертификаты" в приложениях контейнеров Azure.

Настройка интеграции управления производительностью приложений (APM)

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

Если приложение не использует поддерживаемый APM, приложение Azure Insights является одним из вариантов. Дополнительные сведения см. в статье Об использовании Azure Monitor Application Insights с Spring Boot.

Развертывание приложения

Разверните каждую перенесенную микрослужбу (не включая Сервер конфигурации Spring Cloud и реестр службы Spring Cloud), как описано в разделе "Развертывание приложений контейнеров Azure с помощью команды az containerapp up".

Настройка секретов и внешних параметров для каждой службы

Параметры конфигурации можно внедрить в каждое приложение в виде переменных среды. Эти переменные можно задать как записи вручную или как ссылки на секреты. Дополнительные сведения о конфигурации см. в статье "Управление переменными среды" в приложениях контейнеров Azure.

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

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

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

Предоставление доступа к приложению

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

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

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

Оцените возможность настроить работу приложения с реестром Spring Cloud. Этот компонент позволяет приложению динамически обнаруживать другие развернутые приложения Spring и клиенты. Дополнительные сведения см. в разделе "Настройка параметров для компонента Eureka Server для Spring" в приложениях контейнеров Azure. Затем измените все клиенты приложений, чтобы использовать Подсистему балансировки нагрузки Spring Client. Load Balancer Spring Client позволяет клиенту получать адреса всех запущенных экземпляров приложения и находить экземпляр, который работает, если другой экземпляр становится поврежден или не отвечает. Дополнительные сведения см. в разделе Spring Tips: Spring Cloud Load Balancer в блоге Spring.
Вместо того, чтобы делать приложение общедоступным, попробуйте добавить экземпляр шлюза Spring Cloud. Spring Cloud Gateway предоставляет одну конечную точку для всех приложений, развернутых в среде приложений контейнеров Azure. Если шлюз Spring Cloud уже развернут, убедитесь, что правило маршрутизации настроено для маршрутизации трафика в только что развернутое приложение.
Попробуйте добавить сервер конфигурации Spring Cloud для централизованного управления конфигурацией и управления версиями для всех приложений Spring Cloud. Сначала создайте репозиторий Git для размещения конфигурации и настройки экземпляра приложения для его использования. Дополнительные сведения см. в разделе "Настройка параметров" для компонента Config Server for Spring в приложениях контейнеров Azure. Затем перенесите конфигурацию, выполнив следующие действия:
1. В каталоге src/main/resources приложения создайте файл bootstrap.yml со следующим содержимым:
```
  spring:
    application:
      name: <your-application-name>
```
2. В репозитории конфигурации Git создайте <файл с именем> приложения.yml , где your-application-name это так же, как на предыдущем шаге. Переместите параметры из файла application.yml в src/main/resources в созданный файл. Если ранее параметры размещались в файле .properties, сначала преобразуйте их в формат YAML. Можно найти веб-инструменты или подключаемые модули IntelliJ, которые помогут выполнить это преобразование.
3. Создайте файл application.yml в указанном выше каталоге. Этот файл можно использовать для определения параметров и ресурсов, общих для всех приложений в среде приложений контейнеров Azure. К таким параметрам обычно относятся источники данных, параметры ведения журнала, конфигурация Spring Boot Actuator и др.
4. Зафиксируйте эти изменения и отправьте их в репозиторий Git.
5. Удалите из приложения файл application.properties или application.yml.
Попробуйте добавить управляемый компонент admin for Spring, чтобы включить административный интерфейс для веб-приложений Spring Boot, предоставляющих конечные точки актатора. Дополнительные сведения см. в разделе "Настройка компонента администратора Spring Boot" в приложениях контейнеров Azure.
Обдумайте возможность добавить конвейер развертывания для автоматизации и обеспечения согласованности этого процесса. Инструкции доступны для Azure Pipelines и для GitHub Actions.
Рассмотрите возможность использования версий контейнерных приложений, меток редакции и весов трафика входящего трафика, чтобы включить сине-зеленое развертывание, что позволяет протестировать изменения кода в рабочей среде, прежде чем они будут доступны некоторым или всем пользователям. Дополнительные сведения см. в статье "Развертывание Blue-Green" в приложениях контейнеров Azure.
Обдумайте возможность добавить привязки служб для подключения приложения к поддерживаемым базам данных Azure. Такие привязки служб избавляют от необходимости предоставлять сведения о подключении, включая учетные данные, для приложений Spring Cloud.
Рекомендуется включить стек разработки Java для сбора основных метрик JVM для приложений. Дополнительные сведения см. в разделе метрики Java для приложений Java в приложениях контейнеров Azure.
Рассмотрите возможность добавить правила генерации оповещений и группы действий Azure Monitor для быстрого обнаружения и устранения отклонений от обязательных условий. Дополнительные сведения см. в статье "Настройка оповещений" в приложениях контейнеров Azure.
Рассмотрите возможность репликации приложения в зонах в регионе, включив избыточность зоны контейнеров Azure. Трафик распределяется по нагрузке и автоматически направляется на реплики, если происходит сбой зоны. Дополнительные сведения о избыточных параметрах см. в статье "Надежность" в приложениях контейнеров Azure.
Рассмотрите возможность защиты приложений контейнеров Azure от распространенных эксплойтов и уязвимостей с помощью Брандмауэр веб-приложений на Шлюз приложений. Дополнительные сведения см. в статье "Защита приложений контейнеров Azure с помощью Брандмауэр веб-приложений на Шлюз приложений".

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