Развертывание многолотных приложений в плане Azure Spring Apps Enterprise

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

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

Предварительные условия

• Уже развернутый экземпляр плана Azure Spring Apps Enterprise. Дополнительные сведения см. в кратком руководстве по созданию и развертыванию приложений в Azure Spring Apps с использованием плана Enterprise.
• Azure CLI версии 2.45.0 или более поздней. Чтобы установить расширение Azure Spring Apps, выполните следующую команду: az extension add --name spring

Развертывать многоязычные приложения в экземпляре службы

Этот раздел относится к созданию и развертыванию приложений polyglot при включении службы сборки. Если отключить службу сборки, можно развертывать приложения только с помощью пользовательского образа контейнера. Вы можете создать собственный образ или использовать образ, созданный экземпляром Azure Spring Apps Enterprise. Дополнительные сведения см. в статье «Развертывание приложения с помощью пользовательского образа контейнера».

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

При создании экземпляра Azure Spring Apps Enterprise необходимо выбрать построитель по умолчанию из одного из следующих поддерживаемых пакетов сборок семейства языков:

• Java Azure Buildpack для VMware Tanzu
• Buildpack .NET Core для VMware Tanzu
• Go Buildpack для VMware Tanzu
• Сборка веб-серверов для VMware Tanzu
• Node.js Buildpack для VMware Tanzu
• Python Buildpack для VMware Tanzu
• Пакет сборки образов Java native для VMware Tanzu
• PHP Buildpack для VMware Tanzu

Дополнительные сведения см. в разделе "Сборки семейства языков" для VMware Tanzu.

Эти пакеты сборки поддерживают создание исходного кода или артефактов для Java, .NET Core, Go, статических веб-файлов, Node.js и приложений Python. При создании или просмотре сборщика также отображаются версии билдпаков. И вы можете создать пользовательский построитель, указав пакеты сборки и стек.

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

Нажмите кнопку Добавить, чтобы создать новый элемент. На следующем снимке экрана показаны ресурсы, которые следует использовать для создания настроенного конструктора. Стек ОС включает Bionic Base, Bionic Full, Jammy Tiny, Jammy Base и Jammy Full. Бионик основан на Ubuntu 18.04 (Bionic Beaver) , и Джеймми основан на Ubuntu 22.04 (Jammy Jellyfish). Для получения дополнительной информации см. раздел Рекомендации по стеку ОС.

Рекомендуем использовать Jammy OS Stack для создания вашего конструктора, так как VMware прекращает поддержку Bionic OS Stack.

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

Сборщик — это ресурс, который постоянно вносит вклад в ваши развертывания. Он предоставляет последние образы среды выполнения и последние пакеты сборки.

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

1. Сохраните конфигурацию как новый сборщик.
2. Разверните приложения с помощью нового конструктора. Развертывания связаны с новым построителем.
3. Перенесите развертывания от предыдущего построителя к новому построителю.
4. Удалите оригинального строителя.

Рекомендации по стеку ОС

В Azure Spring Apps мы рекомендуем использовать Jammy OS Stack для построения, так как Bioinic OS Stack планируется к устареванию компанией VMware. В следующем списке описаны доступные параметры:

• Jammy Tiny: Подходит для создания минимального образа для достижения наименьшего возможного размера и уровня защищенности. Как и создание собственного образа Java, он может уменьшить окончательный образ контейнера. Интегрированные библиотеки ограничены. Например, вы не можете подключиться к экземпляру приложения для устранения неполадок , так как нет shell библиотеки.

  • Большинство приложений Go.
  • Приложения Java. Некоторые параметры конфигурации Apache Tomcat, такие как настройка bin/setenv.sh, недоступны, так как Tiny не имеет оболочки.

• Jammy Base: подходит для большинства приложений без собственных расширений.

  • Приложения Java и приложения .NET Core.
  • Перейдите к приложениям, которым требуются некоторые библиотеки C.
  • Node.js, приложения Python или веб-серверы без собственных расширений.

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

  • Node.js или приложения Python с собственными расширениями.

