buildpacks containers devops kubernetes pivotal products Tanzu Build Service

Pivotal Build Service, Now VMware Tanzu Build Service, Assembles and Updates Containers in Kubernetes

Who doesn’t love a good Dockerfile? They are powerful and offer an easy, developer-friendly solution to several common scenarios. Yet they can require a lot of knowledge to construct properly. And security and operational rigor can be hard to enforce at scale.

The ideal way to get your source code into a container would keep the convenience of a Dockerfile, and remove human intervention over the development lifecycle. It would work on Day 1 and Day 2. This is the thinking behind Pivotal Build Service, now in alpha.

Build Service is a declarative way to build an OCI-compatible container image from source code. Push your code to the Service, and it will instantly produce an OCI image suitable for any compatible runtime. Today, the Build Service alpha supports Enterprise PKS, Pivotal, and VMware’s Kubernetes product.

Build Service picks up where the Dockerfile workflow leaves off, because it’s:

  • Simple. With Build Service, you don’t need any advanced knowledge of Dockerfiles, or how to optimally construct a Dockerfile for a given programming language.

  • Fast. The Build Service workflow uses caching extensively and minimizes data transfer.

  • Secure. Utilizes the security and compliance benefits of buildpacks.

  • Automated.  Most importantly, Build Service follows a K8s native declarative model and executes builds against a user-defined configuration.    

This should sound familiar to long-time Pivotal customers. Build Service utilizes an evolution of the buildpacks concept that’s been core to Pivotal Cloud Foundry for years.

 

Build Service Evolves Buildpacks for the Kubernetes Era

Enterprises have used buildpacks millions of times (literally) to transform source code into containers. Buildpacks have been an integral part of the Cloud Foundry app staging process since 2013. Why do these companies like buildpacks so much? Three reasons:

  • Buildpacks support the most common enterprise frameworks and runtimes. It supports the tech your developers know and love.

  • Buildpacks increase developer productivity. Your engineers don’t have to fiddle with dependency management and other toil.

  • Buildpacks boost security and minimize risk. Platform teams and InfoSec pros can easily control the supported versions of a given framework. In the event of a CVE, it’s easy to assess risk. Mitigating that vulnerability is just as straightforward. Just update the buildpack, then redeploy your apps with the new bits.

These benefits still resonate today, and Build Service brings them to your Kubernetes deployments.

Build Service has its roots in open source, with Cloud Native Buildpacks (CNBs).

 

Cloud Native Buildpacks Bring Automation to More Runtimes

We teamed up with Heroku to evolve the buildpacks concept and to bring this proven automation to even more runtimes. The Cloud Native Buildpacks (CNB) project was born!

The CNB project seeks to: 

  • Adapt the proven standard of buildpacks to the world of containers.

  • Unify the buildpack ecosystem through a defined platform-to-buildpack contract.

  • Provide the community the tools it needs to create new CNBs and apply them to source code.

So far, so good! Today, Cloud Native Buildpacks embrace the OCI standard for broad applicability. Its entrance into the CNCF speaks to its interoperability, too.

CNBs offer greater modularity compared to traditional buildpacks, meaning operators gain more control over what’s in any given buildpack. For developers, CNBs build a lot faster. And they run in local dev environments to speed troubleshooting.

That’s the open-source story. But enterprise IT departments need something more in order to responsibly use Cloud Native Buildpacks in production for their most important apps.

 

Build Service Adds Essential Enterprise Automation and Control

Buildpacks have always delivered developer productivity and greater security and control. That’s still true with Cloud Native Buildpacks, even though the specifics of risk mitigation fall outside the scope of the open source project. That’s where Build Service comes in.

The service provides the layer of automation and operational control enterprises need to utilize Cloud Native Buildpacks at scale. In particular, Build Service includes three key capabilities: automated image updates, image promotion, and build configurations.

 

Automated Image Updates Keep Configuration in Sync

The Build Service is based on a declarative configuration model. Once you create an image configuration, the service will then constantly build against it to resolve discrepancies between the declared config and what’s actually running in your systems.

When new buildpack versions are released, or OS packages are patched, Build Service knows about them. As a result, it automatically rebuilds the outdated layers within your apps to include the new bits.

With Build Service, your container images are always consistent and up to date. No more snowflake containers!

 

Smart Image Promotion Across Environments Improves Your Security Posture

New buildpack versions tend to hit weekly. They include the security patches you need to care about. Build Service makes sure that all your container images automatically reflect these patches with a nifty image promotion capability. Here how it works.

  • Builds created by the service produce an image that’s hosted in your chosen registry. Another output is a reference to said image that includes a unique image digest.

  • This reference can be promoted between application environments (dev, test, prod) using CD tools such as Spinnaker.

