Use Tanzu Build Service
Note
The Basic, Standard, and Enterprise plans will be deprecated starting from mid-March, 2025, with a 3 year retirement period. We recommend transitioning to Azure Container Apps. For more information, see the Azure Spring Apps retirement announcement.
The Standard consumption and dedicated plan will be deprecated starting September 30, 2024, with a complete shutdown after six months. We recommend transitioning to Azure Container Apps. For more information, see Migrate Azure Spring Apps Standard consumption and dedicated plan to Azure Container Apps.
This article applies to: ❎ Basic/Standard ✅ Enterprise
This article shows you how to use VMware Tanzu Build Service with the Azure Spring Apps Enterprise plan.
VMware Tanzu Build Service automates container creation, management, and governance at enterprise scale. Tanzu Build Service uses the open-source Cloud Native Buildpacks project to turn application source code into container images. It executes reproducible builds aligned with modern container standards and keeps images up to date.
Buildpacks
VMware Tanzu Buildpacks provide framework and runtime support for applications. Buildpacks typically examine your applications to determine what dependencies to download and how to configure applications to communicate with bound services.
The language family buildpacks are composite buildpacks that provide easy out-of-the-box support for the most popular language runtimes and app configurations. These buildpacks combine multiple component buildpacks into ordered groupings. The groupings satisfy each buildpack's requirements.
Builders
A Builder is a Tanzu Build Service resource. A Builder contains a set of buildpacks and a stack used in the process of building source code.
Build agent pool
Tanzu Build Service in the Enterprise plan is the entry point to containerize user applications from both source code and artifacts. There's a dedicated build agent pool that reserves compute resources for a given number of concurrent build tasks. The build agent pool prevents resource contention with your running apps.
The following table shows the sizes available for build agent pool scale sets:
Scale set | CPU/Gi |
---|---|
S1 | 2 vCPU, 4 Gi |
S2 | 3 vCPU, 6 Gi |
S3 | 4 vCPU, 8 Gi |
S4 | 5 vCPU, 10 Gi |
S5 | 6 vCPU, 12 Gi |
S6 | 8 vCPU, 16 Gi |
S7 | 16 vCPU, 32 Gi |
S8 | 32 vCPU, 64 Gi |
S9 | 64 vCPU, 128 Gi |
Tanzu Build Service allows at most one pool-sized build task to build and twice the pool-sized build tasks to queue. If the quota of the agent pool is insufficient for the build task, the request for this build gets the following error: The usage of build results in Building or Queuing status are (cpu: xxx, memory: xxxMi) and the remained quota is insufficient for this build. please retry with smaller size of build resourceRequests, retry after the previous build process completed or increased your build agent pool size
.
Configure the build agent pool
When you create a new Azure Spring Apps Enterprise service instance using the Azure portal, you can use the VMware Tanzu settings tab to configure the number of resources given to the build agent pool.
The following image shows the resources given to the Tanzu Build Service Agent Pool after you successfully provision the service instance. You can also update the configured agent pool size here after you create the service instance.
Build service on demand
You can enable or disable the build service when you create an Azure Spring Apps Enterprise plan instance.
Build and deployment characteristics
By default, Tanzu Build Service is enabled so that you can use a container registry. If you disable the build service, you can deploy an application only with a custom container image. You have the following options:
Enable the build service and use the Azure Spring Apps managed container registry.
Azure Spring Apps provides a managed Azure Container Registry to store built images for your applications. You can execute build and deployment together only as one command, but not separately. You can use the built container images to deploy applications in the same service instance only. The images aren't accessible by other Azure Spring Apps Enterprise service instances.
Enable the build service and use your own container registry.
This scenario separates build from deployment. You can execute builds from an application's source code or artifacts to a container image separately from the application deployment. You can deploy the container images stored in your own container registry to multiple Azure Spring Apps Enterprise service instances.
Disable the build service.
When you disable the build service, you can deploy applications only with container images, which you can build from any Azure Spring Apps Enterprise service instance.
Configure build service settings
You can configure Tanzu Build Service and container registry settings using the Azure portal or the Azure CLI.
Use the following steps to enable Tanzu Build Service when provisioning an Azure Spring Apps service instance:
Open the Azure portal.
On the Basics tab, select Enterprise tier in the Pricing section, and then specify the required information.
Select Next: VMware Tanzu settings.
On the VMware Tanzu settings tab, select Enable Build Service. For Container registry, the default setting is Use a managed Azure Container Registry to store built images.
If you select Use your own container registry to store built images (preview) for Container registry, provide your container registry's server, username, and password.
If you disable Enable Build Service, the container registry options aren't provided but you can deploy applications with container images.
Select Review and create.
Deploy polyglot applications
You can deploy polyglot applications in an Azure Spring Apps Enterprise service instance with Tanzu Build Service either enabled or disabled. For more information, see How to deploy polyglot apps in Azure Spring Apps Enterprise.
Configure APM integration and CA certificates
By using Tanzu Partner Buildpacks and CA Certificates Buildpack, the Azure Spring Apps Enterprise plan provides a simplified configuration experience to support application performance monitor (APM) integration. This integration includes certificate authority (CA) certificates integration scenarios for polyglot applications. For more information, see How to configure APM integration and CA certificates.
Real-time build logs
A build task is triggered when an application is deployed from an Azure CLI command. Build logs are streamed in real time as part of the CLI command output. For information about using build logs to diagnose problems, see Analyze logs and metrics with diagnostics settings.
Build history
You can see all the build resources in the Builds section of the Azure Spring Apps Build Service page.
The table in the Builds section contains the following columns:
- Build Name: The name of the build.
- Provisioning State: The provisioning state of the build. The values are
Succeeded
,Failed
,Updating
, andCreating
. Provisioning statesUpdating
andCreating
mean the build can't be updated until the current build finishes. Provisioning stateFailed
means your latest source code build has failed to generate a new build result. - Resource Quota: The resource quota in build pod of the build.
- Builder: The builder used in the build.
- Latest Build Result: The latest build result image tag of the build.
- Latest Build Result Provisioning State: The latest build result provisioning state of the build. The values are
Queuing
,Building
,Succeeded
, andFailed
. - Latest Build Result Last Transition Time: The last transition time for the latest build result of the build.
- Latest Build Result Last Transition Reason: The last transition reason for the latest build result of the build. The values are
CONFIG
,STACK
, andBUILDPACK
.CONFIG
means the build result is changed by builder updates or by a new source code deploy operation.STACK
means the build result is changed by a stack upgrade.BUILDPACK
means the build result is changed by a buildpack upgrade. - Latest Build Result Last Transition Status: The last transition status for the latest build result of the build. The values are
True
andFalse
.
For Provisioning State, when the value is Failed
, deploy the source code again. If the error persists, create a support ticket.
For Latest Build Result Provisioning State, when the value is Failed
, check the build logs. For more information, see Troubleshoot common build issues in Azure Spring Apps.
For Latest Build Result Last Transition Status, when the value is Failed
, see the Latest Build Result Last Transition Reason column. If the reason is BUILDPACK
or STACK
, no action is necessary. If the reason is CONFIG
, deploy the source code again. If the error persists, create a support ticket.