A powerful capability of Tanzu Application Platform is the tight integration of the ‘app development cycle’, sometimes called the ‘inner loop’. TAP allows a developer directly test the app on a Kubernetes cluster and changes to source code can be deployed in seconds to the running instance (on Kubernetes) of the app. This feature is called Live Update and is part of the Tanzu Developer Tools (available for Visual Studio Code, Visual Studio and IntelliJ).

To get started with the Live Update feature, you will need the Tanzu Developer Tools. The prerequisites for the Tanzu Developer Tools are:

• Visual Studio Code (or IntelliJ) – Tanzu Developer Tools are installed as a extension in your IDE.
• kubectl
• Tilt v0.30.12 or later
• Tanzu CLI and plug-ins
• A cluster with the Tanzu Application Platform Full profile or Iterate profile

This blogpost is focussing on Visual Studio Code as the IDE of choice.

You can install the Tanzu Developer Tools:

• By downloading the plugin from Tanzu Developer Network.
• Install the extension directly from the Marketplace in VSC.

There are a few settings you need to configure. The most important ones are:

• Tanzu Application Platform Gui URL – This is the URL of your TAP installation and used to display the TAP accelerators directly in your IDE (not required for Live Update).
• Namespace – This is the namespace where you deploy your workloads to as a developer. This namespace should be configured according to what is described here.
• Source Image – This is the registry location where the local source code of your app is stored. This location is accessed by your local workstation to push the source code, while TAP needs to access this location to pull your code (to build your app).
• Tracked Namespaces – This setting allows you to enter different namespaces that should be monitored by your IDE, these namespaces will appear in the Workload/Activity panel.

Regarding the Source Image setting, this might be experienced as a bit confusing in the beginning. This setting determines which repository (on which registry) the source code created by the developer will be stored, so TAP can consume the source code and build the live instance of the app. This registry can be the same or a different instance of a registry then TAP is already using. It’s important that both the workstation of the developer and the TAP instance used for the inner loop has access to this registry. This is illustrated in the following diagram:

The developer stores the source code in “registry 1” (named local source code in the diagram), the TAP Cartographer Supply Chain pulls the source code from this repository and builds the container that is stored in “registry 2” (named container(s) in the diagram). Then the K8S artifact(s) are build (including required service bindings of applicable), this is stored on a Git repository. Then the Delivery workflows pulls the K8S artifacts are pulled from Git, and the actual container is pulled from “registry 2”.

Access to “repository 1” in the developer environment should be managed through a Docker login command (called a source image registry in the documentation), or by using the Local Source Proxy option. I will focus on the second option in this blogpost, because it’s more scalable and it doesn’t require to share registry credentials with your developers.

Configure Local Source Proxy

The configuration of the Local Source Proxy is done through the tap-values.yaml file and the creation of an (additional) registry secret (to access “registry 1”). Check out this tap-values example file to get an idea what you need to configure.

On top of this you also have to configure two Secrets and SecretExports as defined here.

The secrets are automatically created when you change create_export to true in the tap-values.yaml, however I faced some unexpected behavior with the distribution of the secrets. The idea is that the lsp-push-credentials secret is available to the Local Source Proxy capability, so the developer is able to push local source code to the repository (without needing/knowing the credentials for this repository). The lsp-pull-credentials secret is used by TAP to pull the source code from the registry and start building the application. The lsp-pull-credentials secret will be (or needs to be) distributed across your developer namespaces. If you’re using the Namespace Provisioner capability of TAP (highly recommended) this is done automatically.

Before we apply the update in the tap-values.yaml, we need to create the two secrets in the tap-install namespace. You can create/use a YAML for this, or just use the Tanzu CLI to create the registry secrets.

tanzu secret registry add lsp-pull-credentials --username <username> --password <password> --server <registry-url> --namespace tap-install --yes

and

tanzu secret registry add lsp-push-credentials --username <username> --password <password> --server <registry-url> --namespace tap-install --yes

Now update your TAP installation bij executing:

tanzu package installed update tap -p tap.tanzu.vmware.com -v $TAP_VERSION --values-file tap-values.yaml -n tap-install

Now wait until the packages reconciles, this shouldn’t take too long.

Now verify if the Local Source Proxy is configured correctly:

tanzu apps lsp health

This command should be executed in a developer namespace on a cluster that is running TAP.

It’s now time to test everything, the good old “Tanzu Java WebApp” is a perfect candidate and is by default available as an accelerator in the TAP catalog. The only thing is that you need to do a minor update to the tilfFile that comes with the app: remove the line with  ” –source-image ” + SOURCE_IMAGE + from the tiltFile.

The local-source-proxy mechanism is completely bypassed if either of the following is true: the –source-image flag is provided or the workload has a defined source image that Local Source Proxy didn’t set (source).

An updated tiltFile is available here.

Do a live update

Now give the whole process a try, open your app in VSC, hit CMD-Shift-P and Choose Tanzu Live Update Start. Visual Studio Code will give you details on what’s going on:

Harbor shows the local source code first being pushed by the robot@svc_tap account (the account that’s in the lsp-push-credentials secret, this is used by LSP), and then being pulled by robot$svc_tap_readonly (available in lsp-pull-credentials secret):

And of course you can follow the whole process in the TAP Developer Portal:

An update to the app (by the developer) will update the running Kubernetes instance instantly, a new version of your app will be available within 10-15 seconds.

That’s it for now. I hope this was useful.