Tanzu Application Platform

calendar Jul 23, 2022 · 8 min read · kubernetes Tanzu TAP  ·
Share on: linkedin copy

Today's post will be a multipart article covering the Tanzu Application Platform (TAP). First, we will cover what TAP is, illustrate a basic single cluster install, then dive into a full multi-cluster install using GitOps. Managing a cluster via GitOps will allow platform operators to manage a large community of developers at scale.

The following topic will be covered.

What is the Tanzu Application Platform (TAP)

Tanzu Application Platform (TAP) enables enterprises to deliver a developer experience atop Kubernetes. Tanzu Application Platform abstracts away the toil of container creation and Deployment YAML. It allows for a secure software supply chain and GitOps deployment/promotion models.

It lets developers focus on authoring business logic, user interfaces, and APIs. Meanwhile, the operations teams can declare compliant delivery processes in a consistent, automated, repeatable manner.

Personas

For the purpose of this post, we are going to define a few personas. Those personas will help us understand how TAP fits into various job roles.

  • Cody. - Cody is an application developer who loves to be productive. He doesn't want to get bogged down in learning technologies not related to what he loves to do. Since coding is his passion, he wants to be able to code within the curly braces and not worry about platform abstractions such as Kubernetes, building containers, how to connect to databases, and implementing single sign-on,
  • Alana - Alana is a platform Operator. Her job is to help developers run their apps in Kubernetes. In addition, she is responsible for ensuring that applications meet the security requirements of her organization and have no Critical CVEs.

Application Accelerator

Cody has just received an assignment to implement a small catalog microservice. As is his company's best practice, he would like to create a small web application to serve as a microservice.

To get started, Cody heads over to his company's application catalog and chooses the java web application accelerator. An accelerator is a template that Naomi created. This template contains everything he needs to get started. Using it, he automatically brings in enterprise standards for project structure, including naming convents, directory organization, and maven settings.

Once stepping through the accelerator creation process, Cody downloads the zip bundle and checks it into a new git repo. Now he can start coding his microservice.

IDE Tools

While Cody has never deployed an application to Kubernetes before, he is a creature of habit and wants to use his favorite IDE. In this case, since he is working on a Java app, he will work with Intellij. Fortunately, TAP has integrations with Intellij, so he can quickly test his application on a live Kubernetes cluster.

Iterative Development

Cody would first like to test his skeleton project and ensure it starts correctly. Then, after importing the project into his IDE, he can start the application on a remote cluster. Using the Tanzu IDE plugin, he can experience running the application in an environment that more closely represents production rather than his laptop.

This task is simple. All Cody has to do is right-click on the included workload file and choose Run. The TAP plugin will then submit the code to be turned into a container and run on the cluster.

At this point, Cody hasn't needed to run Docker or build a Dockerfile. Instead, once submitted to TAP, Tanzu Build Service (TBS) is used to scan the source code, determine the application type, and build the container. Since this is a Spring Boot application, the java build pack is selected and is used to create the container.

TBS uses technology from the open source community called buildpacks. Buildpacks were conceived initially by Heroku and used in Cloud Foundry as a way to shift the container creation process away from the developer. Buildpacks include the base operating system and the required runtimes. We will discuss this feature more when we cover Alana's tasks for managing TAP.

After the container is created and started, Cody is given a URL on his machine to test his application. This magic is made possible by forwarding a local server port on Cody's machine to the app running on the cluster. When he visits http://localhost:8080, he can see his application.

Live View

After verifying that the initial app has started, Cody goes to work coding the required business logic. Once he gets the application coded to his satisfaction, he starts it up on the remote cluster again so he can test it.

While testing the application, he noticed that he needed to make a small change. Since he started the application via his IDE, any change he makes triggers a patch to the container, and the change is reflected immediately on the cluster. This feature allows Cody to quickly verify his changes on a running cluster versus waiting for a complete build to occur in a CI/CD pipeline.

Although Cody is a good Test Driven Development practitioner, he has just encountered a problem where he would like to use his IDE's debugger. Normally this would be problematic since the application runs on a container on a remote cluster. Thankfully he can use the Tanzu plugin to start in debug mode. Once running, the plugin can direct debugging traffic to the remote Kubernetes pod.

Cody is now definitely in his productivity zone.

Workloads

