How to deploy polyglot apps in the Azure Spring Apps Enterprise plan

This article applies to: ❎ Basic/Standard ✅ Enterprise

This article shows you how to deploy polyglot apps in the Azure Spring Apps Enterprise plan, and how these polyglot apps can use the build service features provided by buildpacks.

• An already provisioned Azure Spring Apps Enterprise plan instance. For more information, see Quickstart: Build and deploy apps to Azure Spring Apps using the Enterprise plan.
• Azure CLI version 2.45.0 or higher. Use the following command to install the Azure Spring Apps extension: az extension add --name spring

This section applies to building and deploying polyglot applications when the build service is enabled. If you disable the build service, you can deploy applications only with a custom container image. You can create your own image or use one built by an Azure Spring Apps Enterprise instance. For more information, see Deploy an application with a custom container image.

When you create an instance of Azure Spring Apps Enterprise, you must choose a default builder from one of the following supported language family buildpacks:

• Java Azure Buildpack for VMware Tanzu
• .NET Core Buildpack for VMware Tanzu
• Go Buildpack for VMware Tanzu
• Web Servers Buildpack for VMware Tanzu
• Node.js Buildpack for VMware Tanzu
• Python Buildpack for VMware Tanzu
• Java Native Image Buildpack for VMware Tanzu
• PHP Buildpack for VMware Tanzu

For more information, see Language Family Buildpacks for VMware Tanzu.

These buildpacks support building with source code or artifacts for Java, .NET Core, Go, web static files, Node.js, and Python apps. You can also see buildpack versions during creating or viewing a builder. And you can create a custom builder by specifying buildpacks and a stack.

All the builders configured in an Azure Spring Apps service instance are listed on the Build Service page, as shown in the following screenshot:

Select Add to create a new builder. The following screenshot shows the resources you should use to create the custom builder. The OS Stack includes Bionic Base, Bionic Full, Jammy Tiny, Jammy Base, and Jammy Full. Bionic is based on Ubuntu 18.04 (Bionic Beaver) and Jammy is based on Ubuntu 22.04 (Jammy Jellyfish). For more information, see the OS stack recommendations section.

We recommend using Jammy OS Stack to create your builder because VMware is deprecating Bionic OS Stack.

You can also edit a custom builder when the builder isn't used in a deployment. You can update the buildpacks or the OS Stack, but the builder name is read only.

The builder is a resource that continuously contributes to your deployments. It provides the latest runtime images and latest buildpacks.

You can't delete a builder when existing active deployments are being built with the builder. To delete a builder in this state, use the following steps:

1. Save the configuration as a new builder.
2. Deploy apps with the new builder. The deployments are linked to the new builder.
3. Migrate the deployments under the previous builder to the new builder.
4. Delete the original builder.

In Azure Spring Apps, we recommend using Jammy OS Stack to create your builder because Bioinic OS Stack is in line for deprecation by VMware. The following list describes the options available:

• Jammy Tiny: Suitable for building a minimal image for the smallest possible size and security footprint. Like building a Java Native Image, it can make the final container image smaller. The integrated libraries are limited. For example, you can't connect to an app instance for troubleshooting because there's no shell library.

  • Most Go apps.
  • Java apps. Some Apache Tomcat configuration options, such as setting bin/setenv.sh, aren't available because Tiny has no shell.

• Jammy Base: Suitable for most apps without native extensions.

  • Java apps and .NET Core apps.
  • Go apps that require some C libraries.
  • Node.js, Python, or Web Servers apps without native extensions.

• Jammy Full: Includes most libraries, and is suitable for apps with native extensions. For example, it includes a more complete library of fonts. If your app relies on the native extension, then use the Full stack.

  • Node.js or Python apps with native extensions.

For more information, see Ubuntu Stacks in the VMware documentation.

This section shows you how to manage the container registry used by the build service if you enable the build service with your own container registry. If you enable the build service with an Azure Spring Apps managed container registry, you can skip this section.

After you enable a user container registry with the build service, you can show and configure the registry using the Azure portal or the 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> 

The build service can use a container registry, and can also change the associated container registry. This process is time consuming. When the change happens, all the builder and build resources under the build service rebuild, and then the final container images get pushed to the new container registry.

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> 

You can build and deploy polyglot applications in the following ways using the container registry:

• For the build service using the Azure Spring Apps managed container registry, you can build an application to an image and then deploy it to the current Azure Spring Apps service instance. The build and deployment are executed together by using the az spring app deploy command.

• For the build service using a user-managed container registry, you can build an application into a container image and then deploy the image to the current Azure Spring Apps Enterprise instance and other instances. The build and deploy commands are separate. You can use the build command to create or update a build, then use the deploy command to deploy the container image to the service instance.