This reference works in conjunction with the aforementioned “automated image update” capability to easily apply new security patches to your containers, wherever they happen to be running. CNBs provide a consistent, reproducible, and traceable build process. Build Service keeps dependency layers up to date. The end result: You can trust the service to provide a stream of images that automatically includes security patches as they are released! 

 

Operators Have Greater Control Over “Who Can Do What”

Consider the position of an enterprise platform operator.  They don’t want to hinder the productivity of app development teams, but they also want to make sure that these apps are built with compliant dependencies.  This is why the Build Service will offer “build configurations.” Using this feature, operators will be able to govern how buildpacks are used across their organization and enable app developers to spend more time focused on writing source code.

Let’s consider a real-world scenario.  Imagine you want to use an APM tool like Dynatrace to but just for compatible Node.js apps. Your build config workflow would look like this:

$ pb login -a api.cf.example.com # as admin
$ pb buildpack upload myapm-1.0.3.cnb
$ pb builder get harbor.example.com/dev-builder -o builder.yml
$ vim builder.yml

image:
  tag: harbor.example.com/dev-builder
  team: frontend-team
order:
  - group:
    - id: com.example.apm
    - id: org.cloudfoundry.ruby
  - group:
    - id: com.example.apm
    - id: org.cloudfoundry.nodejs
      version: v1.2.3
  - group:
    - id: org.cloudfoundry.python
  - group:
    - id: org.cloudfoundry.openjdk-custom
    - id: org.cloudfoundry.build-system
      version_from: org.cloudfoundry.java
    - id: org.cloudfoundry.jvm-app
      version_from: org.cloudfoundry.java

$ pb builder apply -f builder.yml

Here’s What You Can Expect From the Build Service Alpha

So what can you do with Build Service at this stage? Plenty! First, let’s cover what you’ll need.

Prerequisites

Enterprise PKS customers can consume Build Service releases and accompanying artifacts through the product’s Pivnet tile.  Platform operators can download these bits as application packages that adhere to the CNAB spec called “bundles.”  Build Service will provide:

  1. A bundle containing Build Service images—including a CLI to control the product called “Pivotal Build” (`pb`), and a “Builder Image” the product will utilize to execute builds

  2. A bundle containing “Duffle”,  a CLI used to interact with bundles

Platform operators will use Duffle to install Build Service on a K8s cluster.  Users can target this cluster and login to Build Service using their UAA credentials.  

Top Features

  • You will interact with Build Service through the ‘pb’ CLI.

  • The alpha ships with the concept of “teams” to provide multi-tenant access control to image configurations. (Kubernetes doesn’t have an opinion on this.)

  • Build Service will rebuild against image configurations it knows about, upon detection of new versions of buildpacks. 

Build Service Helps You Get More From Containers and Kubernetes

Dockerfiles and Kubernetes are wonderful starting points for your cloud journey. Whatever your destination, you need productive developers and operational rigor to help you get there. Build Service, gives your engineering teams a boost by automating more of the container lifecycle. And that means better business outcomes!

Speaking of outcomes, give Pivotal tech a spin: 

SAFE HARBOR STATEMENT

This blog contains statements relating to Pivotal’s expectations, projections, beliefs, and prospects which are "forward-looking statements” and by their nature are uncertain. Words such as "believe," "may," "will," "estimate," "continue," "anticipate," "intend," "expect," "plans," and similar expressions are intended to identify forward-looking statements. Such forward-looking statements are not guarantees of future performance, and you are cautioned not to place undue reliance on these forward-looking statements. Actual results could differ materially from those projected in the forward-looking statements as a result of many factors. All information set forth in this blog is current as of the date of this blog. These forward-looking statements are based on current expectations and are subject to uncertainties, risks, assumptions, and changes in condition, significance, value and effect as well as other risks disclosed previously and from time to time by us. Additional information we disclose could cause actual results to vary from expectations. Pivotal disclaims any obligation to, and does not currently intend to, update any such forward-looking statements, whether written or oral, that may be made from time to time except as required by law.

This blog also contains statements which are intended to outline the general direction of certain of Pivotal's offerings. It is intended for information purposes only and may not be incorporated into any contract.  Any information regarding the pre-release of Pivotal offerings, future updates or other planned modifications is subject to ongoing evaluation by Pivotal and is subject to change. All software releases are on an “if and when available” basis and are subject to change. This information is provided without warranty or any kind, express or implied, and is not a commitment to deliver any material, code, or functionality, and should not be relied upon in making purchasing decisions regarding Pivotal's offerings. Any purchasing decisions should only be based on features currently available.  The development, release, and timing of any features or functionality described for Pivotal's offerings in this blog remain at the sole discretion of Pivotal. Pivotal has no obligation to update forward-looking information in this blog.

Kubernetes is either a registered trademark or trademark of The Linux Foundation in the United States and/or other countries. Other names may be trademarks of their respective owners.

 

Related Articles