In my previous posts I showed you some of the capabilities of Tanzu Application Platform (TAP). We talked about the inner loop and outer loop. In this last article of the series we will explore the TAP GUI and show some of the capabilities.

Available articles in these TAP series are:

• Building and deploying your first app on Tanzu Application Platform (1/3) – Setup the inner loop: Setup the inner loop, configure the dev environment and build a first version of our app.
• Building and deploying your first app on Tanzu Application Platform (2/3) – Setup the ouer loop:Setup the outer loop, provide a SecOps process, build and deploy our app to Kubernetes.
• Building and deploying your first app on Tanzu Application Platform (3/3) – Explore the TAP Graphical User Interface.

Introducing TAP GUI

So the GUI of Tanzu Application Platform (aka “TAP GUI”) may look familiar to you if you already know Backstage.

Backstage is an open platform for building developer portals. Powered by a centralized software catalog, Backstage restores order to your microservices and infrastructure and enables your product teams to ship high-quality code quickly — without compromising autonomy.

Backstage unifies all your infrastructure tooling, services, and documentation to create a streamlined development environment from end to end (source).

So Backstage is a (CMS like) tool for building developer portals and its focus is to visualize what’s going on around software development. It’s up to you to think about how to build to your software in an automated and secure way (using available tools in the market and available plugins to interact with Backstage). The whole idea behind TAP is to provide a ready to consume platform for building your software through a secure supply chain, visualize documentation, get insights of CVEs in your software and provide application accelerators to get started with new software easily. Out of the box TAP provides a standard set of the cooleste open-source tools available in the market; but these tools are swappable according to your needs. Tools included are a.o. Cartographer, Tekton, Grype, Snyck, Kpack (Tanzu Build Service), Knative, Carvel tooling and more.

With this TAP, and more specifically TAP GUI, provides a lot of valuable capabilities to your organization:

• An overview of the assets in your organization in the TAP GUI Organization Catalog.
• An overview of and access to available documentation.
• Application Accelerators, organization defined frameworks, that will get you started quickly with building new apps.
• An overview of available APIs.
• Access to the workloads that went through the available supply chain(s) and delivery workflows. TAP GUI will show all the details about your software builds: available git repositiories, (unit)testing, source code scanning, building your containers, container scanning etc. and the actual deployment of your application to Kubernetes.
• TAP GUI displays an analysis of vulnerabilities discovered in your workload/software builds.

In this article we will walkt through the different components, with a major part of the blogpost focussing on what is happening in the out-of-the-box secure supply chain (spoiler: some cool stuff is happening here). My goal is also to show you how to objects in GUI translate to the Kubernetes CRDs underneath to give you a better understanding of how TAP works.

I will show you some screenshots of the different sections coming from a demo environment build, managed and hosted by my colleague Robert Jensen. Be sure to check out his blog for some great content.

The organization catalog

As already explained provides the Organization Catalog an overview of available assets. This includes available:

• APIs – An API describes an interface that can be exposed by a component.
• Components – A unit of software.
• Groups – An organizational entity (team, business unit) that has members of type User.
• Locations – References to other places to look for catalog data.
• Systems – A system is a collection of resources and components. A system may expose or consume one or several APIs.
• Templates – Describes the definition
• Users – This is a user of TAP. User belong to a group in the system.

These catalog entities are coming directly from Backstage, so you can review this page on backstage.io to get more background about this entities.

You can explore these assets and view additional details. It’s possible to filter available components on owner, lifecycle and tags. This simplifies the proces of finding the asset you need to access.

Opening a component gives you more information about the software component:

On the main page you get access to:

• The source code.
• The tech documentation which can contain information about the app, how to get started, dependencies, etc.
• The owner of the app, if the app is part of a bigger system, the type and lifecycle of the app.
• You can also get direct access to the app itself or publish links to external documentation.
• Information about subcompoments, if applicable.

This information is also defined in the catalog-info.yaml (example linked) that should be part of your application. The catalog-info.yaml is used to add the application to the components section of TAP GUI.

kubectl apply -f catalog-info.yaml

