VMware Tanzu Build Service, a Kubernetes-Native Way to Build Containers, Is Now GA

VMware Tanzu Build Service, a completely new way of building and managing application containers for Kubernetes, is now generally available. You can download an evaluation copy on Tanzu Network today and build your first container in just a few easy steps using our guide.

Although Kubernetes ushered in a new era of container-based applications with microservices architectures, the way that containers are built and maintained did not evolve much. But that becomes a problem when Kubernetes adoption scales rapidly, and the volume and velocity of container builds increase exponentially. So how do you make a container build system that was designed for individual developers or small teams work for thousands of containers?

Increasingly, the answer to that question is that you need a new system. Enter Tanzu Build Service, which represents a paradigm shift in the way developers package their applications into containers for Kubernetes, as well as how operators control the organization, security, and compliance of those containers. Rather than improving processes incrementally by automating your current tooling, Build Service takes a completely new and scalable approach to constructing the same OCI-compliant containers.

Kubernetes-native container building and management

Tanzu Build Service is a Kubernetes-native approach to building containers. It combines the proven buildpacks experience that Tanzu Application Service users know and love with a declarative image configuration model that creates and continuously updates OCI-compliant containers based on a desired state.

What does that mean for developers and operators? It means Build Service puts Kubernetes’ strengths to work for them. Developers no longer need to worry about creating, modifying, and patching container builds using Dockerfiles. Instead, they only need to define their desired app configuration once, and Tanzu Build Service maintains that desired state. Updates to any component of the application—from the code itself to dependencies to the operating system —no longer create unnecessary toil for developers.

Operators using Tanzu Build Service can centrally manage every aspect of the containers running in their infrastructure. They can control access to image configurations, enforce policy around dependencies, apply vulnerability remediation and OS patches, and inspect dependency versions and open source licenses for any container built by the system. They simply feed a continuous stream of image updates into a continuous delivery (CD) pipeline to be deployed to production, all without placing any additional burden on developers.

Enterprise capabilities built on an open source foundation 

Keeping with the spirit of cloud native software engineering, Tanzu Build Service is built on a foundation of open source software. By combining the strengths of community-supported open source projects with enterprise features and support delivered by VMware, Build Service manages to be greater than the sum of its parts. It leverages two open source projects as primary components:

1. kpack, Kubernetes-native image configuration – The kpack project, born in April 2019, extends the Kubernetes API to automatically build and maintain container images based on a declarative configuration specific to each application. Enterprise kpack capabilities introduced by Tanzu Build Service include a proprietary offline installation experience and a build webhook that enables the use of self-signed certificates. kpack, which consists of a set of custom resource definitions coordinated by custom controllers, is what makes the Tanzu Build Service approach Kubernetes-native. Learn more about kpack.

2. Buildpacks for VMware Tanzu – Tanzu Buildpacks are based on an open source implementation of the Cloud Native Buildpacks spec called Paketo Cloud Native Buildpacks. Tanzu Buildpacks are controlled by kpack, which uses image configurations to centrally manage building and updating container images from source code (or compiled binaries if preferred, for languages like Java or Golang). Each Tanzu Buildpack is capable of building container images for a single language runtime. Buildpacks for VMware Tanzu add to Paketo Buildpack functionality with the ability to build containers in offline environments.

   Buildpacks for VMware Tanzu construct containers modularly, so individual layers can be updated without affecting the others. Each container has extensive metadata about which libraries and binaries are in the stack and which open source licenses they are subject to. This vastly simplifies container dependency and OS patching for developers and operators. It removes the need to track dependencies individually for thousands of Docker containers with varying patch levels.

   Tanzu Build Service will ship initially with Java, Node.js, and Golang Buildpacks for VMware Tanzu, as well as a number of beta buildpacks. Tanzu Build Service customers can also leverage open source Paketo Buildpacks. Learn more about buildpacks for VMware Tanzu.

In addition to kpack and buildpacks for VMware Tanzu, Tanzu Build Service packages a number of other open source resources that enable IT teams to centrally manage their organizations’ container building and maintenance.

• The ClusterStack resource manages base operating system images that are used with the buildpacks for VMware Tanzu to create your containers. Organizations leverage the stack resource to enforce IT policies around which security settings and customizations are applied at the operating system level for containers. You can rely on a curated stack maintained by VMware using best practices, or you can bring your own base images.

