Обзор миграции приложений

Статья
02/04/2025

Примечание.

Планы "Базовый", "Стандартный" и "Корпоративный" будут устарели начиная с середины марта 2025 г. с 3-летнего периода выхода на пенсию. Рекомендуется перейти в приложения контейнеров Azure. Дополнительные сведения см. в объявлении о выходе на пенсию в Azure Spring Apps.

Стандартный план потребления и выделенного плана будет устарел с 30 сентября 2024 г. с полным завершением работы после шести месяцев. Рекомендуется перейти в приложения контейнеров Azure. Дополнительные сведения см. в статье "Миграция потребления Azure Spring Apps Standard" и выделенного плана в приложения контейнеров Azure.

Эта статья относится к:✅ Basic/Standard ✅ Enterprise

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

Необходимые компоненты

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

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

Приложения контейнеров Azure позволяют развертывать из реестров контейнеров, таких как Реестр контейнеров Azure (ACR) или Docker Hub. Для развертывания можно использовать такие средства, как портал Azure, Azure CLI или другие. В следующем примере показано, как развернуть приложение в целевой управляемой среде my-container-apps. Дополнительные сведения см. в статье "Развертывание первого приложения контейнера с помощью контейнера" или "Развертывание первого приложения контейнера" с помощью портал Azure.

az containerapp up \
    --resource-group my-container-apps \
    --name my-container-app \
    --location centralus \
    --environment 'my-container-apps' \
    --image mcr.microsoft.com/k8se/quickstart:latest \
    --target-port 80 \
    --ingress external

Теперь приложения контейнеров Azure предлагают предварительную версию для приложений Java. Эта функция позволяет пользователям развертывать приложения непосредственно из JAR-файла или исходного кода из локального или репозитория кода. Настоятельно рекомендуется развертывать приложения-контейнеры с помощью образа контейнера.

Переменные среды

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

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

az containerapp update \
    --resource-group <RESOURCE_GROUP_NAME> \
    --name <APP NAME> \
    --set-env-vars <VAR_NAME>=<VAR_VALUE>

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

Секреты

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

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

https://myvault.vault.azure.net/secrets/mysecret ссылается на последнюю версию секрета.
https://myvault.vault.azure.net/secrets/mysecret/<version-ID> ссылается на определенную версию секрета.

Для этого подхода необходимо включить управляемое удостоверение для приложения-контейнера и предоставить ему доступ к Key Vault. Политика доступа в Key Vault должна разрешить приложению получать GET секреты. Кроме того, если Key Vault использует управление доступом на основе ролей Azure, необходимо назначить Key Vault Secrets User роль. После настройки управляемого удостоверения вы можете добавить ссылку Key Vault в качестве секрета в приложении, указав универсальный код ресурса (URI) секрета. Затем приложение может получить секрет во время выполнения с помощью управляемого удостоверения.

Имейте в виду следующие правила:

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

Секреты можно использовать в приложениях-контейнерах, ссылаясь на них в переменных среды или включив их в тома. В переменных среды значение секрета заполняется автоматически. Кроме того, можно подключить секреты в томах. В этом случае каждый секрет хранится в виде файла с именем секрета в качестве имени файла и значения секрета в качестве содержимого файла. Эта гибкость позволяет безопасно обрабатывать секреты и получать доступ к ним в среде приложения. Дополнительные сведения см. в статье "Управление секретами в приложениях контейнеров Azure".

Если рабочая нагрузка защищает конфиденциальную конфигурацию и извлекает свойства из хранилища ключей с spring-cloud-azure-starter-keyvault-secrets библиотекой, можно использовать пакет SDK Azure или Spring KeyVault PropertySource в приложениях контейнеров Azure. Во время миграции не нужно изменять код.

Параметры виртуальной машины Java

Чтобы распечатать параметры JVM в приложениях контейнеров Azure, выполните действия, описанные в статье "Сборка образа контейнера из JAR-файла" или WAR для контейнеризации приложения. Вы можете добавить -XX:+PrintFlagsFinal файл ENTRYPOINT Dockerfile, как показано в следующем примере:

# filename: JAR.dockerfile

FROM mcr.microsoft.com/openjdk/jdk:17-mariner

ARG JAR_FILENAME

COPY $JAR_FILENAME /opt/app/app.jar
ENTRYPOINT ["java", "-XX:+PrintFlagsFinal", "-jar", "/opt/app/app.jar"]

Чтобы запросить параметры JVM в приложениях контейнеров Azure, используйте следующий запрос:

ContainerAppConsoleLogs_CL
| where ContainerAppName_s == "<APP_NAME>"
| where Log_s has_any ('{default}', '{command line}', '{ergonomic}')

Следующий журнал — это пример, в котором показаны параметры JVM после выполнения запроса:

size_t MinHeapSize = 8388608 {product} {ergonomic}
size_t MaxHeapSize = 268435456 {product} {ergonomic}

