I’ve been publishing about Tanzu Application Platform (TAP) for a while now.
Tanzu Application Platform is a single, end-to-end integrated platform solution that enables companies to build and deploy more software, more quickly and securely, through a rich set of developer tooling and a pre-paved path to production.
As your probaly know, the two main components of TAP are:
- Tanzu Developer Portal – An internal developer platform based on Backstage
- Supply Chain Choreographer – A CI/CD like, Kubernetes based supply chain choreographer that brings your app from idea (source code) to production (running Kubernetes application).
In this post I’m going to explore the Services Toolkit of TAP 1.7 (and newer) that uses Crossplane and Bitnami Services to provide options to abstract classes and claims, dynamic provisioning of service instances and seamless integration of almost any service (cloud based or on-premises). Services in this example can be anything, but to make things a bit more concrete you could think of an actual Postgres DB, a RabbitMQ message broker, Kafka based services and many things more. Actually anything that is supported by Crossplane can be offered as a service to applications that are being build and deployed by Tanzu Application Platform:
Crossplane connects your Kubernetes cluster to external, non-Kubernetes resources, and allows platform teams to build custom Kubernetes APIs to consume those resources. Crossplane creates Kubernetes Custom Resource Definitions to represent the external resources as native Kubernetes objects.
As native Kubernetes objects, you can use standard commands like kubectl create and kubectl describe. The full Kubernetes API is available for every Crossplane resource. Crossplane also acts as a Kubernetes Controller to watch the state of the external resources and provide state enforcement. If something modifies or deletes a resource outside of Kubernetes, Crossplane reverses the change or recreates the deleted resource. More info here.
TAP comes with a set of standard services that are installed out-of-the box: the Bitnami Services. The following diagram, coming from the documentaiton, gives you an overview of the architecture:
So, a Workload running on TAP can bind to a ClassClaim through a Service Binding, the ClassClaim is linked to an instance of a certain Cluster Instance Class (for example a Postgresql database). Out of the Box a Bitnami Service Provider is available, that provides a set of services. You can choose to install and configure additional (Crossplane) providers to have additional services available for dynamic provisioning.
To see the available classes in your cluster are displayed using:
tanzu service class list
or:
kubectl get clusterinstanceclasses.services.apps.tanzu.vmware.com
Each service class/cluster instance class is linked to a Crossplane Composite Resource Definition. You can get a list of available of these Composite Resource Definitions with:
kubectl get compositeresourcedefinitions.apiextensions.crossplane.io
A composite resource definition defines the API for the Composite Resources and Claims.
So let’s say we need a new Postgresql database for a workload we’re going to deploy through TAP. Using the Tanzu CLI we can create a class-claim that can be consumed by a workload:
tanzu service class-claim create customer-database --class postgresql-unmanaged -n production
This creates a new database customer-database of type postgresql-unmanaged in namespace production. The actual instance of the Postgresql DB is not running in this namespace, a new namespace will be dynamically created that runs the database. You can retrieve this information using:
kubectl get classclaims.services.apps.tanzu.vmware.com customer-database -o jsonpath={.status.provisionedResourceRef.name}
The returned name in this example is customer-database-vpwds.
kubectl get all -n customer-database-vpwds
Returns the components that were being deployed to run our database:
A secret is created that reveals more details about this database instance.
kubectl get secret -n customer-database-vpwds customer-database-vpwds -o yaml
Now we’ve created the Class Claim (and thus the database), it’s now time to consume this database from a workload. The Tanzu Java Restful Web App is included as a demo app in TAP and requires a database (or actually service binding) that goes by the name of customer-database.
My instance of this app is available on GitHub. Take a closer look at the workload.yaml, specifically the part under spec.serviceClaims:
Here you can see a Service Claim definition that is pointing to our customer-database Class Claim.
Let’s now deploy our application and investigate the Service Bindings step:
Not all information is deployed in the interface, but if you open the configmap on the command-line you get more information the Service Binding to the database/classclaim:
kubectl get configmaps customer-profile-with-claims -o jsonpath={.data."serviceclaims\.yml"}
Results in:
Using
tanzu apps workload get customer-profile
Will also show the class-claim this app is consuming:
You’re now ready to use the app and read/write/update data from the database! Have fun.
If you want to learn more, there are a few great tutorials and how-to-guides available in the official documentation.