The GUI also show information on dependencies, used APIs and the runtime resources. The runtime resources tab displays all Kubernetes runtime information linked to the selected app:

Other catalog entities are also configured using YAML files. At this github page, owned by my colleague Robert Jensen, you will find some examples for configuring components, domains, groups/users and systems.

Documentation

As you would expect, the documentation tab provides an overview of all available documentation.

Click on the documentation to get access. In this case the documentation is coming straight from git, so the versioning and updates are all pushed to TAP after an update on your git repository.

Application accelerators

Application accelerators are the blueprints a developer can use and customize when he starts building a new application. I already discussed this topic in a previous article, so please go here to learn more.

APIs

APIs will be discussed in a future blogpost.

Review available supply chains and workload builds

The Workloads tab gives a list of apps that went through your Supply Chain en Delivery workflow. You can click a workload to get additional information on the used Supply Chain and on the different steps that are part of the workflow. There’s always a Supply Chain and Delivery Workflow part in place for each workload.

The main task of the Supply Chain is to build the application image (including scanning and testing if required), store it in a registry and build and store the Kubernetes configuration of the application. You can store the Kubernetes configuration in a registry or Git repository.

The main goal of the delivery workflow is deploying your application using the stored Kubernetes configuration and image:

In the Supply Chain:

• The Source Provider will monitor any updates to your Git repository and pull the source code if required.
• Source Tester will take care of things like linting and unit tests.
• The Source Scanner will scan the source of your app for CVEs.
• Image Provider will take care of building the application using Tanzu Build Service/Kpack (using Build Packs technology).
• Image Scanner is responsible for scanning the container built by the previous step.
• The Config Provider is responsible for applying conventions.
• The App Config, Service Bindings, Api Descriptors and Config Writer steps are responsible for building and storing the Kubernetes configuration for your application.

The delivery workflow will pull the Kubernetes configuration and actual container to deploy it to your Kubernetes cluster.

Let’s dive a little deeper into the different steps.

Source Provider

The Source Provider step is leveraging FluxCD for monitoring updates to the branch on your git repository. Clicking this step will show the repository that is monitored.

Entering

kubectl get gitrepositories.source.toolkit.fluxcd.io

will get an overview of Git repositories that are monitored by TAP.

kubectl get gitrepositories.source.toolkit.fluxcd.io nl-tanzu-java-web-app -o yaml

Will provide you additional information on the repository, branch, latest updates, etc. The stamped object ID is identical as the commit ID on Git/Github.

Source Tester

Now the source code is send to the Source Test step where (in this case) Tekton will take care of testing the Java/Spring source code (or any language you’re using). In this example a

./mvnw test

is executed. The specification for this test is available in this yaml file. This file contains a generic test that does nothing, as well as a default Java test. You have to apply these tests to your TAP environment and add the correct label to the workload.yaml of your application as illustrated below:

spec:
  params:
    - name: testing_pipeline_matching_labels
      value:
        apps.tanzu.vmware.com/language: java

The result of the test is available in the interface:

as well as on the commandline.

These log files are coming from the test pod(s) that Tekton spins up. This test log is running in the same namespace as your workload, it has the name “test-pod” in the podname.

kubectl get pods | grep test-pod

Now review the logs of the test-pod, all test-pod(s) for a specific application have an idea.

kubectl logs nl-tanzu-java-web-app-rlbnv-test-pod

You can get an overview of the available pipelineruns (actual test) using:

kubectl get pipelineruns.tekton.de

Source Scanner

After a succesful test, the source code is send to the next step, the Source Scanner. By default Grype is used for this.

kubectl get scanpolicies.scanning.apps.tanzu.vmware.com

Give you an overview of available scanning policies. An example scanning policy definition is available here.

kubectl get sourcescans.scanning.apps.tanzu.vmware.com

Give a list of all the completed source scans.

Image Provider

After a succesful test & scan it’s now time to build the container. The Image Provider step is used for this and leverages Tanzu Build Service (using Buildpacks) for this. You can review available build pods on the Kubernetes cluster:

kubectl get pods | grep build-pod

