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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Если вы создаете 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.

Определение версий 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 найдите версию Spring Boot в plugins разделе:

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 3.0 , чтобы обновить поддерживаемую версию. Поддерживаемые версии см. в разделе Spring Boot и Spring Cloud.

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

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

Maven

В проектах Maven задайте версию Spring Cloud в свойстве spring-cloud.version :

  <properties>
    <spring-cloud.version>2023.0.2</spring-cloud.version>
  </properties>

Градл

В проектах Gradle задайте версию Spring Cloud в блоке дополнительных свойств:

ext {
  set('springCloudVersion', "2023.0.2")
}

Необходимо обновить все приложения для использования поддерживаемых версий Spring Cloud. См. поддерживаемые версии в документации Spring Cloud.

Определите решения для агрегации журналов

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

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

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

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

Определите внешние ресурсы, в том числе источники данных, брокеры сообщений JMS и URL-адреса других служб. В приложениях Spring Cloud обычно можно найти конфигурацию для таких ресурсов в одном из следующих расположений:

• В папке src/main/resources находится файл, который обычно называется application.properties или application.yml.
• В репозитории сервера конфигурации Spring Cloud, который вы определили на предыдущем шаге.

Базы данных

Для приложения 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")
      ...
    }

После идентификации используемых брокеров найдите соответствующие параметры. Обычно они находятся в файлах 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 Cloud, требующие проверки подлинности и авторизации. Сведения о настройке поставщиков удостоверений см. в следующих ресурсах:

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

Ресурсы, настроенные с помощью службы VMware Tanzu Application Service (TAS) (ранее — Pivotal Cloud Foundry)

Для приложений, управляемых с помощью TAS, часто настраиваются внешние ресурсы, включая ресурсы, описанные ранее, с помощью связей сервисов TAS. Чтобы проверить конфигурацию таких ресурсов, используйте интерфейс командной строки TAS (Cloud Foundry) для просмотра VCAP_SERVICES переменной для приложения.

# Log into TAS, if needed (enter credentials when prompted)
cf login -a <API endpoint>

# Set the organization and space containing the application, if not already selected during login.
cf target org <organization name>
cf target space <space name>

# Display variables for the application
cf env <Application Name>

VCAP_SERVICES Проверьте переменную для параметров конфигурации внешних служб, привязанных к приложению. Дополнительные сведения см. в документации по TAS (Cloud Foundry).

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

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

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

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

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

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

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

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

Определение использования Spring Cloud Vault

Если вы используете Spring Cloud Vault для хранения и доступа к секретам, определите резервное хранилище секретов, например HashiCorp Vault или CredHub. Затем определите все секреты, которые использует код приложения.

Найдите источник сервера конфигурации

Если приложение использует сервер конфигурации Spring Cloud, определите, где хранится конфигурация. Обычно этот параметр можно найти в файле bootstrap.yml или bootstrap.properties или иногда в файле application.yml или application.properties . Этот параметр выглядит следующим образом:

spring.cloud.config.server.git.uri: file://${user.home}/spring-cloud-config-repo

Хотя git чаще всего используется в качестве резервного хранилища данных сервера конфигурации Spring Cloud, как показано ранее, ваше приложение может использовать одну из других возможных серверных служб. Ознакомьтесь с документацией по серверу конфигурации Spring Cloud для получения сведений о других серверных службах, таких как реляционная база данных (JDBC),SVN и локальная файловая система.

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

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

Для каждой службы Spring Cloud (не включая сервер конфигурации, реестр или шлюз) задокументируйте следующие сведения:

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

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

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

Выявление клиентов, которые обходят реестр службы

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

Migration

Удаление ограниченных конфигураций

Среда Azure Container Apps предлагает управляемые серверы Eureka Server, Spring Cloud Config и Spring Cloud Admin. При привязке приложения к компоненту Java, Azure Container Apps внедряет связанные свойства как системные переменные среды. Согласно дизайну внешней конфигурации Spring Boot, системные переменные среды перезаписывают свойства приложения, определенные в вашем коде или упакованные в артефакты.

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

• SPRING_CLOUD_CONFIG_COMPONENT_URI
• SPRING_CLOUD_CONFIG_URI
• SPRING_CONFIG_IMPORT
• eureka.client.fetch-registry
• eureka.client.service-url.defaultZone
• eureka.instance.prefer-ip-address
• eureka.client.register-with-eureka
• SPRING_BOOT_ADMIN_CLIENT_INSTANCE_PREFER-IP
• SPRING_BOOT_ADMIN_CLIENT_URL

Создайте управляемую среду Azure Container Apps и приложения

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

