build service buildpacks containers docker java_buildpack kubernetes products Tanzu Build Service

When Building Containers from Source Code, Repeatability is Key. Pivotal Build Service is Here to Help.

We announced the alpha of Pivotal Build Service a few months back. A new version of this alpha adds several new capabilities. This post describes these capabilities.

Dockerfiles are everywhere. Some developers swear by them, while others swear at them. But there's one thing we can all agree on: the reliance on Dockerfiles at scale can be a significant hurdle to superior business outcomes and developer productivity.

Of course, it can be done. A few firms have built the required toolchain of base images, scripts, and extensive documentation. However, many organizations may be lacking the time and skillset to invest in building this from scratch, managing the process at scale, or enforcing the usage of the base images and documented process. 

The ideal scenario is an automated, repeatable way to manage the underlying OS images in each container, as well as the updates to frameworks and other dependencies. If these are a best practice, you’re seeking to avoid the anti-pattern of “snowflake” or non-standard images. The right enterprise solution combines the developer convenience of dockerfiles with the certainty that comes from automation. How can you achieve this?

Use Automation to Control the Environment, the Deployable Artifact, and the Process

In her excellent new book, Cloud Native Patterns, Cornelia Davis discusses how to obtain repeatability: 

  • Control the environment

  • Control the deployable artifact 

  • Control the deployment process

Cloud Native Buildpacks (CNBs) help you address dependencies in the middleware layer, such as language-specific frameworks, but they also help control the base OS piece of the environment. They offer control of the deployable artifact in the form of an OCI-compliant container image. And while CNBs are platform-independent, kpack is an open source project that extends Kubernetes to automate running Cloud Native Buildpacks against application source code. Because kpack is KubernetesⓇ-native, it provides a declarative way to build and rebuild images upon relevant buildpack and source changes.

The alpha version of Pivotal Build Service brings kpack and Cloud Native Buildpacks to the enterprise by augmenting the core capabilities of both of these products with:

  1. A layer of role-based access management features to help enterprises enjoy the benefits of a K8s-native solution while maintaining fine-grained access control. 

  2. A flexible interface that allows operators to create build configurations comprised of specific CNBs and utilize the above access management features to scope these configurations to a group of developers. This gives enterprise security and audit departments peace of mind that apps are being built in a compliant and reproducible manner, and reclaims developer time that might otherwise be spent below the value line.

  3. A CLI that not only extends the value of a K8s native build experience, but also offers a layer of abstraction that is equally useable by K8s power users and novices alike.

Build Service is a Kubernetes-native, OCI-compliant container image builder that provides image standardization. With Build Service, operators gain control over two important elements: what’s in the image, and how the image is built. 

Developers are at their most productive when they don’t have to worry about updating container images built by hand days or weeks after its creation. Build Service is a big win for all roles in the development lifecycle for one reason: 

Build Service has a declarative process that defines the container image, its contents, and where it should be kept.

This way allows for much tighter security controls over the container images deployed into production environments.

Let’s take a deeper look at some of the highlights.

Auto-Image Rebuilds Enable Automated CVE Remediation

Patching a base operating system at scale is extremely challenging. Upgrades are no picnic either.

There is a lot of manual effort required to identify and apply a new operating system image across all the outdated systems. In fact, some operations teams have a full-time team applying the regular OS patches around the clock. 

Containers haven’t made this chore less painful. If anything, containers compound the problem: Instead of hundreds of VMs, you now have to worry about thousands of containers!

Cloud Native Buildpacks addresses this issue by allowing users to easily swap out the base-OS layer (re-basing) when new images are published. This is made possible by a standard interface that guarantees any software that will run on one version of the operating system will run on another as long as the appropriate shared libraries exist. The new alpha version of Pivotal Build Service takes this a step further, by enabling the automatic rebasing of container images when new base-OS layers become available. 

Containers are at their best when they are the output of a mature build pipeline, and the following scenario shows why:

Let’s say you’re bumping your stack to the latest Ubuntu Linux distribution to remedy a CVE. You can wire up a pipeline to consume new versions of the OS base image. Build Service will run Cloud Native Buildpacks such that the out-of-date layers are rebased to the new OS image, and the app itself doesn't need to be rebuilt.

