In my first post about “building and deploying your first app on Tanzu Application Platform” we looked at the inner loop: setup the inner loop, configure the dev environment and build a first version of our app. In this second blogpost we will work on the outer loop: provide a SecOps process, build and deploy our app to Kubernetes.

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.

Outer Loop: Bring the app to production

In first post in these series we worked in the development environment of the developer. We’re now moving on to the SecOps proces; after a new commit is submitted to our repository a new version of the app is build and deployed to our “production” Kubernetes environment. Of course this is simplified representation of reality, but for the purpose of this article enough.

Make sure that your local git repository is synced with the remote repository. In my case my repository is located at https://github.com/viktoriousss/nl-tanzu-java-web-app.

You can either add your app to TAP using a one-liner command

tanzu apps workload create nl-tanzu-java-web-app --git-repo https://github.com/viktoriousss/tanzu-java-web-app --git-branch main --type web --label app.kubernetes.io/part-of=tanzu-java-web-app --yes --namespace tap-production

The structure of this command is:

• tanzu-java-web-app – name of the app used in TAP.
• –git-repo – where to find the application.
• –git-branch – which branch to monitor for this application, in this example it’s the main branch. Depending on your branching strategy, you can include different versions of your application and run different instances next to eachother (in different namespaces).
• –label – this is a label that’s added to the app so it can be found by TAP. More on that later.
• –yes – accept all prompts
• –namespace – the namespace to deploy the application to, in this case tap-production.

Another, easier option is to use a workload.yaml that is packed with your application. Now apply the yaml to the namespace of choice.

tanzu apps workload apply -f workload.yaml -n tap-production

After entering this command the supply chain will be active and will execute. Use

tanzu apps workload get nl-tanzu-java-web-app --namespace tap-production

to see what is going on.

At first you will probably see some error messages, this is expected because at first initial objects are not yet created.

You can also use

tanzu apps workload tail nl-tanzu-java-web-app --namespace tap-production

to monitor progress. These commands are similar as the commands used in the first part of this article. After a couple of minutes

tanzu apps workload get nl-tanzu-java-web-app --namespace tap-production

will show you’ve got a first version of the app available in the tap-production namespace.

The app (in this example) is available at http://tanzu-java-web-app.tap-production.tap.viktoriouslab.nl.

In this example you see that:

• The source is a git repository available at https://github.com/viktoriousss/tanzu-java-web-app.
• The source-to-url supply chain is used for creating the app and Kubernetes configuration.
• Delivery-basic is used for deployment of the Kubernetes configuration to the Kubernetes cluster.
• You see that build- and config-writer pods are available. No actual app pods are running at this moment, because Knative will shut down these pods if no requests are made.
• The app is available at http://tanzu-java-web-app.tap-production.tap.viktoriouslab.nl

Explore the default basic source-to-url supply chain

It this example the source-to-url supply chain was used. This (out of the box) supply chain lacks testing and scanning capabilities. The YAML file linked to this TAP installation is configured to use this basic supply chain:

supply_chain: basic # Can take testing, testing_scanning.

Other valid options are testing and testing_scanning. You can also of course also add/create your own supply chains.

You can explore available supply chain by executing:

kubectl get clustersupplychains.carto.run

This command will show two out-of-the-box supply chains: basic-image-to-url and source-to-url.

You can explore the supply chain with:

kubectl get clustersupplychains.carto.run source-to-url -o yaml

Let’s explore this supply chain and see what’s in it. Reviewing the YAML file for the first time might be a bit overwhelming, but if look at the basic structure you will get a better understanding of what’s going on:

We see a couple of things:

• The metadata part provides the name of the supply chain (source-to-url) and some other properties.
• The spec part contains three top levels:
  • Params – The params section allows to pass information to the supply chain. They can be set or delegated by other (external) objects.
  • Resources – The resource section represents the objects that will be stamped out in the supply chain of each workload.
  • Selector (called selectorMatchExpressions):
    • The selector determines which workloads will use this supply chain. In this case all workloads that have workload-type web, server or worker. The workload-type is set in the workload.yaml as part of your accelerator and application. In this case valid values that are used for selecting relevant workloads are: web, server and worker.
• The status part gives insight on the status of the supply chain and when it ran for the last time.

Diving a little deeper into the resources part of the supply chain, provides some more insight on the objects the supply chain is working with. The command

tanzu apps workload get tanzu-java-web-app --namespace tap-production

I showed earlier provides insight on created objects, the supply chain itself show the references on where these objects are coming from. We see ClusterTemplates, a ClusterImageTemplate and a ClusterSourceTemplate.

A ClusterSourceTemplate indicates how the supply chain could instantiate an object responsible for providing source code.

kubectl get clustersourcetemplates.carto.run source-template -o yaml

Gives some details on this. You could execute similar commands for ClusterTemplate and ClusterImageTemplate. To get a better understanding in general about Cartographer (the component that is used to manage and run the supply chains) I would recommend that you have a look at some interesting tutorials available at cartographer.sh.

Although I am not providing all the details, I hope this article helps to get a butter understanding of what is going on under the covers of Tanzu Application Platform. In a follow-up post we will explore the TAP GUI. Please leave your questions and comments below.