By Matt Butcher, especially for Linux.com
Installing a new app on your phone is easy. Install one on your Mac, Linux box or PC. It should be just as easy to install a distributed application in your cloud – this is the goal of the CNAB project (Cloud Native Application Bundles). We believe that we can achieve this goal without needing any other cloud service or tying the user to just one cloud provider.
Over the past few months, we've seen firsthand how much the cloud has to offer. Since everything from our daily meetings to our children's classrooms has gone online, we are reminded every day of what a powerful blessing cloud technology has become.
We know that some serious issues responsible for building and maintaining our cloud presence have not yet been resolved. One of them is how we install, update and delete applications in the cloud. With containers, some JSON and a first-class security infrastructure, we have created a package management standard for the cloud.
A package format for the cloud
While the overarching cloud technologies such as virtual machines and object storage have been around for over a decade and there is an extensive cloud infrastructure, managing cloud applications remains a challenge. My team got together two years ago and asked a simple question: Why is installing, updating and deleting applications from the cloud such a challenge? It is true there are certain services (like PaaS) that make this manageable for a small part of the ecosystem. But when it comes to a high-level solution, we still have to orchestrate things either by hand or with bespoke tools.
This led us to a simple question:
What if we could find a way to make package management for the cloud the same as for an on-premises operating system?
This domain was not new to us. After all, we had created the hugely successful helmet package manager for Kubernetes. However, we were aware that Helm is inextricably linked to Kubernetes. Although we believe that Kubernetes offers many attractive functions, we do not believe that it will replace the rest of the cloud landscape.
We enumerated the big features and started listing things we wanted to do:
Install virtual machines
Set up object storage and cloud database databases
Load containerized workloads into clusters like Kubernetes, but possibly not just Kubernetes
Manage virtual networks and resources such as load balancers
Interact with policy and identity control tools
Make it possible and even easy for developers to introduce support for new services and tools
The list continued similarly for a while. And then there were the two killer features:
Make it extremely easy to use, just like a normal package manager.
Make it completely cloud independent. It should work just as smoothly on Azure, AKS, On-Prem OpenStack and everything else.
The list of functions looked daunting until a fairly elegant solution appeared: today's packages are being moved into separate bundles of code and supporting resources. And then the host environment runs this bundle. What if we only used one Docker container as the primary packaging technology? In this case, we can reuse a significant amount of cloud infrastructure and move packages easily – even across air gaps.
This was the key finding that became Cloud Native Application Bundles (CNAB). With Docker, Datadog and Pivotal (before they were taken over by VMware), we wrote a specification that describes how to create cloud-centered packages that are captured in Docker containers.
Our combined team, originally announced at DockerCon EU in December 2018, continued to work on the specifications, create tools, and look for better ways to provide a user-friendly cloud packaging experience.
Since our first announcement of CNAB, Docker Apps has added CNAB to its production version. Microsoft has developed Porter – an open source CNAB builder – and Datadog has taken responsibility for a CNAB security specification that not only provides a fast verification scheme but also comprehensive security in the software supply chain.
Docker initially announced its CNAB support for Docker apps a great architectural introduction. At the end of last year, they explained how CNAB works with application templates in Docker Desktop. For Docker, CNAB provides a convenient way to encapsulate applications built with core Docker technology without the user having to learn another technology stack. And now the newly released Docker Write specification is supported in Porter and offers a new way of integrating Docker's excellent developer tools into other cloud technologies.
Microsoft created the Porter project. We had already written a CNAB reference implementation (duffle) to run the specification. However, it was not necessarily designed to provide a great user experience. Porter, on the other hand, is a user-first design. With Mixins, Porter can support a variety of cloud technologies, from Terraform to Helm to Docker Compose. You can easily adapt a CNAB bundle to your preferred target cloud or technology stack.
Thanks to Datadog's careful work, the CNAB group is finally preparing to release a second specification: the CNAB Security 1.0 specification. The original security model for CNAB was developed alongside the core specification. But we wanted to make sure we did our due diligence. We spent an additional year studying scenarios, reviewing and collaborating on popular security products so that existing solutions can accomplish this.
In addition to covering distribution security, this specification also provides a security model for the software supply chain. This means that from development to testing and publication, every step can be checked using a robust security process. We believe that CNAB is a new generation of security tools that reduce risk and increase the fidelity of cloud technologies.
CNAB is designed to work well in corporate environments. And the CNAB group has two other standards in flight. We are eager to achieve this.
One of the target environments of CNAB is the "separate cloud". From physically remote environments such as research stations and oil platforms to secure facilities, cloud technologies offer a robust platform, even when they are not connected to the Internet. CNAB is said to work well in these environments as well. And that means that CNAB must have a robust “air gap” story.
This has been a goal from day one. Over the past two years, we've refined our model, goals, and features to best meet this scenario. The core specification was written taking into account environments with air gaps, as was the safety specification. Our third specification, the CNAB Registry 1.0 specification, is the final piece of the puzzle.
This specification describes how CNAB bundles (packages) are saved, recognized, downloaded and moved. Using the OCI registration standard, this specification describes how users and tools share packages. However, it also contains details on how to move bundles with high fidelity across network boundaries. This specification makes CNAB a convincing method for transporting demanding cloud-native applications from network to network – without sacrificing security or with a lot of manual work.
Finally, we have a specification in progress. The CNAB Claims 1.0 specification describes how CNAB tools can use a general description of their provided applications. For example, one tool may "claim" ownership of an application deployment, while another tool can access the shared information about that application and how it is deployed. This combines distributed management, audit trails and long-term tool interoperability.
Porter and Duffle already support claims, but we are pleased with a formal standard that enables information to be exchanged across all tools in the CNAB ecosystem.
How to get involved
The CNAB specification is developed using an open source model. You can dive right in at cnab.io. There you will not only find the specifications, but also the common source libraries (such as cnab-go) and our full command line reference implementation Duffle.
porter is also open source and a good place to start if you want to work with a user-friendly CNAB tool right away.
We even experimented with graphics CNAB installerand have some VS code extensions improve the development process.
Our goal with CNAB is to provide a package management history for the cloud. Just as it is easy to run an installer on our laptops or install a new app on our phone, it should be easy to install a new cloud application. That is the vision that CNAB pursues tirelessly.
We would be happy if you took part, took a test drive and explored the possibilities.