I am maintaining a set of scripts that I use to deploy Tanzu Application Platform to (test) environment. With the recent release of TAP 1.5, it’s time again to update and re-evaluate my scripts:
- Make the scripts compatible with TAP 1.5.
- Add TLS support for TAP-GUI.
- Configure a working setup for a the testing & scanning out-of-the-box (OOTB) supply chain.
The TLS support part and some parts of the testing & scanning workflow are coming from my highly valued colleague Robert Jensen and now part of my deployment flow.
The script is designed to work on MacOS and Linux. Before you get started with the scripts, it’s important you download the latest version (1.5) of Tanzu CLI (MacOS or Linux version) and Tanzu Clusters Essentials (MacOS or Linux version) from Tanzu Network. You also have to accept the EULAs, if you haven’t accepted them before. Check out all the pre-requisites in the VMware documentation.
Put the downloaded files in the same directory as you have downloaded/cloned the scripts. Make sure you have a Kubernetes cluster available that meets the requirementes, e.g.:
- Kubernetes version 1.24-1.26
- 100 GB (!) diskspace available per node
- At least 8 GB RAM per node and 16 vCPUs available in total
- Full details here.
Now clone the scripts:
git clone https://github.com/viktoriousss/tap-installation.git
Now start with editing 00-set-environment-variables.sh, this file contains some required information to successfully use the scripts. Most important settings are:
- Tanzu net login details, required for downloading the software.
- Private registry configuration, required for installing and running TAP.
- Postgress database configuration, for database deployment. You need to configure these settings in the tap-values.yaml at a later stage as well.
- Dockerhub configuration, only required if you’re using the testing or testing_scanning OOTB supply chain.
- Set version information for Tanzu CLI and Tanzu Cluster Essentials.
Now source this file:
source 00-set-environment-variable.sh
Remove existing Tanzu CLI (optional) and install the updated Tanzu CLI. If you’re already running Tanzu CLI v0.28.1 (TKGm 2.1) you don’t have to remove the existing Tanzu CLI.
./01-remove-tanzu-cli.sh ./02-install-tanzu-cli.sh
Install cluster essentials if you’re using vSphere /w Tanzu on vSphere 7, or a non-TKG Kubernetes cluster (ergo, if you’re running TKGm or vSphere /w Tanzu on vSphere 8, you don’t have to install cluster essentials).
./03-deploy-cluster-essentials.sh
Now copy the TAP installation files from Tanzu Network to your own registry, this process will take some time depending on your internet connection.
./04-relocate-images-to-registry.sh
Add the repo to your cluster. Make sure the K8S cluster you want to deploy to is active:
./05-add-repo-to-cluster.sh
Create a some namespaces and configure them to be used in TAP. Note: the script is still using the legacy developer namespace configuration, I’m working on using the Namespace Provisioner methodology.
./06-configure-namespaces.sh
Installing the database is the next step:
./07-install-database.sh
In the next step we’re going to install TAP. Before you can proceed, you have to configure tap-values.yaml. This file contains almost all the settings for your TAP installation. The comments in the file explain what is expected. Wait till the postgress DB pod is up and running before continuing with the next step:
kubectl get pods -n postgresql -w
Now install TAP:
./08-install-tap.sh
The installation will take around 10-15 minutes. You can monitor the installation using script 97:
./97-monitor-tap-installation.sh
Some post configuration steps are required for grype, for now the result you’re looking for is:
kubectl get packageinstalls.packaging.carvel.dev -n tap-install
kubectl get service -A
Setup an TLS certificate for tap-gui
The tap-values.yaml already contains the required configuration to use a TLS certificate:
The certificate is stored in a secret called tap-gui in namespace cert-manager. As an example I’ve included the steps to create a certificate using Let’s Encrypt and AWS Route 53. Also read this blogpost to get a better understanding how the Route53 Let’s Encrypt works. Configure your own Cert-Manager Cluster Issuer, change tap-gui-certificate.yaml so it’s linked to your cluster issuer and then request the certificate.
Check if the certificate is available using:
kubectl get secret -n cert-manager
You’re looking for:
After the setup is available, it will automatically be used by tap-gui. This is reflected by a secure connection to your tap-gui interface (https://tap-gui.yourdomain.com).
You can also use:
./09-tap-configure-tls.sh
Basic setup of Tekton
For the testing part of the testing & scanning OOTB workflow, Tekton is used. Tekton is also used if you’re using the testing OOTB workflow. You need to have a testing configuration in place, otherwise your workflow will fail. I’ve included some YAML examples on how to setup Tekton on GitHub.
The YAML definitions contains a Tekton Pipeline that will be executed as part of the Testing & Scanning OOTB workflow (to be more specific, testing in this case).
The Pipeline is selected in the TAP Supply Chain based on the label, for example the label
apps.tanzu.vmware.com/language: java
in the java-test-pipeline.yaml is also configured in the workload.yaml of the nl-tanzu-java-web-app testing application.
You can also use:
./10-add-tekton-testing.sh
Basic setup of Grype scanning policy + metadata store configuration
If you’re using the testing_scanning OOTB workflow,you need to setup a basis scanning policy that is applicable to the workloads you’re running on TAP. An example Grype scanning policy is available on Github. Apply this YAML file to your TAP cluster to get started. It’s out of scope of this blogpost to discuss the exact configuration parameters.
Then as a next step, you have to execute a post-configuration step for the metadata store component.
I’ve included the YAML configuration for this on GitHub. You have to apply this YAML file to your TAP installation:
kubectl apply -f metadata-store-sa.yaml
The next step is to retrieve a bearer token, that should be added to your tap-values.yaml file:
kubectl get secrets metadata-store-read-client -n metadata-store -o jsonpath="{.data.token}" | base64 -d
Update your tap-values.yaml (leave the word Bearer in place, update the token with your token retrieved from the previous step):
proxy: /metadata-store: target: https://metadata-store-app.metadata-store:8443/api/v1 changeOrigin: true secure: false headers: Authorization: "Bearer eyJhbGciOiJSUzI1NiIsImtpZCI6IktaVV9MUFNkV3ptRmtYbG1vdktjMklhUkpVZnY0b1UwaWRwM1RCQlpZTkUifQ.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2UiOiJtZXRhZGF0YS1zdG9yZSIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VjcmV0Lm5hbWUiOiJtZXRhZGF0YS1zdG9yZS1yZWFkLWNsaWVudCIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VydmljZS1hY2NvdW50Lm5hbWUiOiJtZXRhZGF0YS1zdG9yZS1yZWFkLWNsaWVudCIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VydmljZS1hY2NvdW50LnVpZCI6IjJlNDY4YThkLTBlNzEtNDUyNi05ZGMxLTQxY2U2MzlkZTVlZSIsInN1YiI6InN5c3RlbTpzZXJ2aWNlYWNjb3VudDptZXRhZGF0YS1zdG9yZTptZXRhZGF0YS1zdG9yZS1yZWFkLWNsaWVudCJ9.FwtOvG7AHuatebyCE7XeakyUj8rNAaTn1AgesTBz8E1aRiLFWjKNygiwio6CQ-bVRoEBtUFNwGE8g1bz_Gwjr8fi_bzi8tvoxwP0BIHvnBvZjQdiHO1ANbhTtnxd33HQcmmfbu0Wd7DSRYd3y-bTOOyCIx1fjgZzW8svjKujWwpBwVB-iN5Tb_CKKwqR98_XXm0GNlErCWJRUO4iPtTSeC2Qzsxjg_YL7GQBOvLMw_84_S1pXh7u0lrNNhbcWGCoWen9O0KRjloiciwkom6SwBNQMLQNGJkb7ZoSIjvQxSWa9IND6a1A77lPS8r6j86j5bc7SAJzQX0ywtqyFSE4Bw" X-Custom-Source: project-star
You can also use:
./11-configure-scanning-policy.sh
Now update your TAP installation using script
./98-update-tap.sh
More information about this procedure is available on https://captainvirtualization.com/tap-metadatastore-error/.
You’re now ready to on-board workloads to TAP, good luck!