Cloud Native Computing Foundation KubeCon + CloudNativeCon Europe 2021, 14 May 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Introduction to Cloud Native Buildpacks - Stephen Levine, VMware & Jesse Brown, Salesforce

Description

Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon North America 2021 in Los Angeles, CA from October 12-15. Learn more at https://kubecon.io The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.

Introduction to Cloud Native Buildpacks - Stephen Levine, VMware & Jesse Brown, Salesforce

Cloud Native Buildpacks transform your application source code into images that can run on any cloud. In this session you'll learn the basics of using buildpacks, and why they make a great choice over the alternatives.

A

Hello, everybody thanks for virtually attending our talk on cloud native, build packs. My name is jesse brown and I work at salesforce and I'm also a maintainer on the cloud native bill. Packs project coordinator bill pax, just graduated from sandbox to incubation in november.

A

So let's talk about what built backs are trying to accomplish. The primary objective of build packs is to take your source code and convert it into an oci image.

A

It doesn't just execute a single like bash script and then poof you have an image. Instead, it creates distinct layers that make sense so you've got your application layer. You've got your runtime layer which might have your ruby runtime dependency layer which might have your ruby gems and the stack layer which is sort of just the base image that your application would run on, and this is all without you having to write any docker files.

A

Taking a step back cloud native bill packs are built on the rich history. Rich and successful history of bill packs bill pack started back in 2011 at heroku pivotal shortly thereafter uh adopted bill packs as well and sort of went their own direction and cloud native bill. Facts really represent sort of the convergence of those and creating a new api that takes into account our containerized world today.

A

Looking at an image that comes out of cloud native build packs a little bit closer, it's got a few key features. First, is that your app image is reproducible.

A

This is important for security purposes and as long as you give it the same source code, the same base, images and deterministic build packs, then you'll be able to produce the same image every time, which is very important for, as I said, security and application developers.

A

Secondly, all images are built with metadata that can be expected after the build. um This can contain all sorts of things depending on the build pack, but primarily things like your dependencies, which version of ruby or go you're running as well as, like other metadata about the build. That could be very important for your containers at scale and, as I mentioned earlier, the layers themselves are logically mapped, so you've got a layer for your go or ruby.

A

Runtime you've got a layer for your gyms or your npn packages, and you've got a layer for your application and it's really up to the bill packs on how to divide this up, but it gives them the tools needed to create fast reproducible builds the cloud native bill. Pax project is responsible for multiple specifications, as well as a reference reference implementation of those specifications.

A

The pink box on this slide is the reference implementation that we call lifecycle. This implements the two primary specifications.

A

One is the platform api on the left, which describes the interface between lifecycle and a platform and platform is something like fly. I o techton pac kpac heroku, salesforce, vmware, tanzu, google cloud things like that and then the other side of lifecycle. The other specification is the billpak api, which represents the interface between bill pack, authors and the life cycle that executes those build packs.

A

As you can see on the left, there's quite a number of platforms that have adopted collaborative bill packs and we're continuing to see more and more services and applications adopt billfax.

A

And on this slide, this is sort of a slide. That's going to show the flow that takes your application source code and an image, a build image and then pushing it through pac, which is our cli to create your application image. But let's take a look at that a little bit closer.

A

Let's start off by building this simple node.js application, as you can see, there's no docker file, and so what we're going to do is we're going to give this application source code via our cli called pac and we're going to go ahead and tell it to build us an application image and I'm going to give it a docker hub url and I'm going to tell it to publish this application to docker hub at the end of it.

A

One of the first things you'll see here is our phase markers and you'll, see detecting here and what's happening here. I'm actually using a google builder and google builders are packaged with a bunch of build packs, and you can see that we chose four build packs here. So the node runtime, a node npm, config entry point and a utils label and the ends yeah. So each build pack in the builder has an opportunity to opt into the build based on the application source code.

A

So a node build pack would look for a package json and then it would get that information of what version of node to install from the package json and an npm one would be very similar. um It's looking for package.json and also to see whether there's any packages that need to be installed, and so you can see that we had those build packs chosen. So in this builder, there's also going to be other build packs like a go buildback or a.net.

A

Build pack and all those build packs had an opportunity to opt into this build process but decided not to because there's nothing there for them to do in the building phase. Here you can see that it's outputting extra information like they're, actually going to go and get the node runtime that we need and then it's going to install the packages for our node application and then finally, at the end, it's going to export to the image that we told it to export to and add docker hub.

A

Excuse me, let's take a look at. Let's run the image first, just to show that this image is, it does work. It's going.

B

To run this application.

A