Дополнительные сведения см. в разделе Ubuntu Stacks документации VMware.

Управление реестром контейнеров

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

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

az spring container-registry list \
    --resource-group <resource-group-name> \
    --service <Azure-Spring-Apps-instance-name> 

az spring container-registry show \
    --resource-group <resource-group-name> \
    --service <Azure-Spring-Apps-instance-name> \
    --name <your-container-registry-name>

az spring container-registry update \
    --resource-group <resource-group-name> \
    --service <Azure-Spring-Apps-instance-name> \
    --name <your-container-registry-name> \
    --server <your-container-registry-login-server> \
    --username <your-container-registry-username> \
    --password <your-container-registry-password>

az spring container-registry delete \
    --resource-group <resource-group-name> \
    --service <Azure-Spring-Apps-instance-name> \
    --name <your-container-registry-name> 

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

az spring build-service show \
    --resource-group <resource-group-name> \
    --service <Azure-Spring-Apps-instance-name>

az spring build-service update \
    --resource-group <resource-group-name> \
    --service <Azure-Spring-Apps-instance-name> \
    --registry-name <your-container-registry-name> 

Создание и развертывание многоязыковых приложений

Вы можете создавать и развертывать приложения polyglot следующими способами с помощью реестра контейнеров:

• Для службы сборки с помощью управляемого реестра контейнеров Azure Spring Apps можно создать образ приложения, а затем развернуть его в текущем экземпляре службы Azure Spring Apps. Сборка и развертывание выполняются вместе с помощью az spring app deploy команды.

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

Для получения дополнительной информации см. раздел «Служба сборки по запросу» в документе «Использование службы сборки Tanzu».

В следующих примерах показаны некоторые полезные команды сборки для использования.

az configure --defaults group=<resource-group-name> spring=<service-name>

az spring build-service build list
az spring build-service build show --name <build-name>
az spring build-service build create --name <build-name> --artifact-path <artifact-path>
az spring build-service build update --name <build-name> --artifact-path <artifact-path>
az spring build-service build delete --name <build-name>

В следующих примерах Azure CLI показано создание и развертывание файла артефакта для двух сценариев реестра контейнеров:

• Управляемый реестр контейнеров Azure Spring Apps.
• Реестр контейнеров, управляемый пользователем.

az spring app deploy \
    --resource-group <resource-group-name> \
    --service <Azure-Spring-Apps-instance-name> \
    --name <app-name> \
    --builder <builder-name> \
    --artifact-path <path-to-your-JAR-file>

az spring build-service build create \
    --resource-group <resource-group-name> \
    --service <Azure-Spring-Apps-instance-name> \
    --name <build-name> \
    --builder <builder-name> \
    --artifact-path <path-to-your-JAR-file>

az spring build-service build update \
    --resource-group <resource-group-name> \
    --service <Azure-Spring-Apps-instance-name> \
    --name <build-name> \
    --builder <builder-name> \
    --artifact-path <path-to-your-JAR-file>

az spring app deploy \
   --resource-group <resource-group-name> \
   --service <Azure-Spring-Apps-instance-name> \
   --name <app-name> \
   --container-image <your-container-image> \
   --container-registry <your-container-registry> \
   --registry-password <your-password> \
   --registry-username <your-username>

При развертывании приложения с файлом артефакта используйте --artifact-path для указания пути к файлу. КАК JAR-файлы, так и WAR допустимы.

Если Azure CLI обнаруживает пакет WAR как тонкий JAR-файл, используйте --disable-validation для отключения проверки.

В следующем примере папка с исходным кодом разворачивается в активное развертывание с помощью параметра --source-path для указания папки.

az spring app deploy \
    --resource-group <resource-group-name> \
    --service <Azure-Spring-Apps-instance-name> \
    --name <app-name> \
    --builder <builder-name> \
    --source-path <path-to-source-code>

