Deep-dive on Tanzu Application Platform’s OOTB Supply Chain
Each organization has a “path to production”; the process by which an application passes as it makes its way toward production. You can model this path as a supply chain with the Tanzu Application Platform (TAP). Under the hood, TAP delivers Supply Chain Choreography via Cartographer; which has a well defined domain model and abstractions for CI/CD choreography. It is the responsibility of the platform operator to identify and define the supply chain. Furthermore, the platform operator must also have available meaningful controllers to implement components of the supply chain.
Tanzu Application Platform bundles valuable components (e.g. Tekton and Supply Chain Security Tools) as well as OOTB templates and OOTB supply chains that delivery powerful capability. This kick-starts time to value, providing a reasonable starting point for your implementation. You can adopt these supply chains as your own, extend them, or simply use them as a reference as you customize your organization’s unique supply chain.
I was so excited to get my hands on Tanzu Application Platform 1.1 when it launched last week. TAP 1.1 introduced the multi-cluster deployment model and workflow visualization. I had been wanting to do a deep dive how the Out of the box Supply Chain with Testing and Scanning worked. More specifically how this worked in a multi-cluster TAP topology which leverages GitOps as demoed on the TAP YouTube channel.
Breaking Down the OOTB Supply Chain with Testing and Scanning
As I’ve discovered, there is a complex set actors that participate in the OOTB Supply Chain with Testing and Scanning, below is an over-simplified view of the input and outputs in the supply chain.
So how does the supply chain accomplish this? We can get insight into the supply chain using a new feature introduced in TAP 1.1. The TAP GUI Workload plugin provides a visualization of the resources of the supply chain and their current status.
Kubernetes Resources
How do I take this visualization and get a Kubernetes resource view of how it is composed? The Cartographer documentation provides a great explanation of the architecture and domain language for working with supply chains. I particularly liked the method of diagraming the supply chain templates and stamped resources. I used this approach to diagram the OOTB Supply Chain for Testing and Scanning.
I extended the diagram to include child resources of the stamped resources. This aligns with what you would see if you use the kubectl tree plugin to evaluate the workload resource. Here we see all the resources that are generated in the developer namespace when the developer applies a workload.
Supply Chain Participants
How about the components that provide the services within the supply chain? These services sub-packages of TAP and included when you deploy TAP with the “build” profile.
- Cartographer (and OOTB supply chains and OOTB templates)
- FluxCD
- Tekton
- Build Service
- Supply Chain Security Tools Scanning (and Supply Chain Security Tools Store)
- Convention Service (and App Live View and Spring Boot Convention Servers)
By exercising the supply chain with the sample Tanzu Java Web App and inspecting the resultant cluster resources and documentation, I created the following diagram and component explanation. I then added which role is responsible for the configuration of key resources, so that I could document the actions and use cases that govern the initial supply chain setup and execution and what I found to be even more interesting, the “day 2” events that may trigger a subsequent reconciliation of the supply chain. This is explained in my companion blog TAP OOTB Supply Chain with Testing and Scanning Events.
The following is an explanation of each component of the supply chain.
source-provider stamps a GitRepository via a ClusterSourceTemplate: Flux source controller clones git repo generates a tarball, storing it in the flux source controller artifact service.
deliverable stamps a Deliverable via a ClusterTemplate: This is a no-op action. Since the build service has no ClusterDelivery blueprints defined, there is no action taken on the Deliverable. This resource could be exported and applied to a “Run” cluster.
source-tester stamps a Runnable via a ClusterSourceTemplate: A Runnable is a wrapper around an immutable resource; in this case a Tekton PipelineRun resource. Cartographer’s templating process, sets teh PipelineRun’s spec properties for URL and revision to reference the tarball stored in the flux source controller artifact service from the GitRepository actions. The Cartographer runnable also references a ClusterRunTemplate. The stamped PipelineRun resource references a Tekton Pipeline that is expected to exist in the namespace. The name of the Pipeline is determined by the Runnable’s spec.selector references. Tekton reviews the specification of the Pipeline, identifies tasks and creates TaskRun resources which in-turn creates a pod to execute the task. Tekton updates status on the PipelineRun and TaskRun resources. The Runnable’s status is then updated as well.
source-scanner stamps a SourceScan via a ClusterSourceTemplate: The SourceScan refers to the blob URL for the tarball (which the GitRepository stored in the flux-source-controller), a ScanPolicy (named “scan-policy” that a an operator must create in the namespace) and a ScanTemplate (this refers to how the scan will execute). The ScanTemplate creates a K8s job that runs the Grype scanner on the source tarball, then runs any identified vulnerabilities found in the output against the ScanPolicy provided and finally updating the SourceScan status with results and if passed, a compliantArtifact url reference.
image-builder stamps an Image via a ClusterImageTemplate: The templating process provides URL of the source code tarball and the desired target to publish the image after a successful build. The target image location is based upon the OOTB supply chain package data values and the workload name.
image-scanner stamps an ImageScan via a ClusterImageTemplate: Similar to the source-scanner, there are references to the container image produced by the image-builder, a ScanPolicy created in the namespace by the platform operator, and a ScanTemplate, which in this case is a private-image-scan-template. The scan template describes a Job that will be created. The output of the job is the scan results, which the scanning controller evaluates based upon the policy and update status on the ImageScan.
config-provider stamps a PodIntent via a ClusterConfigTemplate: The PodIntent is a resource that would ultimately influence the pod specification of the running application. The Tanzu Convention Service has a controller that watches PodIntent resources and then integrates with Convention Servers based upon defined ClusterPodConventions within the platform. The “build” profile of TAP includes the App Live View and Spring Boot conventions. The controller orchestrates this processing via web hooks which update the PodIntent based on the contributions of the conventions. The status of the PodIntent will indicate which conventions were applied.
app-config stamps a ConfigMap via a ClusterConfigTemplate: The templating process generates a Knative Service resource and puts it in the delivery.yml ConfigMap key. If the workload referenced any bound services, then the ResourceClaim and ServiceBinding manifests are put in the ConfigMap’s serviceclaims.yml key.
config-writer stamps a Runnable via a ClusterTemplate: The Runnable defines a Tekton TaskRun which performs a git clone of the gitops repo, replaces the config directory with the app-config, commits and push’s the config to the remote.
Now you try
Now you get it right? The inner workings of the OOTB Supply Chain with Testing and Scanning have been revealed? No, I don’t expect that by reading this blog you would totally understand the processing. However, I hope it has piqued your interest and when you attempt to reason over how the supply chain works, troubleshoot a running supply chain, or seek to customize your own, you can refer to this as a valuable aide.
Please consider continuing on to read my companion blog TAP OOTB Supply Chain with Testing and Scanning Events to review what (and by whom) influence supply chain execution.
