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

Статья
10/01/2024

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

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

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

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

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

Определение версий 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 Cloud .

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

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

Maven

В проектах Maven версия Spring Cloud обычно указывается в свойстве spring-cloud.version:

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

Gradle

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

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

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

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

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

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

Определите все агенты управления производительностью приложений, используемые приложениями. Приложения контейнеров Azure не поддерживают встроенную поддержку интеграции APM. Необходимо подготовить образ контейнера или интегрировать средство APM непосредственно в код. Если вы хотите измерить производительность приложения, но еще не интегрировать APM, рассмотрите возможность использования приложение Azure 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.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 Cloud обычно их можно найти в файлах application.properties и application.yml в каталоге приложений или в репозитории Сервера конфигурации Spring Cloud.

Вот пример 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).

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

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

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

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

Для приложений, управляемых через TAS, внешние ресурсы (включая описанные выше) часто настраиваются с помощью привязок службы TAS. Чтобы проверить конфигурацию таких ресурсов, с помощью TAS (Cloud Foundry) CLI узнайте значение переменной 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

Если для хранения и вызова секретов вы используете хранилище Spring Cloud, укажите резервное хранилище (например, HashiCorp или 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 Boot между несколькими регионами или центрами обработки данных. Задокументируйте требования к бесперебойной работе или соглашение об уровне обслуживания для приложений, которые вы переносите.

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

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

Миграция

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

Среда "Приложения контейнеров Azure" предлагает управляемый сервер Eureka Server, сервер конфигурации Spring Cloud и администратор. Если приложение привязано к компоненту Java, приложения контейнеров Azure внедряют связанные свойства в качестве системных переменных среды. Согласно структуре внешней конфигурации 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

Подготовьте приложение "Приложения контейнеров Azure" в подписке Azure в существующей управляемой среде или создайте новую для каждой службы, которую вы переносите. Вам не нужно создавать приложения, работающие как реестр Spring Cloud и серверы конфигурации. Дополнительные сведения см. в статье Краткое руководство. Развертывание первого приложения-контейнера с помощью портала Azure.

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

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

Примечание.

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

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

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

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

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

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

Миграция секретов из хранилища Spring Cloud в Azure Key Vault

Вы можете внедрять секреты прямо в приложения через Spring, используя начальный набор Spring Boot для Azure Key Vault. Дополнительные сведения см. в статье Как использовать начальное приложение Spring Boot Starter с Azure Key Vault.

Примечание.

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

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

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

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

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

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

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

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

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

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

Обновление клиентских приложений

Обновите конфигурацию всех клиентских приложений, чтобы использовать опубликованные конечные точки приложений контейнеров 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 с помощью Брандмауэр веб-приложений на Шлюз приложений".

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

Устарело	Текущие
Spring Cloud Eureka	Реестр службы Spring Cloud
Spring Cloud Netflix Zuul	Spring Cloud Gateway
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 Turbine	Micrometer и Prometheus

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

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

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

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

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

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

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

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

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

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

Maven

Gradle

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

Maven

Gradle

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

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

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

Базы данных

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

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

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

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

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

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

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

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

Определение используемого хранилища Spring Cloud

Определение сервера с данными о конфигурации

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

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

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

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

Миграция

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

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

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

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

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

Миграция секретов из хранилища Spring Cloud в Azure Key Vault

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

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

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

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

Обновление клиентских приложений

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

Обратная связь

Дополнительные ресурсы