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:
- We need to be able to describe our application as a single artifact, even when it is composed of a variety of cloud technologies;
- We must be able to provision our applications without having to master dozens of tools; and
- We need to manage lifecycle (particularly installation, upgrade, and deletion) of our applications.
The same introduction document introduced the desired functionality CNAB hoped to bring:
Broadly, CNAB brings several features that aren’t currently in the ecosystem:
- Manage discrete resources as a single logical unit that comprises an app.
- Use and define operational verbs for lifecycle management of an app (install, upgrade, uninstall).
- Sign and digitally verify a bundle, even when the underlying technology doesn’t natively support it.
- 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.
- Enable the export of the bundle and all dependencies to reliably reproduce in another environment, including offline environments (IoT edge, air-gapped environments).
- 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.
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 core specification covers the following areas:
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.
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:
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.