Boom so you know, we've got a node.js getting start application running on port 5000 and let's take a look at some of the metadata that we talked about earlier.

A

So I used the pack inspect command and gave it an image, and so using the specified metadata. That is on the image. We can see that the stack was the google stack. We can see that there was a run image with a particular digest that it was built on top of, and that would be very important later when we talk about rebase and then also you've got metadata about which build packs were selected to run and which ones contributed layers, as well as the process that were defined by those build packs.

A

And then, let's see you can also go a little bit further and build packs can contribute very specific data. That would be useful for their platform or for their developers that use the buildback and that's the bill of materials.

A

And so you can see here that in the bill of materials, the node build pack or a node entry was created with a version of 1416.1 and so at scale. You can imagine how useful it would be to know which applications or which containers in your cluster are running which run times that need to be patched and all this without cracking the image open right. All this stuff is built into labels on the images that are output from the cloud-native little packs project, and let's go back to the slides now that we've built an image.

A

Let's talk about this slide in depth in the middle you'll, see two images referenced with a label of stack, and this is a build image and a run image. This is very conceptually similar to multi-stage docker files, so the build image would be a beefier image that has all your supporting libraries for building your application and the run image is generally a thinner image or a completely different image that can run the result of your build.

A

The build image is used as part of the builder image, and earlier I use the google builder image, and it is a builder image consists of a the lifecycle component, which is the implementation reference mentioned in the previous slide, which influenced the spec as well as the build packs that are bundled with that builder image and then combined with your source code. It executes all those build packs which then create dependency layers, and so, as we talked about earlier, there's like a node engine dependency, npm dependency, the packages for your specific application.

A

All of those can be logically put into different layers and exported and spliced together on top of the run image that is defined for that stack and then, finally, your application source code can also be put on top. There.

A

And one thing to point out here is that no two applications have to be alike. That builder image that we looked at earlier may have dotnet ruby node.js, but the process is the same for the application developer, so that consistency of being able to check out some source code from a centralized repository and pack build that into an image and have that builder handle all of your all of your applications.

A

You know your elixir, your google, your ruby, all of those they all work, the same way, they're all going to be built on a consistent set of principles.

A

The layers are going to be logically divided, which means that when you they get pushed to a registry, they will be shared when they can be shared they're built on the same run. Images if you use the same builders, which means that you can, you know, enforce and uh yeah just leverage the fact that those run images are the same and patch them appropriately, and you can patch cloud native pilpat projects with rebase, which we'll get into a little bit later.

A

A more recent addition to the bill pack project is a public build pack registry, similar to rust, crates, npm and other distribution solutions. This is targeted at application developers who are looking for build packs to meet their needs, as well as bill pack authors who wish to share their work with the larger bill pack ecosystem.

A

You can search for specific versions of bill packs published on this registry and used them from pat. So in this example, here we've got minecraft server published by user jay cuttner and you it gives you usage of how to use this with pac, as well as the supported stacks. In this case, we've got heroku 18 and io buildpackstacks.bionic, and this will help the application developers choose what a stack that can accomplish what they need to do.

A

So, let's take a look at this real quick here. I've got an example: go application that only uses the heroku go and heroku profile build packs.

A

So let's go ahead and see what it would look like to add another build pack. I looked at the bill pack registry and saw that joe cuttner had a very useful sshd built back, and so I'm going to build this just like I did previously and we'll see that, in addition to the go build pack, we also get the build pack from the registry sshd and you can see it there in detecting. So it's ran to the detection phase.

A

I believe it just automatically tells cloud native build packs that it wants to participate in the build, and now when we run this image.

A

We should see a log line from the application after we pull the image from the registry, and you actually see here, even though I got an error starting the application that the ssh service was started, and it told us that the user is going to be heroku, which is the user that is defined on that heroku stack that I'm using.

A

If I wanted to get the area to go away, I could just go ahead and do the heroku thing and set a port with an environment variable and now my web service. My go web service here is running, and it also has a ssh service on it that I can connect to over the port 2222 and that's how easily you can use build packs from the registry strongly encourage everyone to check out that registry and find build packs that work with or replace build packs. You use today.

B

Thanks hi, my name is steven levine, I'm a core team member uh on the cloud native build packs project. um I work at vmware on vmware tanzview, and so you know, jesse just showed you kind of what a cloud native build pack build looks like what it looks like to build an application using build packs.

B

uh You know today, I'm going to go into a little more detail about what that build process looks like you know how you know how how does a buildpack build the application image, and I'm also going to talk about uh how the cloud individual pack model these kind of keeping these application layers separate, lets us patch, cves and operating system packages. You know not scale scenarios or just really easily. You know locally using the pax cli and also about how we plan to extend this api uh to.