Чтобы настроить параметры JVM в приложениях контейнеров Azure, можно добавить параметры JVM в ENTRYPOINT файл Dockerfile, как показано в следующем примере:

# filename: JAR.dockerfile

FROM mcr.microsoft.com/openjdk/jdk:17-mariner

ARG JAR_FILENAME

COPY $JAR_FILENAME /opt/app/app.jar
ENTRYPOINT ["java", "-XX:+PrintFlagsFinal", "-Xmx400m", "-Xss200m", "-jar", "/opt/app/app.jar"]

Дополнительные сведения о параметрах JVM см. в разделе "Параметры виртуальной машины Java HotSpot" и "Настройка параметров JVM".

Хранилище

Azure Spring Apps и приложения контейнеров Azure поддерживают хранилище с областью контейнера, что означает, что данные, хранящиеся в контейнере, доступны только во время выполнения контейнера. Для Azure Spring Apps общее хранилище для приложения составляет 5 ГиБ. Приложения контейнеров Azure предлагают хранилище, которое составляет от 1 ГиБ до 8 ГиБ в зависимости от общего количества выделенных виртуальных ЦП. Это хранилище включает все временные хранилища, назначенные каждой реплике. Дополнительные сведения см. в разделе "Эфемерное хранилище" подключения хранилища в приложениях контейнеров Azure.

Azure Spring Apps и приложения контейнеров Azure поддерживают постоянное хранилище с помощью Файлы Azure. Приложения контейнеров Azure поддерживают подключение общих папок с помощью протоколов SMB и NFS. Необходимо создать определение хранилища в управляемой среде, а затем определить том AzureFile (SMB) или NfsAzureFile (NFS) в редакции. Вы можете завершить всю конфигурацию AzureFile (SMB) в портал Azure. Дополнительные сведения см. в статье "Создание подключения тома Файлы Azure в приложениях контейнеров Azure". Поддержка подключения общих папок NFS в настоящее время доступна в предварительной версии. Его можно настроить с помощью Azure CLI или шаблона ARM. Дополнительные сведения см. в разделе NFS Azure и в разделе "Создание общей папки NFS Azure " руководства. Создание общей папки NFS Azure и его подключение на виртуальной машине Linux с помощью портал Azure.

Управляемое удостоверение

Каждое приложение контейнера имеет управляемое удостоверение, назначаемое системой, или управляемые удостоверения, назначаемые пользователем, для доступа к защищенным ресурсам Azure. Сведения об управлении удостоверениями и предоставлением разрешений см. в статье "Управляемые удостоверения" в приложениях контейнеров Azure.

Каждое приложение контейнера имеет внутреннюю конечную точку REST, доступную через IDENTITY_ENDPOINT переменную среды, которая отличается от конечной точки, используемой в Azure Spring Apps. Если приложение использует прямой HTTP-запрос GET , необходимо настроить код, чтобы получить правильную конечную точку. Если приложение использует управляемое удостоверение через клиентскую библиотеку удостоверений Azure, вам не нужны изменения кода, так как удостоверение Azure автоматически управляет этой информацией.

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

Зонды работоспособности

Приложения контейнеров Azure и Azure Spring Apps поддерживают все три типа проб работоспособности, включая пробу запуска, пробу активности и пробу готовности. Для приложений контейнеров Azure пробы могут использовать протокол HTTP или TCP. exec пока не поддерживается.

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

Свойство	Description	Azure Spring Apps	Приложения-контейнеры Azure
`probeAction`	Действие пробы.	Поддерживает `HTTPGetAction`, `TCPSocketAction`и `ExecAction`.	Для типа действия нет свойств. Пользователь должен использовать либо напрямую, либо `httpGettcpSocket` напрямую.
`disableProbe`	Указывает, отключена ли проба.	Логический	Логический
`initialDelaySeconds`	Количество секунд после запуска экземпляра приложения перед запуском проб.		Значение диапазонов от 1 до 60.
`periodSeconds`	Как часто, в секундах, чтобы выполнить пробу.	Минимальное значение — 1.	Значение диапазонов от 1 до 240 с значением по умолчанию 10.
`timeoutSeconds`	Количество секунд, после которого время ожидания пробы истекает.	Минимальное значение — 1.	Значение диапазонов от 1 до 240 с значением по умолчанию 1.
`failureThreshold`	Минимальные последовательные сбои пробы, которые будут считаться неудачными после успешного выполнения.	Минимальное значение — 1.	Значение диапазонов от 1 до 10 с значением по умолчанию 3.
`successThreshold`	Минимальное число последовательных успешных попыток проведения пробы после сбоя, которое нужно, чтобы проба считалась успешной.	Минимальное значение — 1.	Значение диапазонов от 1 до 10 с значением по умолчанию 1.
`terminationGracePeriodSeconds`	Необязательная длительность в секундах модуля pod должна завершиться корректно при сбое пробы.	Значение по умолчанию — 90 секунд.	Максимальное значение — 3600 секунд.