The pipeline can then pick up the newly-built container images and run them through smoke tests before finally pushing the images into production. 

The timely remediation of container images across the enterprise is sort of a Holy Grail for SecOps teams. Opt for the consistent, repeatable automation from Build Service, and these practitioners will feel like Indiana Jones: they “choose wisely.”

Managing Multiple Independent Builds

In earlier releases, Build Service introduced multi-tenancy with teams. This functionality allowed different groups of developers and operators to map ownership of build service resources (like images and secrets) to a group of users. This latest release of the alpha transitions to a  model based on Kubernetes Role-Based Access Control (RBAC), in which Build Service users bind resources to a project tied to a Kubernetes namespace. This change was made to make the product more Kubernetes-native and its management more familiar to Kubernetes operators.

Pivotal Build Service CLI Provides More Data

Like any good product, Pivotal Build Service gets better over time. In this release, operators can easily search for the images associated with a given project. Previously, users could only list the builds, without this additional context. Here’s how it works:

You can also retrieve the metadata about a particular image build via the CLI. This information is available on a per image-level. Subsequent releases will include a detailed bill of materials. This will enable operators to have a wider view of what constitutes all images built via the alpha product.

Another nifty enhancement is that you can use Pivotal Build Service with source code that lives in a blobstore. This opens the product up to a wider range of use cases, such as when S3 or another storage service is used to store source code. For example, some Java development teams prefer to build their own JAR files and store those in a blobstore. This feature allows Pivotal Build Service to fit into that workflow as well.  

See How Pivotal Build Service Can Work for Your Organization!

Cloud Native Buildpacks builds on years of success with buildpacks in the Cloud Foundry and Heroku ecosystem. Pivotal Build Service adds much-needed automation and control to Cloud Native Buildpacks, which helps companies deploy faster and more securely. 

When a nasty CVE occurs, Build Service helps by allowing a consistent, repeatable, and rapid remediation. The product automates the rebuilding or rebasing of affected containers. Add a dash of continuous integration and continuous delivery, and your entire team will enjoy more time spent on higher-value activities.

Ready to learn more? Check out these links:

SAFE HARBOR STATEMENT

This blog contains statements relating to Pivotal’s expectations, projections, beliefs and prospects which are "forward-looking statements” within the meaning of the federal securities laws and by their nature are uncertain. Words such as "believe," "may," "will," "estimate," "continue," "anticipate," "intend," "expect," "plans," and similar expressions are also 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, including but not limited to: (i) our limited operating history as an independent company, which makes it difficult to evaluate our prospects; (ii) the substantial losses we have incurred and the risks of not being able to generate sufficient revenue to achieve and sustain profitability; (iii) our future success depending in large part on the growth of our target markets; (iv) our future growth depending largely on Pivotal Cloud Foundry and our platform-related services; (v) our subscription revenue growth rate not being indicative of our future performance or ability to grow; (vi) our business and prospects being harmed if our customers do not renew their subscriptions or expand their use of our platform; (vii) any failure by us to compete effectively; (viii) our long and unpredictable sales cycles that vary seasonally and which can cause significant variation in the number and size of transactions that can close in a particular quarter; (ix) our lack of control of and inability to predict the future course of open-source technologies, including those used in Pivotal Cloud Foundry; and (x) any security or privacy breaches. All information set forth in this release is current as of the date of this release. 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 in documents filed by us with the U.S. Securities and Exchange Commission (SEC), including our Annual Report on Form 10-K. Additional information will be made available in our quarterly report on Form 10-Q and other future reports that we may file with the SEC, which could cause actual results to vary from expectations. We disclaim any obligation to, and do 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.

©2019 Pivotal Software, Inc. All rights reserved. Pivotal is a trademark and/or registered trademark of Pivotal Software, Inc. in the United States and/or other countries. Kubernetes is a trademark and/or registered trademark of the Linux Foundation in the United States and/or other countries. 

Docker is a trademark and/or registered trademark of Docker, Inc. in the United States and/or other countries. Istio is a trademark and/or registered trademark of Google, Inc. in the United States and/or other countries. Windows is a trademark and/or registered trademark of Microsoft in the United States and/or other countries. Cloud Foundry is a trademark and/or registered trademark of the Cloud Foundry Foundation, Inc. in the United States and/or other countries.

Related Articles