B

Let us install additional packages kind of on a per application basis in the future and what it looks like to patch cvs. In that case too, um so just to kind of kick off. uh You know, as jesse mentioned, um to do a build. You have a builder image that has a build image and build packs, uh and you have source code and a platform like the pax cli.

B

uh You know it takes those artifacts and um you know, does a build and exports the new application layers on top of a runtime based image that you know might live on the registry, uh and so this this process is actually six different steps, and so there's there's a phase at the beginning called detection where build packs can kind of opt in or opt out of the build and also detect versions of dependencies. They need to install uh there's a restore phase that restores a cache um from the last build.

B

There's an analyze phase that kind of looks at the remote image and says you know it figures out if there are any layers that are already just you know, uh are already good, don't need to get rebuilt and can stay on the registry when the next image gets built, there's a build phase that builds new layers and there's an export phase that you know puts those layers uh on the registry to create the new image and then at the end, there's a caching phase, that'll kind of store any build time artifacts that might need to come around next time, and so just to give you an example of what a build looks like imagine, you have a node.js app say, has a package.json package.json lock and maybe some node.js source code and you've selected a you want to build this with a node.js build pack, and also maybe that you have a custom metrics agent and you, you made a custom, build pack that um you know you that installs your metrics agent into the application.

B

So in this case uh the you know, a node.js build pack uh could be a meta build pack like in this example. Like the a real build pack, that's like this is the the potato. Node.Js build pack is a meta build pack, that's actually just um describes a composition of other build packs, and so let's say your node.js build pack.

B

Is um you know, node engine build pack, uh yarn, build packet and pm build pack, and the configuration is so that they're two groups, it could be an installed node and um you know, run yard, install or install node and run npm install.

B

And if you combine this with the metrics agent build pack, you get two groups that you know include the matrix agent as well, and so what this build process looks like is, you know the first first group runs during the detection phase and the yarn yarn build pack, you know immediately opts out, says nope.

B

I can't I can't help here uh because the application doesn't have a yarn, lock file, and so that group fails and then the next candidate group comes along, and uh in this case the npndl pack says yep, there's a package.json, I see it's, you know that app needs node 12 and it says: okay, I require node 12., that's matched up with the node.js build pack that said node.js engine build pack that said yep I can provide node in the metrics agent. You know it's always just going to install a metrics agent.

B

So after that detection process the build process kicks off and the kind of cloud new bill, packs tooling, tells the matrix agent build pack: okay go ahead and install the metrics agent, then it tells the node.js build pack up the npm build pack said it needs node 12., go install, node 12, and so it installs node and the npm cli into separate layers, and then the npm build pack runs and generates node modules into its own sort of additional layer there.

B

And then you know, maybe the modules also get cached and kind of a local. You know under build cache and so on. The next rebuild uh the you know, some of those layers don't necessarily have to get rebuilt um because of that kind of you know analyze and restore phase. You saw before some layers can just stay around in the registry and um you know be part of the next image when it gets exported.

B

uh Some layers, you know, may get cached locally as well, and so uh you know given this api, one kind of really nice thing about generating these application layers that are you know, contractually separated from the rest of the operating system, is that we can patch cves in that operating system package layer very quickly for for lots of images, and we can do this with really minimal data transfer without without you know, even starting build containers.

B

And to do this, we rely on abi compatibility, which is this contract provided by operating system vendors. um uh You know like like canonical with ubuntu bionic, um where they, you know, provide an lts version of the operating system that you know just get security patches that uh you know have a strong guarantee that they're not going to change the behavior of code. That's you know linked against operating system code, and so you know heroku and cloud.

B

Foundry are examples of platforms that have you know, used lts operating system package, container distributions to patch cves at scale and production scenarios for a long time and so I'll kind of run through an example of what it looks like to patch. uh You know operating system packages in this model. So imagine you have a docker registry which has manifests, which are essentially container images and layers which are um you know the file system layers that those uh images point to so say you have three applications, each with their own.

B

You know application layers and you have a runtime based image. That's just that set of operating system packages when there's a vulnerability in the operating system packages.

B

You know we're going to update that runtime base image upload a new set of operating system packages and all we have to do to patch all those applications is make a quick change to their. You know: image manifests to point to the new set of packages. This doesn't require any additional uploading or any. You know it's just just a metadata change for the that those json files on the registry.

B

um You know you still have to deploy those, but that deployment process thanks to container d is also very efficient and so say you're. You know deploying the application to kate's after it gets built um you you know now you have all these applications running in your cage, nodes that are vulnerable from before.

