CNAB Support

[RichiCoder1]

CNAB fits Waypoint's model of building and deploying an immutable artifact, and might a good fit for Waypoint while providing a lot of power.

CNAB, or Cloud Native Application Bundles, are a way of creating, deploying, and managing immutable app packages and their necessary tooling and configuration. https://cnab.io/

[mitchellh]

Can you please provide an example pseudo-code example of how you'd imagine CNAB fitting into the Waypoint configuration file and workflow? We like to just validate some examples before we pursue any work like this and in many cases it may make more sense for a community member to write a plugin for scenarios like this.

[RichiCoder1]

Sure!

One complication is that CNAB authoring is done via one of two tools:

• Duffle which is the reference tool for CNAB authoring
• Porter.sh which is an official tool with a lot of powerful extensions for CNAB authoring

So waypoint would likely wanna pick or support both.

In theory, the build would look a lot like docker. So something like:

build {
  use "cnab" {
    # extensions = ["az"]
  }
  registry {
    use "docker" {
      image = "example.com/my-app"
      tag   = gitrefpretty()
    }
  }
}

Would likely need to do some work to inject Waypoint's entry point into the correct execution layers.

Deploy would be relatively "simple" too:

deploy {
  use "cnab" {}
}

CNAB handles the nitty-gritty of packaging and configuration, as well as deploys and upgrades. So Waypoint would mostly be shelling out to CNAB w/ some smarts/insights into what's happening as well as maybing providing first-class support for params and credentials. So:

deploy {
  use "cnab" {
    # Somehow consume `waypoint config` in the execution CNAB runtime

    secretsProvider = "vault"
  }
}

That's more aspirational however.

Release would in theory be unchanged.

[evanphx]

Hi @RichiCoder1!

Can you tell us a little about how CloudNative BuildPacks compare and contrast with CNAB?

[RichiCoder1]

Buildpacks are focused on greatly simplifying turning source code into production ready images. CNAB is about packing all the necessary images, tools, and configuration into a single immutable bundle that installed in one step. CNAB handles deployment, configuration, infrastructure, and more. So they are actually complimentary! You could use a buildpack to produce an app image, and then bundle that app image into a CNABundle.

[RichiCoder1]

In fact, explaining that made me realize that my build step is missing an example. You'd still need to build the app code. https://porter.sh/author-bundles/#images

So waypoint would need to support building the app image, and then consuming that image to build a CNAB.

[evanphx]

Could you explain on what you think the cnab deploy plugin would do? Would it just be creating some CNAB artifact? I don't see anything in the CNAB spec or website about it having the ability to deploy something.

[RichiCoder1]

It would invoke the bundle created in build, likely invoking install or upgrade:

• https://github.com/cnabio/cnab-spec/blob/cnab-core-1.1.0/102-invocation-image.md#the-run-tool
• https://porter.sh/cli/porter_bundles_install/
• https://github.com/cnabio/cnab-spec/blob/cnab-core-1.1.0/801-declarative-images.md#declarative-infrastructure-and-declarative-installers

[RichiCoder1]

To be clear, CNAB is just an immutable package with invocable images, optionally all packed together in a self-contained bundle. So build would be creating this bundle, and deploy would be invoking it. The nature of which could deploy k8s resources, running terraform commands, or other such things. So it may almost be too flexible for waypoint to reason about 😅

[evanphx]

@RichiCoder1 Do you have an example of how, say, one would use CNAB to deploy a service on kubernetes? Maybe that would help me understand the workflow.

[RichiCoder1]

Here's a pretty concise example:

• https://github.com/getporter/porter/blob/main/examples/gke-example/porter.yaml
• https://github.com/getporter/porter/tree/main/examples/gke-example

[evanphx]

@RichiCoder1 So i'm not seeing an easy way for CNAB to consume other kinds of artifacts, which means that the waypoint file would look like:

build {
  use "cnab" {}
}

deploy {
  use "cnab" {}
}

I'm trying to get an idea of where waypoint is enhancing CNAB (or visa versa). This looks like just another way to invoke those 2 CNAB commands. Can you talk more about the functionality you'd be looking for when integrating CNAB and Waypoint?

[evanphx]

@RichiCoder1 If it's just waypoint invoking a cnab commmand, exec might work. Otherwise I'd invite you to noodle on the CNAB plugins yourself so that we can get an idea of the direction. Doesn't have to be complete, just a first spike to get things flowing.

[RichiCoder1]

@evanphx Per an early note, being able to combing cnab + docker, as you'd still need to create the images/charts that CNAB packages and deploys. The custom urls for CNAB deployed applications. Not to mention the release functionality is still valuable.

That's fair. I think I may just to see how I could get the two to play together in a way that fits the value prop of both.

[evanphx]

Ah! Ok, well that's going to be tough right now because if cnab were the build phase, there wouldn't be another build phase to produce the asset from the application source for cnab to consume. We have some plans around the ability to make this more flexibility but it doesn't exist today.

[RichiCoder1]

@evanphx Yup, that'd be a concern. Either Waypoint would have to support multiple linked use's in build or the cnab plugin would have to take over the docker build portion. Which I may try just for a PoC?

[evanphx]

Multiple linked uses is going to be a big thing in the core, so you'll have to focus on the later.