TAP 1.6 – Tanzu Build Service Improvements

Tanzu Build Service (TBS) is a key component of TAP, allowing for building images directly from source code without needing to write and maintain docker files. TBS itself is built upon the opensource project kpack which till recently was hosted under the pivotal github repo, and recently was donated to the Cloud Native Buildpacks project and is now located at https://github.com/buildpacks-community/kpack. In TAP 1.6, TBS has a few changes that should be noted. The first major change is the removal of the Ubuntu Bionic stack, making the Jammy stack the officially supported option, now that ubuntu bionic is EOL from canonical. As Jammy was made the default in TAP 1.5 it should not cause any issues, but if you are using the bionic stack, be warned! The next major change, is the way you install the full dependencies package. In TAP the full TBS dependencies which are required in air gapped environments, and strongly recommended in production environments even when internet access is available, are packaged in a separate carvel package repository, and installed as another package install alongside TAP. Previous to TAP 1.6, the versioning of the package repository and package itself were based on the version of the TBS package within TAP and not on the TAP version itself. Now with TAP 1.6 and on, the versioning is the same as the TAP version, making the process easier to manage. Another key difference in the installation is that previously you did not need to pass any values into the TBS full dependencies package install, but in TAP 1.6 and on, you need to pass values to the package which should be the same values file that you provide to TAP itself. With all that out of the way we can now talk about the feature im truly excited about which is the introduction of the new Buildpack and ClusterBuildpack CRDs. Previously in Kpack, we had 3 main system level CRDs: ClusterStack – the pairing of a build and a run image which are used to build your images ClusterStore – a cluster scoped resource that references multiple buildpackages. ClusterBuilder / Builder – resources to define and create Cloud Native Buildpacks builders all within the kpack api. basically a pairing between a store and a stack. While this model worked, the clusterstore caused a bunch of issues, and had some limitations and pain points, as well as management overhead. As per the Buildpack CRD RFC: The ClusterStore being the single location for all buildpack images used in multiple builders makes managing the available buildpacks within kpack cumbersome. Adding new buildpacks requires modifying an existing resource and removing buildpacks requires carefully selecting the buildpack image to remove from the list of buildpackage images. The kp cli was built to handle this complexity but, the kp cli should not be a prerequisite to managing buildpacks within kpack. The ClusterStore being a monolithic specification of all available buildpacks leads to performance issues within kpack. If the list of available buildpacks within a ClusterStore is lengthy the reconciliation of a single ClusterStore can take considerable time. If a single buildpack within the ClusterStore is unavailable reconciliation will fail which will cause the entire contents of the ClusterStore to be unavailable. With that background we can now see why a new solution was needed. To solve these issues, Kpack has introduced a new set of CRDs, Buildpack and ClusterBuildpack, both providing the same functionality just one at the namespace scope and one at the cluster scope. A Buildpack CR is simply a CR pointing at the OCI image of the relevant buildpack, these buildpack CRs are now referenceable within a builder directly, without the need of working with stores. As of TAP 1.6, the new TBS configuration uses this new set of APIs instead of the previously used ClusterStore APIs. While this may seem like a backend detail which should not really matter to most, and that may indeed be the case, it allows for less errors and a better performing platform, and it also allows for easier integration of third party or custom homegrown buildpacks. A good example of this is when i had a use case to add a third party buildpack which enables installing apt packages into images. When i did this in previous TAP versions, i needed to package my own Cluster Store, and then also update my builder accordingly, now with TAP 1.6, i can simply add the new buildpack resource and reference it in the builder, with no need to rebuild and package a cluster store which is a tedious process. This model opens up a much easier path to extending TBS with custom buildpacks which is a great option to have in your toolbelt for the day that you need it. Summary While these changes may not be game changing things you will interact with daily, the subtle yet continuous improvements in these components such as TBS, are great to see, and all form together what in my opinion is the most mature and full featured Developer Platform offering on the market!