B

All we have to do is you know, update the you know deployments for those applications to point at the new digest of the new image. Manifests that triggers the new set of operating system packages to get downloaded exactly once for each vm right, not per application, but you know each sort of very minimal data transfer.

B

Each vm just has to get newly updated packages once for every app on it, and then you know the apps will restart and with their new image, digest the point of the new layers, and so that's how we can patch kind of a large platform of many applications.

B

um You know without doing any rebuilds essentially, and so uh you know this looks a little different if you have customizations to your base image, so you know say your: you know your organization doesn't just you know, use ubuntu bionic for all your apps, but you also need some additional operating system packages or ca certs or whatever um the kind of process of of you know. Rolling out. You know, patches to cves in that case looks a little bit different, and so you know imagine you have this uh extra.

B

You know os extension set extra packages, the a certs whatever um when there's a vulnerability that kind of lower operating system package layers you know vulnerable, um but it's also important to note that we can't we can't just replace that operating system package layer underneath those extensions, because uh you know, unlike the application layers, that set of extensions, is, you know, um not kept separate from the base operating system.

B

It's changes to the base operating system that depended on the original files, and so we have to rebuild those layers, unlike the application layers, which we can just keep on the registry and swap things out from under.

B

So when this happens and we get a new, updated run image that has a new version of ubuntu bionic whatever it is, um you know we have to take that uh updated. You know we have to take that patch set of packages and you know maybe locally in a doctor container.

B

um Maybe you know a ci server or you know on case with conoco or something you have to reapply those you know extensions, maybe with a docker file, and then you know re-upload them to uh to the registry to create our new customized version of the run image. And then at that point you know we can do the same thing point all the application manifests new layers.

B

You know redeploy everything see the packages get downloaded, see the you know, apps kind of spin around and point at the new operating system packages- and you know just like before we patch the platform.

B

A much more interesting case to talk about here is what it looks like to patch operating system packages when you've just installed the operating system packages to specific for specific applications, and so there's a new proposal in the cloud native bill. Packs project called stack packs that are special, build packs that, on a kind of per build basis, allow you to install additional operating system packages. This is a really commonly requested feature.

B

You know you have a, maybe a ruby app that you know, needs image magic to do image processing, but you don't want to put image magic on all of your applications that use that base image, and you don't want to maintain your own special base image just to add image magic, and so this is something we'll be able to support soon, but it took a lot of thought to create.

B

You know an api that still preserved this rebasing ability or still made it easy to roll out cve patches to lots of applications at once, and so to do this. You know we took the you know a set of six steps that we had before we introduced a new step for build, called, extend and what extend does is it takes the you know, builder image and run image uh that were provided and um just uh you know, runs the stack pack on each of those images in separate containers to generate a new.

B

You know new two new layers. You know one for each image that have additional build time packages and additional runtime packages.

B

So the build can happen with you know: a set of build time packages, that's different from the set of extra packages that you know might get installed, uh the application that gets exported, and so, in the end you end up with an application that has new packages installed um to do this kind of rebasing process to to replace the you know, operating system packages when they're vulnerable, we had to get a little creative and so the way this works is, uh you know, and I'll kind of run. Through an example.

B

Imagine you have app one uh that has its own set of packages, but apps, two and three are still pointing at that kind of shared base image that everything else has uh when there's a vulnerability in that that operating system package layer um you know we have to rebuild.

B

You know the packages on top of it that app one is using, and so you can see in this diagram there's that orange layer. That's you know app ones packages um when that new kind of base image comes in with uh you know the cv patches. We have to take that base image and uh you know kind of um either in case run a uh you know. Some build containers or you know, run build containers in your ci system, or you know in the kit and in the case of the pax cli.

B

Specifically, we have to run some extra containers in parallel that um you know extend the uh runtime base image with new packages.

B

um Once we have our you know special base image for app one that would get uploaded back to the registry or in the local case it could just stay in the docker daemon and uh you know point all of our application images at the newly patched packages and just like before um you know everything can get redeployed by updating the you know digest on the cluster or wherever they're deployed, so that the images snap around- and you know we end up hatching all the apps in the platform, and so that's how we assault.

B

We kept that ability to patch cves at scale uh but still introduced the ability for individual applications to um uh you know, install uh operating system packages that are specific to those applications during the build process, and that's all we got um please check out buildpax io. If you want more information, we're super active on slack, it's slack.buildpaxio, so please come say, hi and feel free to join our mailing list too. We have a monthly newsletter um thanks. Everybody.