Now that Cody has finished his work, he wants his co-workers to be able to use the new service in the development environment. So it's now Alana's turn to get the application running in the environments she manages.

Alana creates a new Workload in TAP to start this process. A workload is a small piece of YAML that points to Cody's source code in a GIT repository and automatically builds the application with each commit. It also defines the workload type. The workload type selects the proper supply chain that turns the source code into a container.

 1apiVersion: carto.run/v1alpha1
 2kind: Workload
 3metadata:
 4  name: tanzu-java-web-app
 5  labels:
 6    apps.tanzu.vmware.com/workload-type: web
 7    app.kubernetes.io/part-of: tanzu-java-web-app
 8spec:
 9  params:
10    - name: run-image
11      value: registry.gcp.ellin.net/tanzu-java-web-app
12  source:
13    git:
14      url: https://github.com/sample-accelerators/tanzu-java-web-app
15      ref:
16        branch: main

Supply Chain

Alana's company has strict requirements about auditing what software gets into their running cluster. The requirements aim to prevent applications that don't meet security standards from entering the run clusters.

Alana has developed a Supply Chain that is responsible for moving software from source control to a running environment in a repeatable, secure way. In addition, this Supply Chain will check the software along the way for compliance and stop the process if anything fails along the way.

In Alana's case, she has defined a supply chain that implements the following steps.

Supplychain

  1. Scan for commits to the Git repo, which contains the application code. Run Quality Tests on the software, including Unit Tests and static analysis
  2. Scan the source code using Grype and build a Bill of Materials. ( If a high criticality CVE is detected, stop the process) Publish the results to the Software Metastore
  3. Build the container using a Cloud Native Buildpack
  4. Scan the image for Vulnerabilities. ( If a high criticality CVE is detected, stop the process) Publish the results to the Software Metastore
  5. Create the YAML used to deploy the application and push it to a GitOps repo via a Pull Request

Steps 3 and 5 mention a component called the Metastore, which is included with TAP. The Metastore keeps track of which applications use which dependencies. In the event of a risk security event such as the recent Log4J vulnerability, Alana can use the Metastore to identify all applications that have used a particular library.

In addition to identifying vulnerable apps, Alana can quickly remediate issues uncovered in the Metastore. As the operator, Alana can import new buildpacks into TBS regularly. TBS will quickly rebase all images by replacing the os and runtime layers. Tanzu delivers new buildpacks on a regular cadence. The updates include the latest fixes to the base operating system used by the container.

Deliverable

Once the Supply Chain creates an image and the deployment YAML, it is time for Alana to move the code into the test environment. She does this by creating a Deliverable. This small but essential piece of YAML describes where the desired Kubernetes Deployment lives in Git.

 1---
 2apiVersion: carto.run/v1alpha1
 3kind: Deliverable
 4metadata:
 5  labels:
 6    app.kubernetes.io/component: deliverable
 7    app.kubernetes.io/part-of: hello
 8    app.tanzu.vmware.com/deliverable-type: web
 9    carto.run/supply-chain-name: source-test-scan-to-url
10    carto.run/workload-name: hello
11    carto.run/workload-namespace: canary-prod
12  name: hello
13  namespace: canary-prod
14spec:
15  params:
16  - name: gitops_ssh_secret
17    value: git-ssh
18  source:
19    git:
20      ref:
21        branch: prod
22      url: https://github.com/jeffellin/gitops-hello
23    subPath: config/canary/hello

Since the Kubernetes Deployment is in Git, Alana just needs to approve the Pull Request created by the prior Supply Chain. By merging pull requests on protected branches, Alana can control which version of the application will run in a given environment. In the above example whatever is deployed to the prod branch will be deployed to the prod environment.

A second supply chain facilitates this process. This new supply chain will deploy the application once Alana approves the Pull Request created by the previous supply chain.

Supplychain

Scan for updated Deployments in the GitOps repo. Apply the Deployment to the desired environment

What's Next

The following article will delve into more detail on how Cody interacts with the Tanzu Application Platform. We will see how he uses application accelerators to kickstart his work. Additionally, we will see how he can use his IDE to help test and debug his new application.

After that, we will look into how Alana creates a workload and deploys the code to the test environment.

Finally, we will look at how platform operators can install and maintain the TAP platform using GitOps.

Posts in this Series

comments powered by Disqus