The sequence number in each pod is the build number. You can review the build logs in the TAP interview

To review the logs on the command line, you need the kpack command line tools to use the kp build logs command. Use brew on MacOS to install kp, or download one of the available binaries.

brew tap vmware-tanzu/kpack-cli
brew install kp

Review the builds:

kp build logs nl-tanzu-java-web-app

Or include the build number:

kp build logs nl-tanzu-java-web-app -b 11

Replace nl-tanzu-java-web-app with the image name you want to review. By selecting the step (ID) after the Image Provide step you can review where the container image of your app is stored:

In the next step the created image is scanned by Grype again. This is a image scan and not a source code scan (as in the previous step).

Image Scanner

In the image scanner step, the image that is stored in your container registry is scanned for vulnerabilities. So the input is:

• The registry where the scanner is stored and the name and digest of the image. This is the image that was build in the previous step.
• The scan template that is used. The default supply chain uses the private-image-scan-template template.
• The scan policy that is applicable. This is something you define yourself.

For the scan an ImageScan CRD is created, you can review this CRD with

kubectl get imagescans.scanning.apps.tanzu.vmware.com nl-tanzu-java-web-app -o yaml

Replace the image name with your own image name. The resulting YAML will show you which scan template is used (private-image-scan-template) and will also provide some details on the results of the scan.

Config provider, App Config and Config Writer

These step are responsible for the YAML definition of your app that will be applied to Kubernetes cluster you’re deploying your app to:

• The Config Provider is responsible for applying conventions to your app.
• The App Config, Service Bindings and Api Descriptors steps define the different Kubernetes configuration aspects of your application. (To be explored further in another article).
• The Config Writer writes the App Configuration to either a Git repository or to a file on your registry.

To determine where the App Configuration is stored, you can request the runnable CRD for your app:

kubectl get runnable nl-tanzu-java-web-app-config-writer -o yaml

The delivery.yml is stored as a base64 encoded file, the contents of this value is displayed in the runnable object:

Decoding this base64 value, will show the delivery.yml that will be used by the delivery workflow.

You can use this one-liner to get this information:

kubectl get runnable nl-tanzu-java-web-app-config-writer -o yaml | yq -r '.spec.inputs.params[0].value' | base64 --decode | yq -P '.'

Use this command to see where your configuration is stored on your registry:

k get runnable nl-tanzu-java-web-app-config-writer -o yaml | yq -r '.spec.inputs.params[1].value'

Pull config and delivery

Now we have our image and Kubernetes configuration file ready, it’s time to deploy the actual application to our Kubernetes cluster. For this the delivery workflow is used as introduced earlier:

The steps are, pull the app configuration (from the registry in this case, or from a Git repository if for GitOps approach).

kubectl get clusterdeliveries.carto.run

Will show this delivery workflow in the command-line and of course you get more details with

kubectl get clusterdeliveries.carto.run delivery-basic -o yaml

The pull-config will pull the configuration from the registry, this step is called source-provider in the YAML file. The Delivery step will (finally) deploy your configuration using kapp.

Deploy and view groups of Kubernetes resources as “applications”. Apply changes safely and predictably, watching resources as they converge.

An overview of created kapp objects in your cluster can be retrieved by entering:

kubectl get apps.kappctrl.k14s.io

The delivery of your app should appear in this list. And as always you can get more details about your app with:

kubectl get apps.kappctrl.k14s.io nl-tanzu-java-web-app -o yaml

You also might want to install kapp cli and utilize this tool. Now we have our app available, we want to have a look at the tree of all the objects that are created. This tree is available under Runtime Resources as part of a service in the component catalog.

The kapp object is there, subcomponents are the Knative service and at the end the Deployment, Replicaset and Pod.

Security analysis

The security analysis tap provides an overview of detected vulnerabilities. Depending wether a severity violates or doesn’t violate a policy, it will be displayed in the appropriate tab. More details about the detected CVEs and policies can be retrieved from the supply chain as discussed in the previous paragraph.

Settings

The settings tab allows you to review your infromation and set some appearance configuration settings. You can also sign-out from TAP through the Authentication Providers tab.