Microsoft BUCK Shows How CNAB Bundling Could Work for Cloud App Deployment

The convenience of containers quickly made them the modern equivalent of a ZIP file for simple deployments, but as applications built on a cloud native stack become more sophisticated, the container is no longer the unit of deployment — the application is.

Tools like Helm tackle app installation for Kubernetes, but many applications involve more than just Kubernetes, with serverless functions and hosted cloud services that need to be defined and packaged, up along with containers, into a bundle that can be shared. And cloud native apps aren’t necessarily running in the public cloud; they might run anywhere from a cloud appliance to a Raspberry Pi on an intermittently connected industrial site where resources can’t be downloaded on demand, but you still need to be able to install apps and update them (or even delete them).

Distributing and deploying cloud native apps is a key focus for the recently formed the Cloud Native Computing Foundation Application Delivery Special Interest Group (SIG), not just building or operating them. Even the eponymous container company Docker is attempting to pivot from containers to this much broader view of what it takes for a developer to ship an application.

One of the key initiatives here is the CNAB specification for Cloud Native Application Bundles that package distributed applications into a single installable file that can be signed and stored in a registry or copied to a USB stick, using tools like Duffle, Porter and Docker Applications.

“We have customers who love Helm but they’re not only on Kubernetes,” Lachlan Evenson from the Azure container compute team told The New Stack. “Modern distributed applications consist of many different runtimes and you’re never going to be all in on just one. So CNAB was about, what about the world who wants to run distributed apps that consists of more than just Kubernetes; how do we give them that distributed application experience that we all know and love that Docker gave us with containers”

“There’s just nothing else out there that does what CNAB does, and certainly nothing out there that can do it with the security and compliance guarantees that we’re able to offer with a fully hermetically, cryptographically sealed bundle,” director of Azure Compute Gabe Monroy told us.

The new Open Application Model specification for separating the definition of an application from the operational details of how it’s deployed (implemented for Kubernetes as two tools, Dapr for developers and Rudr for operators) can use a Helm chart to deploy an OAM definition and dependencies to a Kubernetes cluster. Or if you need to install the same app on a Kubernetes cluster that doesn’t have access to the container images Helm would need to pull, you can put the images and the Helm chart in a CNAB bundle. Unlike a Helm chart, the CNAB bundle can also include operational details like triggering automatic rollback if the health of a group of services is impacted by an upgrade. OAM will be also able to target platforms other than Kubernetes, and CNAB helps with that.

The overall goal, says Monroy, is “how do we make it possible for developers to write robust resilient, highly available distributed applications?” OAM and Dapr are one approach to that, as is serverless. Buck, the Brigade Universal Controller for Kubernetes that Microsoft built to simplify the development of Kubernetes controllers by writing them in JavaScript rather than Go) is part of the same trend, he suggests. “How do we democratize this technology, how do we make it more appealing and more approachable, to a larger number of developers?”

Bucking the Go Trend

Kubernetes operators — applications that are automated and can operate themselves, often by listening for user-defined resources created by Custom Resource Definitions – are an exciting pattern in cloud native development, says Monroy. “But writing an operator is hard, it requires a deep knowledge of Kubernetes API semantics: how to do watches, how to do the resync loops. There’s a lot of hard stuff in there.”

“People want to define their workload-specific controllers,” explains Evenson, “but the barrier to entry is very steep. You have to go down to kubebuilder. If you never worked with Kubernetes before, it’s a very big leap. You want to define a very lightweight controller that talks to Kubernetes, without having to deal with all the nitty-gritty, so can we leverage Brigade and the tools that we built to receive an event from Kubernetes, and then implement a controller”

Buck uses Brigade, a Cloud Native Computing Foundation project for event-driven workflow automation, to make it easier to write Kubernetes controllers; it’s a Brigade gateway that acts as a Kubernetes controller front end by accepting a custom resource name and then listening on the Kubernetes event stream for events related to that custom resource. When the gateway receives an event for its custom resource, it notifies Brigade which creates a new worker and passes it the event details; that worker then runs the workflow of jobs you’ve defined.

Buck itself is written in Rust, but because it’s a gateway for Brigade, the controllers can be written in JavaScript. There’s even a Helm chart for defining a custom resource and deploying the Buck gateway with it.

“There’s a whole world of developers operating in JavaScript and when they come to Kubernetes you ask them to go and be a Go developer,” Evenson points out. “Brigade was always about, can we create a framework to speak to those developers too, so they can have the Kubernetes experience without having to become a Go expert.”

Hosting Bundles Like Containers

Microsoft also created a sample operator using Buck for installing CNAB bundles onto clusters and managing their lifecycle using Porter. “One of the things we wanted to do with Buck was model the possibilities of CNAB,” Evenson explains.

That defines a Porter action as a Kubernetes custom resource. It also lets you manage CNAB bundles from the cluster, using a YAML file with the details of the CNAB installation; create the YAML to install the bundle, modify it to update the CNAB installation and delete it to uninstall the CNAB.

If CNAB bundles become common, you’re not going to want to stand up and secure another repo — or manage accounts on another cloud registry — just to store them in. Container registries have already been hardened, secured and made scalable and available. So why not use them for other artifacts like CNAB bundles and Helm charts and Terraform, ARM and Cloud Formation templates and all the other artifacts we need for cloud deployments?

The Distribution specification from the Open Container Initiative is what defines the registry API; version 2 of that is still going through approval but thanks to the OCI Artefacts project and the ORAS (OCI Registry as Storage) library, it will support different media types like Helm charts, CNAB bundles — and even WebAssembly modules. That’s already implemented in the Docker Registry and the Azure Cloud Registry under an experimental flag.

“When you do a Docker login, you can now store your Helm charts and your bundles in that same space,“ Evenson explains. “It’s just a nice integrated experience.”

Using OCI registries for new artifacts like CNAB bundles integrates them better with existing tools, and that makes it easier to move to bundles as you start to build more sophisticated cloud apps that require them.

The Cloud Native Computing Foundation is a sponsor of The New Stack.

Feature image via Pixabay.