Packages in the Cloud

Creating Bundles with Porter

Once you have built the porter.yaml for your project, the rest of the work is very simple. Use porter build to create the bundle, which can then be loaded into an open containers initiative (OCI)-compatible container registry such as Docker Hub or a local instance of Quay. From there, you can easily roll out the bundle again locally with porter install.

Working with the porter command is quite similar to using the docker command, but unlike Docker, Porter gives you the complete bundle, which can roll out resources in many different cloud environments at the same time. This clearly shows how practical CNAB is as a format.

Docker App

The third reference for CNABs, which once again comes from Docker, is also worth a mention. In contrast to Duffle, which looks to build local bundles, Docker App [4] is intended to be the Docker counterpart to Porter, but with a far smaller feature set (Figure 5).

Figure 5: Docker App uses Docker containers to build CNABs, but its future looks anything but assured.

The basic principle of Docker App is similar to that of Porter: You use a metadata file to describe the CNAB, which can comprise various Docker images and their respective configurations. Running docker app then creates a bundle for this app that meets the CNAB specification.

Practically speaking, docker app actively ensures that the resulting bundle complies with the CNAB standard; the container registries that comply with the OCI standard (e.g., Docker Hub) can already handle CNABs. From an admin point of view, this setup is very practical because the CNABs created in this way can be distributed without problem.

Unlike Porter, Docker App is oriented exclusively toward Docker Swarm or, locally, to Docker itself. A Kubernetes connection also exists with the Helm package manager, which allows applications built in Docker App to be deployed directly in Swarm or in a Kubernetes environment. What is missing, however, is the versatility of integration with various Kubernetes variants or the services offered by public cloud providers.

If you want to use Kubernetes for a WordPress installation, for example, you need the MySQL database. Although this can also be operated in Kubernetes as part of an application with its own container, you can weigh yourself down with an additional full application in this way. The advantage of the cloud providers' as-a-service offers is that you have no need to worry about certain basics of these applications – such as replication, backups, data integrity, or maintenance of the underlying operating system. However, Docker App does not support the integration of such services and therefore falls a little short of the mark.

Also unclear at the time of this writing was whether Docker App would have a real future. After all of Docker's commercial business was transferred to Mirantis, the new owner immediately set about cleaning up. Only a few hours after the announcement of the takeover, several news items popped up on Twitter announcing that former Docker developers were now looking for new employment opportunities.

Meanwhile, prophets of doom hint that what is now left of Docker could make a great match for Microsoft, which, however, would probably not be a good thing for the future of Docker App, because Microsoft already has the far more extensive Porter. If you're currently getting started with CNABs, you are well advised to take a closer look at Porter and wait and see how Docker App develops.

CNABs and Kubernetes?

It makes sense to take another look at the relationship between CNABs and Kubernetes. As mentioned at the beginning, Kubernetes is currently without doubt the only real shooting star in the container universe. Docker felt this painfully in November: Rumors that the company was on the verge of bankruptcy persisted for weeks. The speculation only came to an end when Mirantis took over the business from Docker Enterprises. However, Mirantis is taking a rigorous pro-Kubernetes course, which raises the question of whether Docker is planning to quit using CNABs and to what extent the use of CNAB packages in the CNAB context makes sense at all. After all, Kubernetes also has its own package manager, Helm, which is similar to a CNAB in many ways.

Whether and to what extent CNABs and Kubernetes can complement each other meaningfully all depends on the question of how homogeneously admins and developers design their container experience. Those who run Kubernetes on bare metal or in a cloud do not have a central problem that CNABs address. Normally, they will not need to deal constantly with different toolchains and different targets for the deployment of their containers. Instead, in such a use case, Kubernetes APIs are available to handle all the tasks at hand, including installing packages with Helm.

CNABs, on the other hand, have a reason to exist if you do not want to deploy exclusively to a local Kubernetes instance via the native Kubernetes APIs. Anyone using Terraform or wanting to use the Kubernetes services of AWS, Azure, or Google in their respective clouds is already confronted with several tools. In this scenario, CNABs help, because they abstract and resolve this complexity. The admin uses the same bundles for all target platforms and enjoys a uniform interface.