В настоящее время вы не можете настроить пробы для приложений контейнеров Azure непосредственно на портал Azure. Вместо этого необходимо настроить их с помощью шаблона ARM или файла YAML приложения контейнера с помощью Azure CLI. Дополнительные сведения см. в статье "Пробы работоспособности" в приложениях контейнеров Azure.

Масштабировать

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

Масштабирование имеет три категории триггеров, HTTP, TCP и настраиваемых. HTTP и TCP основаны на количестве запросов или сетевых подключений. Дополнительные сведения см. в статье Установка правил масштабирования в Контейнерах приложений Azure.

Масштабирование триггера на основе ЦП или памяти

Пользовательские правила масштабирования приложений контейнеров основаны на масштабировщике KEDA на основе ScaledObject. Вы можете достичь масштабирования с помощью приложений-контейнеров на основе использования ЦП или памяти с помощью масштабировщика ЦП KEDA и масштабирования памяти.

В следующем примере показана конфигурация, при которой масштабирование происходит, когда среднее использование памяти превышает 25 %. Использование памяти включает в себя память, используемую текущим приложением контейнера, а также соответствующими модулями pod, такими как внутренние контейнеры бокового контейнера. KEDA включает встроенную конфигурацию, чтобы предотвратить перехват приложения контейнера. Дополнительные сведения о внутренних параметрах см. в разделе "Настройка правил масштабирования в приложениях контейнеров Azure". Необходимо проверить поведение во время выполнения, чтобы убедиться, что он соответствует вашим потребностям.

az containerapp create \
    --resource-group MyResourceGroup \
    --name my-containerapp \
    --image my-queue-processor --environment MyContainerappEnv \
    --min-replicas 1 --max-replicas 10 \
    --scale-rule-name memory-scaler \
    --scale-rule-type memory \
    --scale-rule-metadata "type=Utilization" \
                          "value=25"

Масштабирование триггера на основе метрик Java

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

Необходимые компоненты

Зарегистрируйте приложение в Microsoft Entra ID. Дополнительные сведения см. в Быстрый старт: зарегистрируйте приложение на платформе идентификации Microsoft.
Предоставьте разрешения. Назначьте зарегистрированное приложение Monitoring Reader роли для ресурса Azure Container Apps.

Шаги

Добавьте секреты. Используйте следующую команду, чтобы сохранить идентификатор клиента и секрет приложения Microsoft Entra в приложениях контейнеров Azure в качестве секретов:
```
az containerapp secret set \
    --resource-group MyResourceGroup \
    --name my-containerapp \
    --secrets activeDirectoryClientId=<Microsoft-Entra-Application-Client-ID> \
              activeDirectoryClientPassword=<Microsoft-Entra-Application-Client-Password>
```

Определите правило масштабирования. Используйте следующую команду, чтобы создать пользовательское правило масштабирования, использующее масштабировщик Azure Monitor. Это правило активирует действия масштабирования на основе определенной метрики Java, например JvmThreadCountотслеживаемой с помощью Azure Monitor.

az containerapp create \
    --resource-group MyResourceGroup \
    --name my-containerapp \
    --image my-queue-processor --environment MyContainerappEnv \
    --min-replicas 1 --max-replicas 10 \
    --scale-rule-name thread-count \
    --scale-rule-type azure-monitor \
    --scale-rule-auth "activeDirectoryClientId=activeDirectoryClientId" \
                      "activeDirectoryClientPassword=activeDirectoryClientPassword" \
    --scale-rule-metadata "activationTargetValue=1" \
                          "metricAggregationInterval=0:1:0" \
                          "metricAggregationType=Maximum" \
                          "metricName=JvmThreadCount" \
                          "resourceGroupName=MyResourceGroup" \
                          "resourceURI=MyContainerAppShortURI" \
                          "subscriptionId=MyResourceID" \
                          "targetValue=30" \
                          "tenantId=MyTenantID"

Сведения о ключе

Управление секретами: учетные данные приложения — идентификатор клиента и пароль — безопасно хранятся в виде секретов.
Критерии масштабирования. Параметр metricName определяет метрику Java ( JvmThreadCount в данном случае — которая используется для оценки времени масштабирования.
Целевое значение: targetValue параметр задает пороговое значение для масштабирования, например масштабирование, если число потоков превышает 30.

Задав это правило, приложение-контейнер может динамически настраивать количество экземпляров на основе метрик производительности java, повышая скорость реагирования и использование ресурсов.

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

Обзор миграции приложений

Необходимые компоненты

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

Переменные среды

Секреты

Параметры виртуальной машины Java

Хранилище

Управляемое удостоверение

Зонды работоспособности

Масштабировать

Масштабирование триггера на основе ЦП или памяти

Масштабирование триггера на основе метрик Java

Необходимые компоненты

Шаги

Сведения о ключе

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

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