For more information, see the Build service on demand section of Use Tanzu Build Service.

The following examples show some helpful build commands to use.

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>

The following Azure CLI examples show building and deploying an artifact file for two container registry scenarios:

• Azure Spring Apps managed container registry.
• User-managed container registry.

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>

If you deploy the app with an artifact file, use --artifact-path to specify the file path. Both JAR and WAR files are acceptable.

If the Azure CLI detects the WAR package as a thin JAR, use --disable-validation to disable validation.

The following example deploys the source code folder to an active deployment by using the --source-path parameter to specify the folder.

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>

You can also configure the build environment to build the app. For example, in a Java application, you can specify the JDK version using the BP_JVM_VERSION build environment.

To specify build environments, use --build-env, as shown in the following example. The available build environment variables are described later in this article.

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>

For each build, you can also specify the build resources, as shown in the following example.

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>

The default build CPU/memory resource is 1 vCPU, 2 Gi. If your application needs a smaller or larger amount of memory, then use --build-memory to specify the memory resources - for example, 500Mi, 1Gi, 2Gi, and so on. If your application needs a smaller or larger amount of CPU resources, then use --build-cpu to specify the CPU resources - for example, 500m, 1, 2, and so on. The maximum CPU/memory resource limit for a build is 8 vCPU, 16Gi.

The CPU and memory resources are limited by the build service agent pool size. For more information, see the Build agent pool section of Use Tanzu Build Service. The sum of the processing build resource quota can't exceed the agent pool size.

The parallel number of build tasks depends on the agent pool size and each build resource. For example, if the build resource is the default 1 vCPU, 2 Gi and the agent pool size is 6 vCPU, 12 Gi, then the parallel build number is 6.

Other build tasks are blocked for a while because of resource quota limitations.

Your application must listen on port 8080. Spring Boot applications override the SERVER_PORT to use 8080 automatically.

The following table indicates the features supported for each language.

For more information about the supported configurations for different language apps, see the corresponding section later in this article.

Native Image is a technology to compile Java code ahead of time to a native executable. Native images provide various advantages, like an instant startup and reduced memory consumption. You can package native images into a lightweight container image for faster and more efficient deployment. Because of the Closed World Optimization, the following limitations apply:

• The following Java features require configuration at executable build time:
  • Dynamic Class Loading
  • Reflection
  • Dynamic Proxy
  • JNI (Java Native Interface)
  • Serialization
• Bytecode isn't available at runtime anymore, so debugging and monitoring with tools targeted to the JVMTI isn't possible.

The following features aren't supported in Azure Spring Apps due to the limitation of Java Native Image. Azure Spring Apps will support them when the Java Native Image and the community overcomes the limitation.

The buildpack for deploying Java applications is tanzu-buildpacks/java-azure.

The following table lists the features supported in Azure Spring Apps:

The buildpack for deploying .NET applications is tanzu-buildpacks/dotnet-core.

The following table lists the features supported in Azure Spring Apps:

The buildpack for deploying Python applications is tanzu-buildpacks/python.

The following table lists the features supported in Azure Spring Apps:

The buildpack for deploying Go applications is tanzu-buildpacks/go.

The following table lists the features supported in Azure Spring Apps:

The buildpack for deploying Node.js applications is tanzu-buildpacks/nodejs.

The following table lists the features supported in Azure Spring Apps:

The buildpack for deploying WebServer applications is tanzu-buildpacks/web-servers.

For more information, see Deploy web static files.

The buildpack for deploying Java Native Image applications is tanzu-buildpacks/java-native-image.

You can deploy Spring Boot native image applications using the tanzu-buildpacks/java-native-image buildpack. Spring Native provides support for compiling Spring Boot applications into native executables. The buildpack uses Liberica Native Image Kit (NIK) to create native images of Spring Boot applications and these applications are fully supported.

When you build a Java Native Image, you must set the build environment BP_NATIVE_IMAGE to true and the build memory resource shouldn't be less than 8Gi. The build service agent pool size shouldn't be less than 4 vCPU, 8 Gi. For more information, see the Build agent pool section of Use Tanzu Build Service.

If you want to build the native image into a smaller size container image, then we recommend using a builder with the Jammy Tiny OS stack. For more information, see the OS stack recommendations section.

The following table lists the features supported in Azure Spring Apps:

There are some limitations for Java Native Image. For more information, see the Java Native Image limitations section.

The buildpack for deploying PHP applications is tanzu-buildpacks/php.

The Tanzu PHP buildpack is only compatible with the Full OS Stack. We recommend using a builder with the Jammy Full OS stack. For more information, see the OS stack recommendations section.

The following table lists the features supported in Azure Spring Apps:

• Deploy web static files