Подготовка сервера конфигурации Spring Cloud

Настройте сервер Config в Azure Container Apps для компонента Spring. Для получения дополнительной информации см. раздел Настройка параметров для компонента Config Server for Spring в Azure Container Apps.

Замечание

Если текущий репозиторий конфигурации Spring Cloud находится в локальной файловой системе или локальной среде, сначала необходимо перенести или реплицировать файлы конфигурации в облачный репозиторий, например GitHub, Azure Repos или BitBucket.

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

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

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

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

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

Перенос секретов Spring Cloud Vault в Azure Key Vault

Секреты можно внедрять непосредственно в приложения через Spring с помощью начального средства Spring Boot в Azure Key Vault. Дополнительные сведения см. в разделе Как использовать стартер Spring Boot для Azure Key Vault.

Замечание

Для миграции может потребоваться изменить название некоторых секретных данных. Вместе с этим обновите код приложения.

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

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

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

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

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

Параметры конфигурации можно внедрить в каждый контейнер в виде переменных среды. Все изменения в переменных создают новую редакцию для существующего приложения. Секреты являются парами "ключ-значение" и остаются действительными во всех редакциях.

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

Если для любого из приложений 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 конечные точки для перенесенных приложений.

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

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

Оптимизация для шаблонов на основе облака

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

Обнаружение сервисов и балансировка нагрузки

Включите приложение для работы с компонентом реестра Spring Cloud, чтобы другие развернутые приложения Spring и клиенты могли динамически обнаруживать его. Дополнительные сведения см. в разделе Настройка параметров компонента Eureka Server для Spring в Azure Container Apps.

Затем измените все клиенты приложений, чтобы использовать Load Balancer Spring Client. При использовании Spring Client Load Balancer клиент получает адреса всех запущенных экземпляров приложения и выбирает работающий экземпляр, если другой выходит из строя или перестает отвечать. Дополнительные сведения см. в разделе Spring Tips: Spring Cloud Load Balancer в блоге Spring.

Шлюз API

Рассмотрите возможность добавления экземпляра Spring Cloud Gateway. 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 в созданный файл. Если параметры были ранее в файле свойств .properties, сначала преобразуйте их в YAML. Вы можете найти онлайн-инструменты или подключаемые модули IntelliJ для выполнения этого преобразования.

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

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

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

Администрация

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

Повышение готовности к работе

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

• Конвейеры CI/CD: добавление конвейера развертывания для автоматического, согласованного развертывания. Инструкции доступны для Azure Pipelines и GitHub Actions.
• Сине-зеленое развертывание: используйте версии контейнерного приложения, метки версий и веса входящего трафика для тестирования изменений кода в производственной среде перед тем, как сделать их доступными для конечных пользователей. Чтобы получить более подробную информацию, см. раздел Blue-Green Deployment в Azure Container Apps.
• Привязки служб. Добавление привязок служб для подключения приложения к поддерживаемым базам данных Azure. Привязки служб устраняют необходимость предоставления сведений о подключении, включая учетные данные для приложений Spring Boot.
• Метрики JVM: включите стек разработки Java для сбора основных метрик JVM. Дополнительные сведения см. в статье Метрики Java для приложений Java в Azure Container Apps.
• Оповещения: Добавьте правила оповещений и группы действий в Azure Monitor для быстрого обнаружения и устранения аномальных условий. Дополнительные сведения см. в разделе Настроить оповещения в Azure Container Apps.
• Резервирование зоны: Дублируйте ваше приложение между зонами доступности, включив резервирование зоны. Трафик балансируется по нагрузке и автоматически направляется на реплики, если происходит сбой зоны обслуживания. Дополнительные сведения см. в статье "Надежность" в приложениях контейнеров Azure.
• Брандмауэр веб-приложения. Защита приложения-контейнера от распространенных эксплойтов и уязвимостей с помощью брандмауэра веб-приложения в шлюзе приложений. Дополнительные сведения см. в разделе Защита приложений Azure Container с использованием брандмауэра веб-приложений на шлюзе приложений.

Замена устаревших компонентов Spring Cloud Netflix

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

Устаревший компонент	Текущая альтернатива
Spring Cloud Eureka	Реестр службы Spring Cloud
Spring Cloud Netflix Zuul	Шлюз Spring Cloud
Spring Cloud Netflix Archaius	Сервер конфигурации Spring Cloud
Spring Cloud Netflix Ribbon	Spring Cloud Load Balancer (балансировщик нагрузки на стороне клиента)
Spring Cloud Hystrix	Spring Cloud Circuit Breaker и Resilience4J
Spring Cloud Netflix Турбина	Micrometer и Prometheus