Packages in the Cloud

Environments and Structure

With CNABs, abstraction goes so far as to make it possible to roll out different services of an application on different platforms. Although some components then run in Kubernetes, others opt for a BOSH (bidirectional streams over synchronous HTTP) or Rancher deployment. In practice, you might not encounter such deployment scenarios very often, but the fact that they are possible shows how flexibly the CNAB standard is designed.

The basic structure of the CNAB format will not surprise most admins. Basically, you are dealing with two files: A YAML file, which contains the bundle definition with all the relevant metadata, and an invocation image, which is used to install the containers. The invocation image is therefore a kind of meta service, whose only task is to roll out the containers according to the information in the bundle definition.

Microsoft, Docker, and companies like HashiCorp have also added a built-in quality check to the new format. It distinguishes between "well formed" and "complete." A CNAB application is considered well formed if both the bundle definition and the required images follow the CNAB standard. It can call itself complete if it either integrates all required components into the package (thick bundle) or if the bundle definition lists all external dependencies correctly and they can be resolved (thin bundle). The thin bundle approach obviously saves disk space and makes rolling out CNABs dependent on external factors (e.g., a working Internet connection).

If you have ever built packages in RPM or DEB format, you know an armada of tools exist that, among other things, take care of writing the metadata file for the respective package. Most Debian packages, for example, rely on the debhelper suite to perform tasks automatically, such as creating the metadata description. Not surprisingly, Microsoft, Docker, and others have released several tools along with the CNAB standard to make it easier to use.

Three of these tools play an important role: Duffle is a reference implementation of a tool that can build packages in line with the CNAB definition. It is joined by Porter, which wraps itself around Duffle and creates installer packages on demand that then use the CNAB format in the background. Finally, Docker App builds reusable images on the basis of Docker Compose and the CNAB standard that can even be distributed from Docker Hub.

Duffle

Duffle (Figure 3) unabashedly refers to itself as the reference implementation of the CNAB format and provides a variety of functions for building CNAB packages. Duffle is easy to learn; you can create an initial usable app in package form without problems. After installing Duffle, duffle init drags the local development environment for Duffle into the light of day.

Figure 3: Duffle is the reference implementation for building complete CNABs – but it's not the only tool. © Deislabs

As the next step, you create a folder for your application that contains two files and one folder. In bundle.json, enter the metadata that a CNAB cannot automatically guess, such as the name of the CNAB's maintainers. You need to add similar information to the duffle.json file, which is only used for Duffle and will not be included in the CNAB later on. The cnab/ folder contains all the files necessary for creating the image. In the case of the trivial Hello World Duffle example [2], this folder contains the Docker file that turns a generic container into a Hello World container. The app/ folder also contains files that need to be copied to the container in the Dockerfile – Duffle only searches for them there.

Once you have created the configuration files for the container, the following steps are trivial:

• duffle build creates the CNAB for the Hello World package, which is then found in the host's Docker registry.
• duffle install then rolls out the application as a CNAB.

In the end, you have a ready-to-run container based on Docker. You guessed it: Duffle currently only works with Docker and requires Docker as its command-line interface.

Porter

The second reference implementation for CNABs, Porter [3], does not come from Docker but from Microsoft, who has invested resources in the past years to get Docker running on Windows – with some success. However, for understandable reasons, Microsoft primarily wants to attract customers to its own cloud. What could be more obvious than building a tool that offers developers and administrators the possibility of building CNABs directly for Azure? Porter precisely hits this target (Figure 4).

Figure 4: Porter comes from Microsoft and is far more versatile than Duffle. Above all, it also supports other services.

For Porter, you again write a file containing the metadata for the CNAB, but this file is not the bundle.json file used by Duffle. Porter uses the metadata file to generate a future bundle.json. By the way, if you don't like JSON, Porter will be happy to provide YAML, to avoid all those parentheses.

Developers store all the required details in the YAML file. For example, you would specify not only the name and version of the CNAB, but also which invocation image is to be used. Mixins are a kind of module that can be used to integrate support for container environments. They exist for (surprise!) Azure, as well as AWS or completely different environments like Terraform.

Unlike Duffle, Porter knows how to handle the various as-a-services of the clouds it supports. For example, if you need MySQL in a CNAB, you can integrate the MySQL resources from Azure or AWS with the database-as-a-service (DBaaS) functionality there. If you later install the CNAB in an environment with Porter, it automatically starts the necessary database.

Moreover, Porter works with Kubernetes, because one of the supported mixins is the Kubernetes package manager Helm. If you want to roll out WordPress to a Kubernetes cluster in Azure that also talks directly to a MySQL database in Azure, you can enter all these details directly in a Porter metadata file.