This topic tells you about Tanzu Build Service dependencies.
ImportantUbuntu Bionic stack is deprecated and will be removed in a future release. VMware recommends that you migrate builds to Jammy stacks. For Tanzu Application Platform v1.5 and later, the default stack for Tanzu Build Service is Jammy.
To build OCI images, Tanzu Build Service has the following dependencies: Cloud Native Buildpacks, Stacks, and Lifecycles.
When Tanzu Application Platform is installed with Tanzu Build Service, it is bootstrapped with a set of dependencies. No extra configuration is required. Each version of Tanzu Application Platform and Tanzu Build Service contains new dependencies.
When Tanzu Application Platform is upgraded, new dependencies are installed which might cause workload images to rebuild. To ensure dependency compatibility, Tanzu Build Service only releases patches for dependencies in patch versions of Tanzu Application Platform. For upgrade instructions, see Upgrade the full dependencies package.
By default, Tanzu Build Service is installed with the lite
set of dependencies, which have a smaller-footprint and contain a subset of the buildpacks and stacks in the full
set of dependencies. For a comparison of lite
and full
dependencies, see Dependency comparison.
To view the set of dependencies installed with Tanzu Build Service, inspect the status of the cluster builders by running:
kubectl get clusterbuilder -o yaml
Cluster builders contain stack and buildpack metadata.
Tanzu Application Platform v1.3 and later supports Ubuntu v22.04 (Jammy) based builds and will default to it from Tanzu Application Platform v1.5 and later.
Ubuntu Bionic will stop receiving support in April 2023. VMware recommends that you migrate builds to Jammy.
For more information about support for Jammy stacks, see About lite and full dependencies later in this topic.
NoteWhile upgrading apps to a later stack, you might encounter the build platform erroneously reusing the old build cache. If you encounter this issue, delete and recreate the workload in Tanzu Application Platform, or delete and recreate the image in Tanzu Build Service.
Each version of Tanzu Application Platform is released with two types of Tanzu Build Service dependencies: lite
and full
. These dependencies consist of the buildpacks and stacks required for application builds. Each type serves different use cases. Both types are suitable for production workloads.
By default, Tanzu Build Service is installed with lite
dependencies, which do not contain all buildpacks and stacks. To use all buildpacks and stacks, you must install the full
dependencies. For instructions about installing full
dependencies, see Install full dependencies.
For a table comparing the differences between full
and lite
dependencies, see Dependency comparison.
The lite
dependencies are the default set installed with Tanzu Build Service.
lite
dependencies contain a smaller footprint to speed up installation time, but do not support all workload types. For example, lite
dependencies do not contain the PHP buildpack and cannot be used to build PHP workloads.
The lite
dependencies contain the following stacks:
base-jammy
(Ubuntu Jammy)default
(identical to base-jammy
)For more information, see Stacks in the VMware Tanzu Buildpacks documentation
The lite
dependencies contain the following buildpacks in Tanzu Application Platform v1.8:
Buildpack | Version | Supported Stacks |
---|---|---|
Java Buildpack for VMware Tanzu (Lite) | 9.15.2 | Bionic, Jammy, UBI |
Java Native Image Buildpack for Tanzu (Lite) | 7.13.2 | Bionic, Jammy |
.NET Core Buildpack for VMware Tanzu (Lite) | 2.10.0 | Bionic, Jammy |
Node.js Buildpack for VMware Tanzu (Lite) | 2.5.0 | Bionic, Jammy, UBI |
Python Buildpack for VMware Tanzu (Lite) | 2.7.0 | Bionic, Jammy |
Go Buildpack for VMware Tanzu (Lite) | 3.1.0 | Bionic, Jammy, Jammy Static |
Web Servers Buildpack for VMware Tanzu (Lite) | 0.17.1 | Bionic, Jammy |
Ruby Buildpack for VMware Tanzu (Lite) | 2.10.1 | Bionic, Jammy |
And the following components:
Component | Version | Supported Stacks |
---|---|---|
CNB Lifecycle | 0.16.0 | Bionic, Jammy |
Base Stack of Ubuntu Jammy for VMware Tanzu | 0.1.79 | Jammy |
The Tanzu Build Service full
set of dependencies contain more buildpacks and stacks, which allows for more workload types.
The dependencies are pre-packaged, so builds do not have to download them from the Internet. This can speed up build times and allows builds to occur in air-gapped environments. Due to the larger footprint of full
, installations might take longer.
The full
dependencies are not installed with Tanzu Build Service by default, you must install them. For instructions for installing full
dependencies, see Install Tanzu Build Service with full dependencies.
The full
dependencies contain the following stacks, which support different use cases:
base-jammy
(Ubuntu Jammy)full-jammy
(Ubuntu Jammy)tiny-jammy
(Ubuntu Jammy)default
(identical to base-jammy
)For more information, see Stacks in the VMware Tanzu Buildpacks documentation.
The full
dependencies contain the following buildpacks in Tanzu Application Platform v1.7:
Buildpack | Version | Supported Stacks |
---|---|---|
Java Buildpack for VMware Tanzu | 9.15.2 | Bionic, Jammy, UBI |
Java Native Image Buildpack for Tanzu | 7.13.2 | Bionic, Jammy |
.NET Core Buildpack for VMware Tanzu | 2.10.0 | Bionic, Jammy |
Node.js Buildpack for VMware Tanzu | 2.5.0 | Bionic, Jammy, UBI |
Python Buildpack for VMware Tanzu | 2.7.0 | Bionic, Jammy |
Ruby Buildpack for VMware Tanzu | 2.10.1 | Bionic, Jammy |
Go Buildpack for VMware Tanzu | 3.1.0 | Bionic, Jammy, Jammy Static |
PHP Buildpack for VMware Tanzu | 2.9.0 | Bionic, Jammy |
Web Servers Buildpack for VMware Tanzu | 0.17.1 | Bionic, Jammy |
Procfile Buildpack for VMware Tanzu | 5.7.0 | Bionic, Jammy |
And the following components:
Component | Version | Supported Stacks |
---|---|---|
CNB Lifecycle | 0.16.0 | Bionic, Jammy |
Tiny Stack of Ubuntu Jammy for VMware Tanzu | 0.1.86 | Jammy |
Base Stack of Ubuntu Jammy for VMware Tanzu | 0.1.83 | Jammy |
Full Stack of Ubuntu Jammy for VMware Tanzu | 0.1.140 | Jammy |
Standard Stack of UBI 8 for VMware Tanzu | 0.0.12 | UBI 8 |
Static Stack of Ubuntu Jammy for VMware Tanzu | 0.1.23 | Jammy |
The following table compares the contents of the lite
and full
dependencies.
Feature | lite | full |
---|---|---|
Faster installation time | Yes | No |
Dependencies pre-packaged (faster builds) | No | Yes |
Supports air-gapped installation | No | Yes |
Contains base stack | Yes | Yes |
Contains full stack | No | Yes |
Contains tiny stack | No | Yes |
Contains Jammy stack | Yes | Yes |
Supports Java workloads | Yes | Yes |
Supports Node.js workloads | Yes | Yes |
Supports Go workloads | Yes | Yes |
Supports Python workloads | Yes | Yes |
Supports Ruby workloads | Yes | Yes |
Supports .NET Core workloads | Yes | Yes |
Supports PHP workloads | No | Yes |
Supports static workloads | Yes | Yes |
Supports binary workloads | Yes | Yes |
Supports web servers buildpack | Yes | Yes |
New versions of dependencies such as buildpacks, and stacks are available in new versions of Tanzu Application Platform. To update dependencies, VMware recommends that you update to the latest patch version of Tanzu Application Platform.
If you are using lite
or full
dependencies, upgrade to the latest patch version of Tanzu Application Platform to update your dependencies.
If you are using full
dependencies, you must complete some extra steps after you upgrade to the latest patch. For more information, see Upgrading the full dependencies package.
NoteWhen Tanzu Application Platform is upgraded, new dependencies are installed which might cause workload images to rebuild.
To update dependencies between Tanzu Application Platform releases, you can either use automatic dependency updates or you can update dependencies manually.
Tanzu Build Service dependencies might be upgraded between Tanzu Application Platform releases, for example, if a CVE is discovered in the OS (stack update) or language (buildpack update).
Automatic dependency updates enable your cluster to consume the stack and buildpack updates immediately instead of waiting for the next Tanzu Application Platform patch release to pull in the updated dependencies.
tap-values.yaml
file or your full dependencies values.Prerequisites: These steps assume a registry secret already exists in the cluster for accessing tanzu-build.packages.broadcom.com
and your registry.
To enable automatic dependency updates:
Add the following to your tap-values.yaml
file:
buildservice:
dependency_updates:
allow: true
scope: SCOPE
include_packages: [""]
exclude_packages: [""]
Where:
SCOPE
is the list of dependencies you want updated. The options are:
stacks-only
(default): Only stacks and builders are updated. This addresses CVEs in the base image or operating system.all
: Stacks, builders, and buildpacks are updated. This addresses CVEs in the base image or operating system and CVEs in the language toolchain such as compilers, interpreters, and standard libraries.custom
: This list is empty by default. Use the include_packages
key to add packages to be updated.NoteYou must update the Tanzu Application Platform package install and the Full Dependencies package install after changing the
tap-values.yaml
.
Add the Tanzu Build Service Dependency Updates package repository by running:
kubectl apply -f - <<EOF
apiVersion: packaging.carvel.dev/v1alpha1
kind: PackageRepository
metadata:
name: tbs-dependencies-package-repository
namespace: tap-install
spec:
fetch:
imgpkgBundle:
image: DEPENDENCY-UPDATER-PACKAGE-REPO
tagSelection:
semver:
constraints: VERSION-CONSTRAINT
EOF
Where:
DEPENDENCY-UPDATER-PACKAGE-REPO
is the location of the package repository. This is tanzu-build.packages.broadcom.com/build-service-dependency-updater/package-repo
for online installs and the internal container image registry for air-gapped installs.VERSION-CONSTRAINT
is the Tanzu Application Platform version in the form of MAJOR.MINOR.x
. For example, 1.8.x
.After completing this configuration, the repository you set with DEPENDENCY-UPDATER-PACKAGE-REPO
will be polled for updates and any new releases will automatically be made available to the cluster.
You can update buildpack dependencies outside of upgrading Tanzu Application Platform, but VMware recommends that you upgrade Tanzu Application Platform when possible instead. Each Tanzu Application Platform release version includes a tested set of buildpacks. If you consume a buildpack from the Broadcom Support Portal that is not packaged and tested in a Tanzu Application Platform release, it might introduce errors.
Sign into VMware Tanzu Network so that the image can be retrieved from the registry.
Select the required buildpack in the Tanzu Buildpacks documentation. Select full
or lite
dependencies. Scroll to the Docker command, and copy the buildpack image URL for use in the next step.
Run:
imgpkg copy -b BUILDPACK-IMAGE-URL --to-repo ${INSTALL_REGISTRY_HOSTNAME}/${INSTALL_REPO}/tbs-deps/BUILDPACK-LANGUAGE
Where BUILDPACK-IMAGE-URL
is the buildpack image URL copied from the Docker command in the previous step
Create a ClusterBuildpack
resource referencing the copied buildpack image:
apiVersion: kpack.io/v1alpha2
kind: ClusterBuildpack
metadata:
name: out-of-band-LANGUAGE-NAME-BUILDPACK-VERSION
spec:
image: RELOCATED-BUILDPACKIMAGE
serviceAccountRef:
name: dependencies-pull-serviceaccount
namespace: build-service
Where RELOCATED-BUILDPACKIMAGE
is the URL of the relocated buildpack image from previous step.
To avoid naming collisions, follow the name conventions specified in metadata.name
. The name can follow any convention that allows the Cluster Operator to distinguish this ClusterBuildpack
from others installed by Tanzu Application Platform.
Apply the YAML from the previous step to the Tanzu Application Platform cluster:
kubectl apply -f FILE-FROM-PREVIOUS-STEP
The ClusterBuildpack
is now deployed. Tanzu Build Service uses the latest available version to run builds. All images that were built with older versions of the buildpack will now be rebuilt.
When you upgrade Tanzu Application Platform, new buildpacks with later versions are installed. After an upgrade, the ClusterBuildpack
created in this procedure is not needed and can be removed.