Перенос приложений Spring Boot в Azure Container Apps

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

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

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

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

• Перенос исполняемых JAR-приложений в контейнеры на Azure Kubernetes Service (руководство запланировано)
• Перенос исполняемых JAR-приложений в Azure Virtual Machines (запланированное руководство).

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

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

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

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

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

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

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

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

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

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

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

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

Если приложение в настоящее время обслуживает статическое содержимое, для него требуется альтернативное расположение. Вы можете рассмотреть возможность перемещения статического содержимого в Azure Blob Storage и добавления Azure CDN для молниеносных скачиваний глобально. Дополнительные сведения см. в разделе Статическое размещение веб-сайтов в Azure Storage и Quickstart: интеграция учетной записи Azure storage с Azure CDN.

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

Если приложение поддерживает статическое содержимое, отправленное или созданное самим приложением, оно остается неизменным после его создания, можно интегрировать Azure Blob Storage и Azure CDN. Вы также можете использовать функцию Azure для управления отправкой и активацией обновлений CDN при необходимости. Мы предоставили пример реализации для вашего использования в разделе Загрузка и предварительная загрузка статического содержимого в CDN с помощью Azure Functions.

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

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

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

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

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

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

java -version

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

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

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

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

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

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

Мейвен

В проектах 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 Application 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.yaml :

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

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

• Репозитории JPA
• Репозитории JDBC
• Репозитории Cassandra
• Репозитории MongoDB

Брокеры сообщений 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).

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

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

• Сведения о конфигурации OAuth2 см. в справочнике по Spring Security.
• Сведения о конфигурации Auth0 Spring Security см. в документации по Auth0 Spring Security.
• Сведения о конфигурации PingFederate Spring Security см. в инструкциях auth0 PingFederate.

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

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

Все другие внешние ресурсы

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

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

Инвентаризация паролей и безопасных строк

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

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

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

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

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

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

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

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

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

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

Миграция

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

Создайте экземпляр Azure Container Apps в вашей подписке Azure. Его безопасная среда размещения создается вместе с ней. Дополнительные сведения см. в статье Quickstart: развертывание первого приложения контейнера с помощью портала Azure.

Убедитесь в записи логов в консоль и настройте параметры диагностики

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Оцените возможность настроить работу приложения с реестром Spring Cloud. Этот компонент позволяет вашему приложению быть динамически обнаруженным другими развернутыми приложениями Spring и клиентами. Дополнительные сведения см. в разделе Настройка параметров для компонента Eureka Server для Spring в Azure Container Apps. Затем измените все клиенты приложений, чтобы использовать Load Balancer Spring Client. Load Balancer Spring Client позволяет клиенту получать адреса всех запущенных экземпляров приложения и находить экземпляр, который работает, если другой экземпляр поврежден или не отвечает. Дополнительные сведения см. в разделе Spring Tips: Spring Cloud Load Balancer в блоге Spring.

• Вместо того чтобы сделать приложение общедоступным, рекомендуется добавить экземпляр Шлюза Spring Cloud . Spring Cloud Gateway предоставляет одну конечную точку для всех приложений, развернутых в среде Azure Container Apps. Если шлюз Spring Cloud уже развернут, убедитесь, что правило маршрутизации настроено для маршрутизации трафика в только что развернутое приложение.

• Попробуйте добавить сервер конфигурации Spring Cloud для централизованного управления конфигурацией и управления версиями для всех приложений Spring Cloud. Сначала создайте репозиторий Git для размещения конфигурации и настройки экземпляра приложения для его использования. Дополнительные сведения см. в разделе Настройка параметров для компонента Config Server for Spring в Azure Container Apps. Затем перенесите конфигурацию, выполнив следующие действия:

  1. В каталоге src/main/resources приложения создайте файл bootstrap.yml со следующим содержимым:

       spring:
         application:
           name: <your-application-name>
     

  2. В репозитории конфигурации Git создайте файл <your-application-name>.yml , где your-application-name соответствует тому же, что и на предыдущем шаге. Переместите параметры из файла application.yml в src/main/resources в созданный файл. Если параметры были ранее в файле СВОЙСТВ , сначала преобразуйте их в YAML. Можно найти веб-инструменты или подключаемые модули IntelliJ, которые помогут выполнить это преобразование.

  3. Создайте файл application.yml в приведенном выше каталоге. Этот файл можно использовать для определения параметров и ресурсов, общих для всех приложений в среде Azure Container Apps. К таким параметрам обычно относятся источники данных, параметры ведения журнала, конфигурация Spring Boot Actuator и др.

  4. Зафиксируйте эти изменения и отправьте их в репозиторий Git.

  5. Удалите файл application.properties или application.yml из приложения.

• Рассмотрите возможность добавления компонента администрирования для Spring, чтобы включить административный интерфейс для веб-приложений Spring Boot, предоставляющих конечные точки актуатора. Дополнительные сведения см. в разделе Настройка компонента администратора Spring Boot в Azure Container Apps.

• Обдумайте возможность добавить конвейер развертывания для автоматизации и обеспечения согласованности этого процесса. Инструкции доступны для Azure Pipelines и для GitHub Actions.

• Рассмотрите возможность использования версий контейнерных приложений, меток версии и весов входящего трафика, чтобы обеспечить сине-зеленое развертывание, что даёт возможность протестировать изменения кода в продуктивной среде, прежде чем они будут доступны некоторым или всем пользователям. Дополнительные сведения см. в разделе Blue-Green Развертывание в Azure Container Apps.

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

• Рекомендуется включить стек разработки Java для сбора основных метрик JVM для приложений. Дополнительные сведения см. в разделе метрики Java для приложений Java в Azure Container Apps.

• Рассмотрите возможность добавления правил генерации оповещений и групп действий Azure Monitor для быстрого обнаружения и устранения аберрантных условий. Дополнительные сведения см. в разделе Настроить оповещения в Azure Container Apps.

• Рассмотрите возможность репликации вашего приложения по зонам в регионе, включив зональную избыточность в Azure Container Apps. Трафик балансируется по нагрузке и автоматически направляется на реплики, если происходит сбой зоны обслуживания. Дополнительные сведения о избыточных параметрах см. в разделе Reliability в Azure Container Apps.

• Рассмотрите возможность защиты Azure Container Apps от распространенных эксплойтов и уязвимостей с помощью Web Application Firewall в шлюзе приложений. Дополнительные сведения см. в разделе Защита Azure Container Apps с помощью брандмауэра веб-приложений на шлюзе приложений.