az spring build-service build create \
   --resource-group <resource-group-name> \
   --service <Azure-Spring-Apps-instance-name> \
    --name <build-name> \
    --builder <builder-name> \
    --source-path <path-to-source-code>

az spring build-service build update \
    --resource-group <resource-group-name> \
    --service <Azure-Spring-Apps-instance-name> \
    --name <build-name> \
    --builder <builder-name> \
    --source-path <path-to-source-code>

Вы также можете настроить среду сборки для создания приложения. Например, в приложении Java можно указать версию JDK с помощью среды сборки BP_JVM_VERSION .

Чтобы указать среды сборки, используйте --build-env, как показано в следующем примере. Доступные переменные среды сборки описаны далее в этой статье.

az spring app deploy \
    --resource-group <resource-group-name> \
    --service <Azure-Spring-Apps-instance-name> \
    --name <app-name> \
    --build-env <key1=value1> <key2=value2> \
    --builder <builder-name> \
    --artifact-path <path-to-your-JAR-file>

az spring build-service build create \
    --resource-group <resource-group-name> \
    --service <Azure-Spring-Apps-instance-name> \
    --name <build-name> \
    --build-env <key1=value1> <key2=value2> \
    --builder <builder-name> \
    --artifact-path <path-to-your-JAR-file>

az spring build-service build update \
    --resource-group <resource-group-name> \
    --service <Azure-Spring-Apps-instance-name> \
    --name <build-name> \
    --build-env <key1=value1> <key2=value2> \
    --builder <builder-name> \
    --artifact-path <path-to-your-JAR-file>

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

az spring app deploy \
    --resource-group <resource-group-name> \
    --service <Azure-Spring-Apps-instance-name> \
    --name <app-name> \
    --build-env <key1=value1> <key2=value2> \
    --build-cpu <build-cpu-size> \
    --build-memory <build-memory-size> \
    --builder <builder-name> \
    --artifact-path <path-to-your-JAR-file>

az spring build-service build create \
    --resource-group <resource-group-name> \
    --service <Azure-Spring-Apps-instance-name> \
    --name <build-name> \
    --build-env <key1=value1> <key2=value2> \
    --build-cpu <build-cpu-size> \
    --build-memory <build-memory-size> \
    --builder <builder-name> \
    --artifact-path <path-to-your-JAR-file>

az spring build-service build update \
    --resource-group <resource-group-name> \
    --service <Azure-Spring-Apps-instance-name> \
    --name <build-name> \
    --build-env <key1=value1> <key2=value2> \
    --build-cpu <build-cpu-size> \
    --build-memory <build-memory-size> \
    --builder <builder-name> \
    --artifact-path <path-to-your-JAR-file>

Ресурс ЦП и памяти сборки по умолчанию — 1 vCPU, 2 Gi. Если приложению требуется меньше или больше памяти, используйте --build-memory для указания ресурсов памяти , например, 500Mi, 1Gi2Giи т. д. Если приложению требуется меньшее или большее количество ресурсов ЦП, используйте для --build-cpu указания ресурсов ЦП , например, 500m, 12и т. д. Максимальное ограничение ресурсов процессора и памяти для сборки составляет 8 vCPU, 16Gi.

Ресурсы ЦП и памяти ограничены размером пула агентов службы сборки. Дополнительную информацию см. в разделе Пул агентов сборки в Use Tanzu Build Service. Суммарная квота ресурсов для обработки не может превышать размер пула агентов.

Параллельное число задач сборки зависит от размера пула агентов и каждого ресурса сборки. Например, если ресурс сборки по умолчанию — это 1 vCPU, 2 Gi, а размер пула агентов — 6 vCPU, 12 Gi, то число параллельных сборок равно 6.

Другие задачи сборки блокируются в течение некоторого времени из-за ограничений квоты ресурсов.

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

