This topic gives you an overview of the Where for Dinner? application, which is a sample application to use for learning about Tanzu Platform for Kubernetes.
Getting started with Tanzu Platform for Kubernetes takes you through the steps to deploy the sample Where for Dinner?
application. This application requires the following components:
For simplicity, we have provided prebuilt artifacts for Where for Dinner
. The prebuilt artifacts include microservices (ContainerApps), Services, and Routing Configurations.
The Where For Dinner?
has 6 microservices that were built by using tanzu build
to create ContainerApps that are ready to be deployed. This process produces ready to deploy ContainerApps.
To learn how to use tanzu build
to build the Where for Dinner?
application, or your own application, see How to Use Tanzu Build.
The Where For Dinner?
application is a stateful application that requires backing services to store state of the running application. In the Where for Dinner?
case, it requires MySQL and Redis. With Tanzu Platform for Kubernetes, you can use the concept of service bindings to bind the application to backing services, giving you the flexibility to choose your service provider.
For this Getting Started guide, the pre-built Where for Dinner
application deploy and bind to Bitnami services to store state.
Bitnami-backed services:
Bitnami-backed services are intended for low-cost and low-complexity development use cases. The Bitnami-based backing services use services from the Bitnami Catalog deployed to the Space. Backing services from Bitnami are deployed in each Availability Target and Space replica. Therefore, if you have multiple Availability Targets or Space replicas, you have multiple instances of the Bitnami services deployed.
These currently do not replicate to each other, so deployed applications are functional but data is split-brained between Space replicas and availability targets.
AWS-backed services:
AWS-backed services are intended for production use cases in which an application is scaled across multiple Availability Targets or Space replicas. These backing services are located outside of the Space, and all instances of the application connect to the shared service. For more information, see Bind backing services to your application.
The Where for Dinner application requires a method of routing traffic from the browser to the service. This is accomplished using an HTTP Ingress defined with the application.
The prebuilt Where for Dinner has been configured to use where-for-dinner
as the host name. When the application is deployed, Tanzu Platform for Kubernetes creates a GLSB that uses the where-for-dinner
host name in combination with the domain specified in Create network profile. For example, if you configure the application to use tanzu-demo.net
for the domain, the URL for the deployed Where for Dinner? application is http://where-for-dinner
.