This topic describes commercial buildpacks supported by VMware Tanzu Application Service for VMs (TAS for VMs).
Commercial buildpacks are of the following types:
- Cloud Foundry Buildpacks
- Cloud Native Buildpacks, adapted for use by Cloud Foundry
The following table lists the commercial buildpacks available for TAS for VMs:
| Name | Supported languages, frameworks, and technologies | Type |
|---|---|---|
| Java | Java, Spring, Spring Boot, Grails, Play, etc. | Cloud Foundry |
| Java Native Image | Java, Spring, Spring Boot, Quarkus | Cloud Native* |
| Kerberos | Kerberos | Cloud Foundry |
| Web Servers | NGINX, HTTPD, and Frontend JavaScript | Cloud Native* |
Cloud Foundry Buildpacks
Commercial Cloud Foundry buildpacks are v2 buildpacks as described in buildpacks.io, originally written to run on Cloud Foundry.
Some are commercial versions of open-source buildpacks listed in CF Buildpack Languages and Sources.
Cloud Native Buildpacks (beta)
Commercial Cloud Native buildpacks for TAS for VMs are based on Tanzu Buildpacks, which are Kubernetes-based, v3 buildpacks as described in buildpacks.io.
For TAS for VMs, these buildpacks are packaged work with Cloud Foundry.
These buildpacks are still in beta and have some limitations. For details, see Limitations of Beta release
VMware does not recommend using these buildpacks in production at this time.
Removing the beta Cloud Native Buildpacks
For operators who do not wish to give developers access to the beta Cloud Native Buildpacks, they can make changes using the cf CLI with admin access:
cf update-buildpack web_servers_cnb_beta --disable
Limitations
Cloud Native Buildpacks for TAS for VMs have these known limitations:
- Procfiles: Apps with Procfiles do not work correctly with the implementation of CNBs for TAS. Only the
webprocess type is honored by Cloud Foundry. This is because the Procfile Cloud Native Buildpack, which ships as part of most meta-buildpacks (or composite buildpacks), manages the Procfile in a way that CF/Diego does not handle. - Service Bindings: CNBs were designed with Kubernetes secrets in mind, so service bindings, which typically contain credentials, do not work with Cloud Native buildpacks adapted for TAS for VMs.