Поддерживаемые языки для развертываний

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

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

Ограничения нативных образов Java

Native Image — это технология компиляции кода Java заранее в собственный исполняемый файл. Собственные образы обеспечивают различные преимущества, такие как мгновенное запуск и сокращение потребления памяти. Вы можете упаковать нативные образы в облегченный контейнерный образ для более быстрого и эффективного развертывания. Из-за оптимизации закрытого мира применяются следующие ограничения :

• Для следующих функций Java требуется настройка во время сборки исполняемого файла:
  • Загрузка динамического класса
  • Отражение
  • Динамический прокси-сервер
  • JNI (собственный интерфейс Java)
  • Сериализация
• Байт-код больше недоступен во время выполнения, поэтому отладка и мониторинг с помощью средств, предназначенных для JVMTI, невозможна.

Следующие функции не поддерживаются в Azure Spring Apps из-за ограничений Java Native Image. Azure Spring Apps будет поддерживать их после того, как сообщество справится с ограничением Java Native Image.

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

Пакет buildpack для развертывания приложений Java — tanzu-buildpacks/java-azure.

В следующей таблице перечислены функции, поддерживаемые в Azure Spring Apps:

Развертывание приложений .NET

Пакет buildpack для развертывания приложений .NET — tanzu-buildpacks/dotnet-core.

В следующей таблице перечислены функции, поддерживаемые в Azure Spring Apps:

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

Пакет buildpack для развертывания приложений Python — tanzu-buildpacks/python.

В следующей таблице перечислены функции, поддерживаемые в Azure Spring Apps:

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

Пакет buildpack для развертывания приложений Go — tanzu-buildpacks/go.

В следующей таблице перечислены функции, поддерживаемые в Azure Spring Apps:

Развертывание приложений Node.js

Пакет buildpack для развертывания Node.js приложений — tanzu-buildpacks/nodejs.

В следующей таблице перечислены функции, поддерживаемые в Azure Spring Apps:

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

Пакет сборки для развертывания приложений WebServer — tanzu-buildpacks/web-servers.

Дополнительные сведения см. в разделе "Развертывание статических веб-файлов".

Развертывание приложений на Java Native Image (предварительная версия)

Пакет buildpack для развертывания приложений машинного образа Java — tanzu-buildpacks/java-native-image.

Вы можете развернуть приложения как нативные образы Spring Boot с помощью пакета сборки tanzu-buildpacks/java-native-image. Spring Native поддерживает компиляцию приложений Spring Boot в собственные исполняемые файлы. Пакет buildpack использует пакет образов Liberica Native Image Kit (NIK) для создания собственных образов приложений Spring Boot, и эти приложения полностью поддерживаются.

При создании Java Native Image необходимо задать среду сборки на BP_NATIVE_IMAGEtrue, и ресурс памяти сборки не должен быть меньше 8Gi. Размер пула агента службы сборки не должен быть меньше 4 vCPU, 8 Gi. Дополнительную информацию см. в разделе Пул агентов сборки в Use Tanzu Build Service.

Если вы хотите создать нативный образ в виде образа контейнера меньшего размера, мы рекомендуем использовать построитель со стеком ОС Jammy Tiny. Для получения дополнительной информации см. раздел Рекомендации по стеку ОС.

В следующей таблице перечислены функции, поддерживаемые в Azure Spring Apps:

Существуют некоторые ограничения для нативного образа Java. Дополнительные сведения см. в разделе ограничений Java Native Image.

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

Пакет buildpack для развертывания приложений PHP — tanzu-buildpacks/php.

Пакет сборки Tanzu PHP совместим только с полным стеком ОС. Рекомендуем использовать билдер с стеком ОС Jammy Full. Для получения дополнительной информации см. раздел Рекомендации по стеку ОС.

В следующей таблице перечислены функции, поддерживаемые в Azure Spring Apps:

Следующие шаги

• Развертывание статических веб-файлов