The state of CNAB: Part 1 - CNAB Core

What is CNAB?

Late last year, the CNAB (Cloud Native Application Bundles) specification was announced - the news made it to TechCrunch and other tech publications, and partner organizations wrote about how they’re using CNAB (for example Docker, Pivotal, or Bitnami).

So what is CNAB? According to the official specification:

CNAB is a standard packaging format for multi-component distributed applications. It is not a platform-specific tool, and developers can bundle applications targeting environments spanning IaaS (like OpenStack or Azure), container orchestrators (like Kubernetes or Nomad), container runtimes (like local Docker or ACI), and cloud platform services (like object storage or Database as a Service).

But let’s take a step back and recap what problems CNAB is trying to solve:

1. We need to be able to describe our application as a single artifact, even when it is composed of a variety of cloud technologies;
2. We must be able to provision our applications without having to master dozens of tools; and
3. We need to manage lifecycle (particularly installation, upgrade, and deletion) of our applications.

You can read an introduction to CNAB, and here you can find the CNAB announcement blog post.

The same introduction document introduced the desired functionality CNAB hoped to bring:

Broadly, CNAB brings several features that aren’t currently in the ecosystem:

1. Manage discrete resources as a single logical unit that comprises an app.
2. Use and define operational verbs for lifecycle management of an app (install, upgrade, uninstall).
3. Sign and digitally verify a bundle, even when the underlying technology doesn’t natively support it.
4. Attest (or attach a signature to any moment in the lifecycle of that bundle) and digitally verify that the bundle has achieved that state to control how the bundle can be used.
5. Enable the export of the bundle and all dependencies to reliably reproduce in another environment, including offline environments (IoT edge, air-gapped environments).
6. Store bundles in repositories for remote installation.

In the months following the initial announcement, the specification was split into three separate specifications:

• CNAB Core - addresses 1, 2, and part of 5.

• CNAB Registries - addresses part of 5 and 6.

• CNAB Security - addresses 3 and 4.

(Two more sub-specifications followed, for claims and bundle dependencies.)

Why break down into multiple specifications in the first place? The scope of the problem is objectively broad, and it’s much easier to iterate and agree on a subset of changes, with a reduced problem space. Also, all other areas depended on the core specification, so it made sense to reach a stability point there, then turn to the other parts of the ecosystem. So as a community, we decided to focus on having a stable core specification first.

But this doesn’t come without any risks - the most obvious is potentially realizing that the core specifications needs (breaking) changes in order to accommodate distribution or security. We hope this will not be the case, and we think that we’ve covered potential issues (adding custom extensions, custom actions, handling image relocation without mutating the bundle, to name a few), but realizing another part of the ecosystem will only work with a future CNAB Core 2.0 is a possibility until those parts reach stability.

The CNAB Core Specification

The core specification covers the following areas:

• the bundle.json file
• the invocation image format
• the bundle runtime
• the bundle formats

This is the area of CNAB that has seen the most interest so far, and at the beginning of August, a core specification freeze has been instated, stabilizing the core specification even more, and allowing the reference implementation and other tools implementing the specification (such as Porter or Docker App) to implement the latest changes.

Of course following the specification freeze a number of issues have been raised regarding some clarifications, but none of them has lead to major changes.

So what does stabilizing the core specification mean for the community? It means that you can build a bundle with tool A, install it with tool B, then upgrade it or uninstall it with tool C - so the following workflow could be possible:

$ porter build <bundle>
$ porter publish <bundle>
$ docker app install <bundle>
$ duffle uninstall <bundle>

The arguments and flags passed to the tools above are not representative.

There is also a list of issues deferred for a post 1.0 version of the core specification - and as the tools using CNAB mature, that list is expected to grow.

Where is CNAB used today?

There are multiple public (and even more still private) projects that implement parts of the CNAB specification, or use CNAB as a way of deployment:

• Duffle is the reference implementation of the specification, and its goal is to provide functionality for all parts of the specification. You can use it to build, install, and manage bundles, as well as export bundles in thick format for distributing in air-gapped environments.
• Porter is an opinionated CNAB builder that gives you building blocks to create a cloud installer for your application, handling all the necessary infrastructure and configuration setup. It is a declarative authoring experience that lets you focus on what you know best: your application.
• Docker App is an opinionated CNAB builder and installer that leverages the Docker Compose format to define your applications. To facilitate developer to operator handover, you can add metadata and runtime parameters. These applications can easily be shared using existing container registries. Docker App is available as part of the the latest Docker release.
• the Pivotal Build Service (alpha), a declarative way to build an OCI-compatible container image from source code, and is using CNAB to deploy the service on Kubernetes clusters.
• the next alpha release of Pivotal Function Service (a platform for building and running Functions, Applications, and Containers on Kubernetes, based on the Project Riff (v0.4.0) open source project) is likely to be distributed as (CNAB) bundles.
• VS Code extension and graphical installer for bundles - graphical user interfaces for interacting with CNAB bundles
• several groups in Azure are also evaluating the use of CNAB as a delivery and operational pillar.

If a tool or platform wants to be CNAB compliant, it must implement the core specification, but it can choose not to implement the distribution or security specifications. (One example for this scenario is a team that needs the application definition of a bundle, but already has mechanisms in place for distributing it, and ways of attesting the provenance. This team could decide to only implement the CNAB Core specification.)

Finally, CNAB is a community effort, and we would like to thank everyone involved with the project!

In the next article, we will discuss the distribution of CNAB bundles.