Packages in the Cloud

In 2018, Docker and Microsoft noticed the lack of a generic package standard for containers and set out to address the problem. The result was cloud-native application bundles (CNABs), which "… facilitate the bundling, installing, and managing of container-native apps and their coupled services" [1] (Figure 1). The "approved deliverable" version 1.0 was made publicly available under the terms of the Open Web Foundation 1.0 license in September 2019. I take a close look at the CNAB standard to see what it does and does not define and how administrators and developers can benefit.

Figure 1: Cloud-native application bundles define a format for packetizing container applications and standardizing the roll-out.

A New Ecosystem

In the typical manner for new technology, a standard toolset can take a while to crystallize. Even containers are not immune to this effect. In the initial phase, Docker was the undisputed king of the hill, single-handedly guiding containers out of the shadows and making them presentable. (See the "Container Advantages" box.)

However, it soon became clear that anyone that uses Docker as a foundation for applications needs logic to manage the various containers of an application centrally. In the age of the cloud, a suitable framework must also let admins operate Docker containers as entire fleets of physical or virtual systems because it is the only way to ensure scalability.

Solutions such as Kubernetes quickly appeared on the scene, while the actual container formats tended to take a back seat. Kubernetes, for example, can now be operated just as well with CRI-O as with the Docker format for container images. From the outside, you hardly notice any difference (e.g., as with OpenShift, shown in Figure 2).

Figure 2: The value of container virtualization is not in the format but in the management. © Red Hat

The question then is how a format can be defined that is as generic as possible, yet sufficiently effective for distributing containers. Anyone familiar with the Linux world knows that RPM and DEB have been closely defined standards for decades. If you build a DEB package for a program and stick to the rules, you can rely on having a good package. Containers have been different thus far, until Docker and Microsoft teamed up to create CNABs.

What Is Needed

To understand the idea behind CNABs, it helps to visualize the container developer's working day. In an application that comprises many small components, the developer also has to deal with many small containers. A CNAB does not give any instructions on how to develop these containers, which is very much in the tradition of the classic package manager.

For DEB, it doesn't matter how the package is created. What is important is its compatibility with the version of the DEB standard that the package developer specifies in the metadata. Just as certain toolchains have emerged in RPM and DEB that are mainly used today for building packages, containers have followed the same course.

Comprehensive integration with a continuous integration and continuous deployment (CI/CD) tool is an essential part of a valid container success story. If the developer takes the trouble to set it up at the very beginning of this work, it pays dividends time and time again. The commands required to build an image can reside in a Docker file in a Git directory, for example. If a detail changes in this Docker file or anywhere else in the repository, the Git environment itself triggers the image rebuild with a hook application. As an example, GitLab comes with its own Docker registry, to which it uploads new images on demand.

However, one swallow does not a summer make, and an image doesn't make an application rolled out in a microservices architecture – for many reasons. For one, admins do not just need to deal with one container, but with several, and they typically have to be rolled out in a certain way.

As for normal packages, containers often have dependencies. Sometimes the complexity of containers is even far greater than that of package systems, because certain containers not only have to run in parallel, their configuration also has to be coordinated. If you roll out containers in the context of a fleet orchestrator such as Kubernetes, you also have to be familiar with the various parameters that need to be taken into account during the rollout.

CNABs Supply the Metadata

Metadata, and a tool that interprets and implements it, acts as the glue that holds together various active Docker images and their configurations and is where a CNAB comes into play: The term is (and is certainly confusing for many users) both the name of the defined standard and the umbrella term for the tools associated with it. Nevertheless, it does make sense to consider the standard format and tools separately.

The two initiators of CNAB, Microsoft and Docker, see it primarily as a package standard that defines the formats and metadata for distributing applications in containers. A CNAB is aimed at all administrators who have worried about getting lost in the tangle of different services and APIs in their container environments in recent years.

As an admin, you have to deal with a number of APIs and tools: Docker at the command line and Kubernetes with what feels like hundreds of tools and utilities (partly upstream, partly not). Various additional services like Terraform and CloudFormation enjoy the users' favor, as well, and they all come with their own metadata formats that you have to learn if you want to use them to roll out applications. In the simplest form, an application is rolled out by packing it into a large Docker container and distributing it over Docker Hub, although this is not a very flexible solution.

The CNAB standard sets out to bring order to the combination of available tools and standards by wrapping itself around them like a vise. A CNAB describes a metadata format that abstracts the minutiae of many different run-time environments (including Terraform, CloudFormation, Kubernetes, and Docker Compose) and makes them usable under a common domain-specific language (DSL). Although Kubernetes is undoubtedly the container tool of the hour, a CNAB is not aimed only at Kubernetes fans (probably because of the involvement of Docker, who offers a Kubernetes competitor in the form of Docker Swarm).