There’s a problem in the IT industry today: operations folks spend way too much time on YAML. Take the installation of packages, for instance. Whether you’re installing on Kubernetes, public cloud, VMs, or even bare metal, there’s a lot of configuration to slog through. And the situation promises to get worse as more workloads move to distributed runtimes.
Shouldn’t there be a standardized way of installing software? Can’t we abstract this tedium away?
We think so. To this end, Microsoft, Docker, HashiCorp, Bitnami, Pivotal, and many others created Cloud Native Application Bundles (CNAB). CNAB is an open source cloud-agnostic package format specification for bundling and installing distributed applications.
The CNAB core spec just hit version 1.0. (Here’s the spec itself.) This milestone signals that the project has matured enough to be useful. And what, exactly, can the community do with CNABs? TechCrunch sums up it up well:
“At its core, the CNAB is nothing but a specification that allows developers to declare how an application should be packaged and run. With this, developers can define their resources and then deploy the application to anything from their local workstation to public clouds.”
That’s the real power of CNAB: you can deploy compliant packages to different targets and runtimes the same way. My colleague Mark Fisher recently observed:
“One of CNABs main value propositions is not being opinionated about the target environment, not necessarily K8s. The invocation image can be/do anything. It's really a packaging format and an env var ‘contract’ but otherwise completely open-ended.”
Don’t sweat the details. Just install the package, then use it!
Sure, CNAB supports different runtimes. But the obvious question is, “How will this play with Kubernetes?” We’re bullish on CNAB for two reasons:
-
You don’t have to be a Kubernetes expert to use it. Kubernetes can be daunting. Don’t worry! The CNAB abstraction layer over the top is much easier to use.
-
CNAB simplifies complex deployments. Most enterprises aren’t in a world where 100% of their app estate runs atop Kubernetes. CNAB is a common format that abstracts the nuance of any given runtime away. For example, consider a collection of microservices. Some services may run on Kubernetes, but other parts of the app still need to be deployed on BOSH. You may even need to run Terraform scripts to setup dependent cloud services. CNAB can handle this variation with ease.
Software that’s packaged according to the newly minted CNAB spec has two interesting attributes:
-
It can be cloud-agnostic. A bundle can be composed to use whatever infrastructure or services you need. CNABs support your multi-cloud strategy.
-
It’s shareable. Use bundles to deliver apps across teams, organizations, and marketplaces. Sharing at scale drives productivity!
Another attribute in the works: security, specifically easy options for verification. Project contributors are exploring how a bundle can be cryptographically signed, attested, and verified to ensure it comes from a trustworthy source. In time, InfoSec teams may come to appreciate these embedded options for governance and security. (This emerging work is covered by CNAB-Sec, a spec that builds on CNAB-Core.)
Let’s take a closer look at the core spec.
Inside the Cloud Native Application Bundle Core Spec
CNAB provides a packaging format for a broad range of distributed applications. We’ll wade through some jargon here, so buckle up!
Each bundle has a bundle definition to define the app, and an invocation image to install the app.
The bundle definition is a single file (bundle.json) that contains the following information:
-
Bundle name, version, description, and keywords
-
Information about locating and running the invocation image (the installer program)
-
A list of user-overridable parameters that this package recognizes
-
A list of credential paths or environment variables that this bundle requires
-
A list of executable images that this package uses
The canonical representation of a bundle definition is a JSON-formatted file. It’s encoded as a Canonical JSON object stored in a bundle.json file, according to the bundle file definition.
The bundle definition is mounted as a file within the invocation image's runtime filesystem. Additionally, it can be stored on its own, or as part of a packaged archive (known as a “thick bundle”). This is simply a CNAB bundle that includes the JSON file and exported images, including the invocation image.
A bundle is considered to be well formed if its definition follows the CNAB schema and the images are in the correct formats. A bundle is considered complete if it is packaged as a thick bundle, and all the components are present OR if it is packaged as a thin bundle and all of the references are resolvable. Completeness of a thin bundle is thus contingent upon external factors such as network access.
Want to dig even deeper? The CNAB core spec is on Github.
Let’s wrap up with a look at how Pivotal is experimenting with CNABs today.
We’re Exploring How to Use Cloud Native Application Bundles
Historically, Pivotal engineers package code in a specific way, depending on the intended deployment target. Our teams ship open-source and commercial software as BOSH releases, Kubernetes resources, and Helm templates. From there, users match the right package with their preferred runtime. This complexity goes away with CNABs. Whenever a compliant bundle is published, the user simply installs said bundles on their preferred runtime.
Today, we use CNAB in a handful of our new Kubernetes-based offerings. Let’s examine how CNABs simplify the installation of Build Service, an alpha product that automates the creation and management of container images from source code.
With CNAB bundles, installation of Build Service is straightforward. Build Service is a multi-component deployment, which would otherwise involve many steps before you’d have it up and running on your cluster.
Some manual install steps are particularly error-prone. One would need to configure multiple credentials and configuration parameters during installation. With the Build Service bundle, these details need to be provided just once. That vastly reduces the surface area for mistakes.
What’s more, Build Service upgrades are delightfully uneventful with CNAB bundles. Why? Because all the installed components are managed by the same artifact.
Get to Know CNABs
So what’s next? The registries spec and the aforementioned security spec, for starters.
The registries spec deals with distributing bundles via OCI registries, something Docker has been working on for some time.
As for the security spec, project contributors are researching cryptographic verification on many levels. One idea under consideration: the thick bundle artifact could be signed, and include the content digests of all the images specified in the bundle (Docker, OCI, VM, and so on). CNAB runtimes could then be required to validate the digests.
Contributors will investigate ways to standardize invocation images and make bundle development easier. Another backlog item: splitting out artifacts from the invocation image. This way, cloud providers can create standard invocation images that developers can use as building blocks for their apps.
In the meantime, now is your chance to get involved in the community! Here are a few resources to help:
-
Start by reviewing the spec.
-
Join the #cnab channel in the CNCF's Slack. The CNAB community has an open meeting every other Wednesday at 09:00AM US Pacific.
-
Take the reference implementation, duffle, for a spin.
-
Deis Labs has a blog series on CNAB. Here’s Part 1, and Part 2.
-
Listen to the Kubernetes podcast about CNAB.
-
Want a video explainer? This one from Microsoft and Docker is terrific.
-
Register for SpringOne Platform, October 7-10 in Austin! It’s a terrific conference if you’re keen to learn more about modern engineering practices. We’ll be talking about CNAB at the Pivotal booth; several other project contributors will be at the show as well.
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.
