In this Services Toolkit tutorial you learn how developers can use direct references to Kubernetes
Secret resources to connect their application workloads to almost any backing service.
This includes backing services that:
If you are familiar with Cloud Foundry and Tanzu Application Service, this capability is similar to the concept of user-provided service instances. For more information about user-provided service instances in Cloud Foundry, see the Cloud Foundry documentation.
This tutorial demonstrates a procedure to bind a new application on Tanzu Application Platform to an existing PostgreSQL database that exists in Azure. However, the steps are applicable to any backing service that you want to connect to.
Target user role: Service Operator and Application Operator
Estimated time: 10 minutes
Topics covered: Service Binding, Direct Secret References
Learning outcomes: Ability to bind workloads to almost any backing service using direct secret references
Before you can follow this tutorial, you must have:
Create a file named
external-azure-db-binding-compatible.yaml and enter a Kubernetes secret resource similar to the following example:
# external-azure-db-binding-compatible.yaml --- apiVersion: v1 kind: Secret metadata: name: external-azure-db-binding-compatible type: Opaque stringData: type: postgresql provider: azure host: EXAMPLE.DATABASE.AZURE.COM port: "5432" database: "EXAMPLE-DB-NAME" username: "USER@EXAMPLE" password: "PASSWORD"
Substitute in the values as required.
When using direct secret references, the
Secret values must abide by the Well-known Secret Entries specifications as defined by the Service Binding Specification for Kubernetes. If you plan to bind this secret to a Spring-based application workload and want to take advantage of the auto-wiring feature, this secret must also contain the properties required by Spring Cloud Bindings.
Apply the YAML file by running:
kubectl apply -f external-azure-db-binding-compatible.yaml
In a file named
stk-secret-reader.yaml, grant sufficient Role-Based Access Control (RBAC) permissions to permit Services Toolkit to read the secrets specified by the class:
# stk-secret-reader.yaml --- apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: stk-secret-reader labels: servicebinding.io/controller: "true" rules: - apiGroups: - "" resources: - secrets verbs: - get - list - watch
Apply your changes by running:
kubectl apply -f stk-secret-reader.yaml
Create a claim for the newly created secret by running:
tanzu service resource-claim create external-azure-db-claim \ --resource-name external-azure-db-binding-compatible \ --resource-kind Secret \ --resource-api-version v1
Obtain the claim reference of the claim by running:
tanzu service resource-claim list -o wide
Expect to see the following output:
NAME READY REASON CLAIM REF external-azure-db-claim True services.apps.tanzu.vmware.com/v1alpha1:ResourceClaim:external-azure-db-claim
From the output, record the value of
Create an application workload by running a command similar to the following example:
tanzu apps workload create WORKLOAD-NAME \ --git-repo https://github.com/sample-accelerators/spring-petclinic \ --git-branch main \ --git-tag tap-1.2 \ --type web \ --label app.kubernetes.io/part-of=spring-petclinic \ --annotation autoscaling.knative.dev/minScale=1 \ --env SPRING_PROFILES_ACTIVE=postgres \ --service-ref db=REFERENCE
WORKLOAD-NAMEis the name of the application workload. For example,
REFERENCEis the value of the
CLAIM REFfor the newly created claim in the output of the last step.