Effective (and enjoyable) development should feel like you are having a conversation with your computer. Apply a small change, and see the results. Did that function do what you thought it would? Any unintended consequences? Making these small, iterative changes—when you can quickly see the results—can make your code more elegant, less buggy, and more in line with the intention of any given feature.
To enable such effectiveness, many developers turn to local development paradigms. Pushing changes to an organization’s main branch kicks off heavy-handed integration tests, packaging, and in some cases, even a full deployment. But when it comes to the task of changing code, a shorter iteration cycle is needed, one in which the developer “conversation” can be synchronous and verbose.
Technologies like Docker and Kubernetes enable this fast, iterative cycle. And applications packaged in containers allow for a plethora of automation options when it comes to deploying code. In this post, we will look at how you can move faster and more effectively with VMware Tanzu Build Service inserted into such a local development cycle. Tanzu Build Service will monitor your development branch and automatically build your containers with every push. Then it will upload that container to your image registry for you to pull down and run locally.
First, you will use Docker Desktop to spin up a small Kubernetes cluster on which you will install a local copy of Tanzu Build Service. Then you will configure Tanzu Build Service to monitor a branch in GitHub. You will then integrate Tanzu Build Service with Docker Hub, which it will use as a repository to store the images Tanzu Build Service builds. With this configuration, whenever a change is pushed to your configured branch, Tanzu Build Service will pick up that change, build the new image, give it a distinct tag (as well as tag it “latest”), and push it to your registry. You’ll then be able to pull that
image:tag combination and see how your change impacts things overall before pushing it to a main branch.
Let’s get started.
Note: At the time of this writing, Tanzu Build Service is currently in version 0.2.0, and is in beta. This space is rapidly changing, and bugs are inevitable. The Tanzu Build Service engineering team is working diligently to enhance features and fix issues. This guide is not a solution meant for production use cases (yet).
Before you get started, you’ll need to do the following:
Create a Docker Hub account: This is where Tanzu Build Service will push your built images for you to pull down and run. It is also where you will push your Tanzu Build Service build images during the install process.
Install the Pivnet CLI: This CLI offers an easy way to download applications and bundles from the VMware Tanzu Marketplace, straight from the command line, without worrying about passing credentials in curl headers. If you would prefer you can modify commands used in this post to use curl, wget, or similar.
Install the kubectl CLI: You will use this CLI to manage your Kubernetes environment. Tanzu Build Service also uses your Kubernetes config file to connect and authenticate with your local cluster.
Install Duffle (preferably from the VMware Tanzu Network): Duffle is an application for installing and managing distributed applications like Tanzu Build Service. You will use it here to push the Tanzu Build Service installation image to your registry, as well as install Tanzu Build Service onto Kubernetes. The version from the Tanzu Network is preferred for this project since it is tested with the Tanzu Build Service version deployed.
Download the Tanzu Build Service bundle
Tanzu Build Service is hosted on the VMware Tanzu Network. You will need access to this network as a customer to download Tanzu Build Service and the associated client tooling. This command will download Tanzu Build Service version 0.2.0 into your local directory. Download commands for other releases can be found on the VMware Tanzu Network.
Create the Kubernetes cluster
This is where you will install Tanzu Build Service. To create a local Kubernetes cluster using Docker Desktop, follow this guide from Docker. The process is straightforward:
Docker Desktop > Preferences > Kubernetes > Check “Enable Kubernetes” > Apply & Restart
Kubernetes running on Docker Desktop provides an easy way to get started with Kubernetes, as well as a way to reset your cluster to “defaults” should something go awry. Creating this cluster will also create a Kubernetes config file in
kubectl and Tanzu Build Service will use to interact with your new cluster.
Next, switch your kubectl context to your local cluster.
And verify the cluster is working properly.
Create the Tanzu Build Service credentials file
The credentials file tells Tanzu Build Service where your Kubernetes config file is in order to connect. Because we are deploying locally, we can keep the
ca_cert information blank.
Copy and paste the following block into your terminal. Modify the path attribute for your kube config file. This will create the necessary credentials file.
Push the Tanzu Build Service bundle to Docker Hub
The bundle you downloaded earlier contains many images for the buildpack runtime packages Tanzu Build Service will use to build your images. It also contains the install image for Tanzu Build Service. For Tanzu Build Service to have access to these images, they need to be pushed to your image registry.
Note: These steps will create many separate image registries within your Docker Hub account—one for each buildpack image, as well as one for the install image. More on these in the next step. You may consider using a separate Docker Hub account for this project, as these image registries might clutter your interface.
First, log in to your Docker Hub account. This command will ask you for your username and password.
Then use Duffle to push the bundle to the repo. This command will take some time to complete; depending on your internet connection, it should take anywhere from 5-10 minutes. Modify this account with your own account name.
-m flag allows for a JSON-formatted output file we will use later to tell TBS where each image is located.
Install Tanzu Build Service
Now it’s time to install Tanzu Build Service to your local Kubernetes cluster. This command will utilize many of the environment variables we previously defined.
In addition, you can change the install name from
tbs-deploy-demo to something that makes more sense for your use case. The
kubernetes_env attribute is the name of your Kubernetes cluster. If you’re following these steps the name is likely
docker-desktop, but running
kubectl config get-clusters will give you a list of your clusters. Then change the
docker_repository attribute for your username and set the credentials.
Again, this will take a couple of minutes, but not as long as it took to push the images to Docker Hub.
Note: While this guide is for setting everything up yourself, it is worth noting what the responsibilities of different roles within an organization would be if this were a production use case. Ordinarily, an operations team would be setting up and managing the Tanzu Build Service cluster environment, managing the cluster credentials and buildpack images, and generally doing all of the steps you just completed.
Everything that follows would typically be done by a developer. They would simply install and connect the Tanzu Build Service client application, kp (or more appropriately, script the install as part of setting up a developer environment), and set up the automated build flow.
The local CLI tool, kp, is used for interacting with your Tanzu Build Service installation. It can be downloaded from the VMware Tanzu Network for your platform here. The following commands are specific to macOS. Modify them as needed for other platforms.
To download the binary for macOS, use the following
pivnet command. Go to the Tanzu Build Service bundle in the VMware Tanzu Network to find versions for other platforms.
Once downloaded, rename the binary.
Make the binary executable.
And move it into your local
Verify the installation of your Tanzu Build Service server and kp client by running a command to list the default stacks that ship with Tanzu Build Service.
Access the example application
Before Tanzu Build Service can build a container image for us, we need an application for it to build. In this project, the application we are using is called spring-petclinic. This is a simple example of an application that would be used to manage a veterinary hospital. It is relatively easy to understand and make changes to as you experiment.
You can use the spring-projects repository version to do a one-time build and test of Tanzu Build Service. But this method will not allow you to see the automated build functionality when a new commit it pushed to the repo. To test the automated build functionality on Tanzu Build Service, you will need to fork this repository into your own. You can also use a different image entirely. In this case, just be sure to modify the rest of the commands in this guide to suit your needs. All of the following commands will assume you have forked this repository into your own account.
Forking is done through the GitHub GUI. A guide for how to do that can be found here.
Tanzu Build Service will need to talk to your version control system and your image registry. In this guide, you are configuring Tanzu Build Service with GitHub and Docker Hub. To do this, you need to pass these credentials to Tanzu Build Service using the
kp secret command.
First, create a secret for your Docker Hub account. Be sure to modify the following command by adding your Docker Hub username. The following will prompt you for your Docker Hub password.
Next, create the secret for your GitHub account. Again, modify this command to add your username.
Alternatively, you can create a secret based on SSH key access. Either method will work for this use case.
Configure an image
So now our Tanzu Build Service project knows about the two systems it needs to talk to. The last step is to tell Tanzu Build Service about the code we want to monitor and build.
With this next command, we are telling Tanzu Build Service where to retrieve the source code. Tanzu Build Service will be configured to watch the master branch by default, but you can configure it to watch your own development branch for whatever feature or bug you happen to be working on. Finally, the tag is where the image will be pushed in your registry. Modify this file to address your own image.
Once the image configuration has been applied, Tanzu Build Service will scan the repo and start building your image. You can see this happening by running the pb command below to list all of the builds associated with an image tag.
Once completed, Tanzu Build Service will put a copy of the image into your Docker Hub registry, as well as a copy on your local Kubernetes cluster within the default namespace (this is configurable). From there, you can run the image locally and see any changes you push to your registry.
This command runs the container and forwards the local port 8080 to the container port 8080.
Then open a browser window with the URL http://localhost:8080
Next, try making a change to the source code and pushing it to the branch your Tanzu Build Service project is configured to watch. Tanzu Build Service will pick up the change automatically, build a new container, and push it to your registry!
All of this automation applies to your base “run” image, too. As new updates and critical security vulnerabilities are patched, Tanzu Build Service will pick up those changes and rebuild and redeploy all of your containers. This is a very powerful feature of Tanzu Build Service, one that helps keep your customers, and your business, safe from vulnerabilities.
If you would like to dive deeper into VMware Tanzu Build Service, check out the documentation section. And make sure to let us know how the beta* is going!
*Note there is no commitment or obligation that beta features will become generally available.
This article may contain hyperlinks to non-VMware websites that are created and maintained by third parties who are solely responsible for the content on such websites.
About the AuthorMore Content by Tony Vetter