• The ClusterStore resource enables IT operators to define a collection of buildpacks that are available for building and updating containers. As buildpack updates are continuously published to Tanzu Network, the ClusterStore is refreshed with the latest versions so that container updates can be triggered. Buildpacks for VMware Tanzu also support ISV integrations and environments through the ClusterStore. Admins can control which buildpacks in the store are accessible to which groups of developers, and create and consume their own custom buildpacks, through this resource.

• The Builder resource combines the ClusterStack and ClusterStore resources. It defines which combination of build and run images are available for use with which buildpacks, and permits the builder author to scope the resource at the cluster or namespace level. 

• The kp CLI, which is downloaded together with Tanzu Build Service, enables interaction with it through the command line. It accesses whatever Kubeconfig is actively being used by kubectl to streamline RBAC. The kp CLI can be used to both update and manage Tanzu Build Service resources and to define, build, and update application containers with Build Service. Check out the kp CLI on GitHub. 

After downloading a Stack update, a container operating system is updated with the kp clusterstack update command

Tanzu Build Service can be installed in any Kubernetes cluster. Once you have completed installation, all of these resources are ready to be leveraged together with kpack and Tanzu Buildpacks to provide a streamlined, simplified process of constructing and managing the containers that will be deployed into your production Kubernetes clusters. 

Tanzu Build Service: Coming to a CI/CD pipeline near you

Tanzu Build Service is designed to be an integral part of the pipeline that developers and operators use to transform ideas into applications running in production. Let’s look at where it fits into a CI/CD pipeline.

Not all pipelines are configured the same way. Many customers will not want this level of automation, and will choose instead to evaluate whether they would like to deploy each update based on myriad factors in their environment.

There are three events that can prompt Tanzu Build Service to trigger an update to an application container.

1. A developer pushes a code commit to Git – The change is detected by a CI tool such as Jenkins (let’s assume we are building images directly from source, and not from compiled binaries). Jenkins runs a series of tests on the updated code. Once those tests are complete, Jenkins executes a kpack build command that triggers a new container image to be built. This image is deposited into Harbor.

2. An updated buildpack is released – Jenkins is monitoring the relevant buildpack for VMware Tanzu tiles for updates. Jenkins downloads the updated buildpack and adds it to the ClusterStore. Jenkins then executes a kpack image build, which updates any dependencies in the container that have been patched since the last build. This image is deposited into Harbor.

3. An operating system update is released – Jenkins, which is monitoring the OS version in the Tanzu dependencies tile in Tanzu Network, downloads the update and adds it to the ClusterStack. Jenkins then triggers a kpack image build that updates the operating system version in the image. The updated container is deposited into Harbor.

As you can see, an update to any layer in a container triggers a new build that is then added to Harbor. From there, the container revision update can trigger Jenkins (now in a CD capacity) to automatically run a variety of acceptance tests in a Kubernetes test cluster. When these tests have all passed “green,” an operator may get a notice to manually approve deploying the update in production. Once this happens, the new container replaces all copies of the old one in production through a rolling update.

Notice that the only manual interventions required during that entire process were for the developer to push code and an IT operator to approve the very last step of deploying a container update to production. This hypothetical example of a fully automated pipeline is just one example of how Tanzu Build Service is able to feed a continuous stream of images into CD systems. Security patches to dependencies and operating systems as well as changes to the application itself are continuously pushed to production as quickly as possible.

While this scenario demonstrates how Tanzu Build Service could be used to achieve maximum automation as part of a CI/CD pipeline, many organizations instead choose which updates are applied to their containers as they become available. Build Service is flexible enough to accommodate either strategy, or anything in between.

Get started

So you’ve learned a little bit about Tanzu Build Service, and it sounds great. What are you waiting for!? Get out there and get your feet wet!

Here are some more resources to get you on your way.

• In the Tanzu practitioner blog, you can find an excellent guide written by Tony Vetter that will help you get up and running with Tanzu Build Service on your friendly local K8s cluster in no time.

• Read our comprehensive documentation.

• Download an evaluation copy of Tanzu Build Service.