Cloud Native Buildpacks Conference Talks, 4 Sep 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Building Docker Images with Cloud Native Buildpacks - Ben Hale, VMware & Terence Lee, Salesforce

Description

Don’t miss out! Join us at our upcoming events: EnvoyCon Virtual on October 15 and KubeCon + CloudNativeCon North America 2020 Virtual from November 17-20. Learn more at https://kubecon.io. The conferences feature presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.

Building Docker Images with Cloud Native Buildpacks - Ben Hale, VMware & Terence Lee, Salesforce

In today’s cloud-native world, Docker Images are the lingua franca for platform portability. Unfortunately creating great, secure, and efficient images can be difficult and time consuming. In this talk, you'll learn about Cloud Native Buildpacks, a high-level abstraction for building application images. Buildpacks are a standardized tool for creating images in a secure, reproducible, and efficient manner. As an application developer, you don't need to know the best practices for command ordering to optimize layer reusability. As an operator, you will minimize the security hazards developers my introduce. Come learn how buildpacks meet developers at their source code, automate the delivery of both OS-level and application-level dependency upgrades, and help you efficiently handle day-two operations.

https://sched.co/Zeu7

A

Good afternoon everybody and welcome to building docker images with cloud native build packs. My name is ben hale. uh I lead the java language on all of the cloud platforms at vmware with me is terence.

B

Hi, I'm terence. I work at salesforce and work on the heroku platform there and help co-create the bill packs api.

A

So we're all here today to learn about how cloud-native build packs are going to help us build images that we can run in production. But all of this is framed in the discussion of what does it mean today in a modern way to deploy and distribute applications into production.

A

We see over and over again that as the languages and frameworks that we use proliferate within our development teams, it's becoming harder and harder to treat application artifacts as the immutable artifacts that pass to our systems gone are the days when we can build a jar and pass a jar through ci pass it out through cd, pass it to a production team. We just don't get to do that anymore.

A

Many of the common languages that we see people using are actually interpreted rather than compiled. This means we're distributing source repositories effectively rather than actual compiled single file artifacts. At the end, we also see a new trend in developers wanting to be able to both test their applications in the environment that they're going to run in.

A

This is a really good idea, but also have full control of that environment that their applications are running in, rather than relying on another team to configure that, for them we've seen so many times a development team gets everything working on their local development systems gets it all working in their qa environment throws it over the wall to production where something is configured differently and everything breaks. So all of that leads us to the following statement.

A

Docker images are the lingua franca for platform portability.

A

What do I mean by this effectively? What I'm saying is that this is the new immutable artifact that we want to pass around and it's great because it contains everything it contains the operating system file system. It contains the application file system. It contains the command that we're going to actually run the application with it gives us a nice self-contained environment that runs exactly the same everywhere.

A

That means it's going to run the same on your laptop. It's going to run the same on the data center. It's going to run in the public cloud. It's going to run on your local docker demon. It's going to run on kubernetes, it's going to run everywhere exactly the same.

B

Docker files are probably how most people create the docker images that ben's talking about and they're great they're easy to use. They provide a lot of control to developer, but it's a double-edged sword. It requires a lot of work to harden these docker files for production use, and you have to resort to thing what I like to call dockerfile as an example. This the official alpine python docker image, is 137 lines long and the main run command. That does.

B

The bulk of the work is about 80 lines, a single run command that is 80 lines, long to configure, install and install and set up python.

B

So what if you could actually go and create a good docker image without doing all that work, all that dockerfile gymnastics that most people are doing today, so ben's going to go ahead and demo that.

A

So the question terence has asked is what, if we could create a good docker image, but without result resorting to docker file gymnastics. So what we're going to demonstrate here today is the pac cli.

A

The pax cli is a command line uh utility created by the cloud native, build packs project that creates an application image in this case called applications demo from some sort of source. In this particular case, it's the demo01 snapshot jar using a builder, so a bunch of build packs in this case called builders adopt open jdk.

A

So we'll go ahead and kick that off. We see it go to work, we say: oh, there could be 16 build packs, but five of them are going to participate. Here we look at what exactly happens in this particular.

A

Build what we see here is that an adopt open, jdk build pack has contributed a whole lot of things, but specifically it's contributed a jre, because this is a java application and it's contributed some other stuff to make running inside of container a little bit easier. An executable jar build pack has figured out what the command line for this particular application could should be. It's pretty conventional java, setting its class path, settings java, ops and then calling a particular class inside of it, and then because we know that this application is a spring boot application.

A

It can come in here and do all sorts of things such configuration given its web application type. In this case, it's a reactive web application, contributing some things around spring cloud bindings slicing up the application into multiple slices, adding a bunch of image labels to the image itself, and then, when it's done, it goes off and creates a particular image. In this case, it's called applications demo tag latest, and we can see that all of that build took only 12 seconds to do.

B

So that's the demo of cloud and bill packs and cloud and build packs, are a cncf sandbox project.

B

That's built on top of a technology called build packs and millpacks have been running in productions on millions of apps since 2011, ranging from applications that are startups all the way up to enterprises and what they do is they provide a higher level abstraction on top of the standard docker file, allowing app developers to do what they do best, which is delivering business value to their customers and we're able to do this with a set of features like faster builds by using various layers, not having to kind of rerun instructions that don't need to be run um being able to reproduce those images in a reliable way.

B

The build packs themselves that are being used to actually build. These images can be modular and composable um and, at the end of the day, we're producing a docker image similar to how dockerfile also produces docker images, and that makes them portable via the oci standard. That ben was talking about before, so we're going to go and take a deeper dive or second look at cloudant, build packs and kind of look into these features in more detail.

A

So terrance just listed off a whole bunch of different things that build packs can do that are kind of advantages. You might say over something like a normal doctor file. So let's take a look at the first one. What does it mean to reuse layers? So what we're going to do is we're going to rerun the exact same command we ran previously, so we're going to do that build we see. Detection pick the same five build packs, but this time we see something even more interesting.

A

We see that as we analyze the previously existing image, it noticed that there was a bunch of layers that already existed. We download the metadata, not the data from those layers, but just the metadata which gives us the ability, in this case the adopt open, jdk, build pack to say, hey I've already delivered version 11.0.8.

A

I don't need to do it again. What I want you to do is create an image but use the layer that already existed in that image same thing in the spring boot application. I already did the work I needed to do because of the web application type or around spring cloud bindings, so I don't need to do those again.

A

I don't need to transfer that data and what we see now is that that same, build that took more than 10 seconds last time has immediately shrunk to six seconds, so we're probably seeing it being twice as fast the second time around, but that's not the only kind of advantage we can get that kind of layer reuse. We can also take a look at what exactly is going to be used when builds happen.

A

So if we do a pack inspect builder, we're going to take a look at that adopt open, jdk builder that we used before we said that build packs, encourage composability and modularity, and we see that in this particular builder we see that there are 15 different, build packs that all participate when we build an image. The first one here this is the adopt open, jdk build pack, you can remember, we saw the executable jar buildback participate.

A

We saw the uh spring boot, uh build pack participate as well, and there are many others that chose not to participate but could have if we'd, given it a different set of of input.

A

So if we see that this is sort of how the builder is going to behave, what if we took, took a look at a different builder.

A

Let's take a look at a bellsoft liberica builder bellsoft liberic is just another distribution of java like adopt open, jdk or oracle or sap or any of a number of others, and what we'll see is because of the way the build packs are built in a modular way and the way we compose them most of the build packs 14 of the 15 build packs that were in. There are exactly the same as they were before, but we've been able to replace just the java distribution that we want to use say we support contract with bellsoft.

A

We might want to use them instead of adopt open jdk. So now, if we do that same, build.

A

But with the bell soft builder, this this whole time or this time we see the same five of 16 participating, and what we see here is that the belt soft build pack gets involved. It contributes its version of 1108.

A

If there's any changes to the way memory calculation is done or certificates are loaded, those all are recontributed as well, but only this build pack has changed. If we take a look at the spring boot build pack, we get to reuse those previously cache layers, because this build pack is orthogonal to the java build pack itself.

A

So we see all of these build packs um participating during a build. But what is it exactly that they do build, so we're going to use a utility that I absolutely love called dive and we're going to take a look at the layers inside of an application.

A

So if we take a look at the first couple of layers of this application, you'll start recognizing that file system on the right as the kind of thing that typically gets built when you're installing a new operating system installing a set of packages. What you're actually seeing here is a standard, ubuntu, bionic installation with all of the packages that normally come with that. We then take that stack image which basically that base os, uh and we will instead we'll then start putting stuff on it.

A

The first thing we put on it is the launcher, and the launcher is a bit of the life cycle that we leave inside your application, that's responsible for guaranteeing that the environment is set up right and that we start your application with the proper command line. Every time you try and run with this particular image, but then we also start seeing the build packs themselves are contributing things. We see the bellsoft librarica build packet installs. This thing called a class counter some stuff around java ops.

A

Eventually it installs an entire jre inside of this particular image, 140 megs there, but we go even further than that. We can see the executable jar does some stuff with the class path. That's what we see over here on the right with this class path environment at launch. We see spring cloud bindings go in. We see the thing that it's going to make a change, because this happens to be a reactive web application type and then eventually we get to the point where we see our application as well.

A

In this particular case, spring boot applications are really well known. They understand what it means to go into an image, and so they actually can be sliced up. We effectively have a layer that has all of your dependencies on it, another one that has the boot loader application. If there were snapshot dependencies, we put that on a layer, another layer uh here that is the classes of your particular application.

A

In this case, the demo application all of these end up on separate layers, and that may seem like a little bit of overkill, but this is really really useful when it comes time to transferring data, it means that the data that changes a lot things like your application, as you are developing it can be separated much smaller 5.3, kilobytes versus 20 megs of dependencies, and only that 5.3 kilobytes would be transferred out to edge nodes, would be duplicated inside of registries things that don't change as much things like your dependency list, which you might only change once a quarter or once every six months, basically can be reused and deduped and not transferred to edge nodes much more easily because you're not sort of polluting it.

A

With this kind of application code that changes quite a lot.

A

So that's what we see in here, the build packs, are all creating these layers that contain certain bits of the file system. All those are glued together and a normal standard, oci image, and we say that that oci image is a portable. What does that mean? It means that I can do a docker run tty and we can literally use this document or this docker image that we created to start an application and docker.

A

Here we go a running spring boot application and, while I'm not going to demonstrate it completely, you'll have to trust me on this one. We also.

A

Can use that exact same image as you see right here. This is normal kubernetes deployment. Descriptor says exactly what my container is going to be sets, for example, the the probe. So we know when the application is live and ready, but we're going to use the exact same image in this particular case. Going to start the exact same uh start command, it's going to do it with the exact same environment variable set. All of that's embedded inside of that image, it'll run here, it'll run on heroku it'll run on cloud.

A

Foundry it'll run on any platform, exactly the same as long as that platform understands docker images, that's really really uh awesome.

B

So all this is great for your. You know app as an application developer you're, you know, building these images. But what do you have to what happens when you actually have to run these uh images in production? What do cloud name bill packs, get you, um and one of the nice things is that with planet build packs and the way we build uh our applications through the layers and stuff um that you saw get contributed in a very specific way.

B

Is that how we build them is actually standardized, and that provides a lot of benefits to operators who need to actually deal with stuff like compliance and security of your application image once it's running in production um and that allows us to help with uh kind of like two main features that we provide as part of the climate build packs ecosystem.

B

uh One of them is build materials which shows uh what is actually in your image, and so this can help with auditing or kind of your client story there, because you can without having to crack open your docker image.

B

You can actually see what's in that particular image um as well as a feature that we like to call git rebase, um so think, along the lines of like what you do when you have a git rebase, and so the osa image manifests back, uh has ordered pointers for various layers, and this is different from kind of the older docker image, v1 spec, which uh treated them as kind of this tree-like structure, which meant that uh if you're changing that, like kind of from line when you're gonna do an operating system managed update, you actually have to rebuild the entire tree because, like your parent route, tree is now different.

B

So you can't like make any assumptions about kind of the child properties, they're, all all invited and validated.

B

But one nice things with this new oca image manifest. Is that they're pointers? And so that means that if you have stack images built on top of um operating systems that comply to this application, binary interface compatibility. So, basically, when you update uh your operating system from one version to the next, if the avi interface hasn't changed, you don't actually have to rebuild all those layers um on top of kind of your stack image because they complied the same avi um interface. And so what this looks like in practice.

B

uh If we take a sample, node buildpack, that's building a node application or at the node.js layers complied this avi compatibility against this operating system, and it once we need to update this operating system.

B

It's going to have an api compatible operating system update, and that means we can actually do a lift and shift and just rewrite the manifest layer which is this json text file with pointing to the new layers which massively speeds up the image update, as well as the push to the registry when we actually have to push these layers up um and this scales really well, when you do this across an enterprise fleet of you know, thousands.

A

Or tens of thousands.

B

Of images so ben's gonna go ahead and show uh what kind of these day two operations look like, uh while using cloudmate.

A

So this next demo here is gonna focus less on application developers, although this information that we're gonna see is pretty interesting and it's going to focus more on what your applications can do to help the operations teams that are around you. So one of the really really interesting questions that a lot of security teams and compliance teams really care about our.

A

What sort of inputs went into the creation of this image that I am currently running right now as an application, and so one of the tools inside of pac is what we call pack inspect image. So inspect image allows us to take a look at some information about the the image itself so give it a second. It comes in and tells us of all of those 15 build packs. Here were the five that were going to do their thing right.

A

We saw bellsoft liberica, executable jar, all of these things participated and we can even see which versions they were and we can see the command that was going to get run. This is all embedded in metadata on the image. One of the key things about this information is we get this not by downloading the entire image. All you know, 100, megs or whatever it is. We download a very small amount of data, a couple of tens of k effectively that contain all of this.

A

It allows our um compliance teams to iterate over large numbers of images currently in production and ensure that they are what they think they are find out if there are any existing vulnerabilities.

A

So this is the kind of information about what exactly was run to build this particular image, but we can go further than that as well. You can say pack inspect images and we can take a look at something called the bill of materials. So whenever an image is created by specification, the uh the build packs can contribute and say: hey here are some things that we put into this particular image.

A

So, for example, we can take a look and see that we put in bellsoft liberica version 11.08, here's where we would have downloaded it from if we needed to download it. If you want to validate it, here's the java256 hash of that we can even tell you what the license was for this dependency that we've put into your image.

A

If you want to do sort of license compliance kind of testing- and we do that for absolutely everything that we put into the build pack itself, our memory calculator, the class counter things about how we configure link local dns, uh all sorts of things that come from the build packs, but even beyond things that come from the build pack. So, for example, here are a set of dependencies that your application contains. So if you're running a normal spring, boot application, probably you're, writing a rest api that returns json, payloads.

A

Well, guess what you're probably going to use jackson so which version of jackson is in your application? Well, you could download the image boot it up. Take a look inside. You know, use a fine command and like go and be a shell, but that's actually really expensive time and transfer wise right.

A

You've got to move a lot of bytes to do that or you can take a look at this metadata and the bill of materials that we've attached and we can find out that you're using jackson, core version 2.11.0 again, if you aren't trust trustworthy of our metadata here- is the hash you can go and validate. That hash is exactly the version that we claimed it was, and it goes beyond that right, you're, you're, a spring user right. So let's go ahead and take a look down here in spring spring. Boot version 2.3.0.

A

If you want to go a little bit further, you might take a look for something like spring core is really common, we're using spring core version 5.2.6.

A

So, in addition to the metadata about how we built this, we also have metadata about what exactly we put into it when we did the build, but also what we were presented with, what our application was when it was built, we don't have to sort of look back and try and uh corroborate this with a give and commit and figure out what the answer is. We look this up during the build and we put it on as metadata that can be inspected in a very light and quick way.

A

The final thing that we uh we talked about as an operator feature is something called rebasing and so rebasing, as we said, is the act of taking a um a a bunch of layers that comprise things that are contributed by the build pack, as well as your application that sit on top of an operating system and move all of those to a different version of the same abi compatible operating system. So in this case, I'm going to put the time command on the front of it.

A

So we can find out exactly how long something like this takes, but we're going to do a time pack rebase we're rebasing that applications demo we're going to change what the run image is underneath it in this particular case we're going to a different version. This version is 0 0, 4 7, which is a slightly newer version than the one we've been doing, the the demo on so far.

A

So if we take a look at what the time says, we we managed to change the operating system underneath this entire application in 1.39 seconds right. If we were working against a registry. This is a weird oddity of using a docker demon. It's actually much slower to do it locally against the docker demon.

A

If we were doing this against a real live docker registry, even a docker registry over a network link, we would have expected this to be closer to a quarter to a tenth of a second to actually get this done, because we're transferring back and forth very small bits of metadata, like on the order of three or four kilobytes of metadata versus hundreds of megs of data being transferred.

A

But, most importantly, we didn't execute any of the rest of the build we didn't have to uh untar or unjar the the application we didn't have to untar the jre we didn't have to do any install around a file system. We transferred almost no data back and forth.

B

So that's great we've been doing a ton of stuff with this tax. Eli and pac is really just a platform, but really you know built for your local cli um for your local development, um but that's not the only place you can run bill packs built packs are out there uh in the wild um being used by the azure spring cloud uh on google app engine, it's running on roku.

B

You know vmware and kpac, uh even all the way to uh java frameworks like spring boot that are using it and really targeted towards developer productivity, and so we're going to demo and show what it looks like to actually, if you're a spring boot developer, what it takes to actually just build a docker image that is ready for production.

A

So, as terrance said, spring boot can act as just another platform, the same way that we consider the pac cli to be one platform. The same way we consider vmware's kpac to be a platform or heroku to be a platform. It turns out that platforms can come in all shapes and sizes. One of my favorite platforms, given my history as a member of the spring team, is actually spring boots. Maven plug-in can be a platform, so in this particular case we're going to go ahead and run a maven command.

A

Maven test skip spring boot, build image, and what this does is it goes off uh to maven, as you normally expect it to, and it actually builds this jar file for us right. The last thing we see is here is where it's jarring up the application itself, and then it immediately kicks off a build right like internally. Without you ever leaving maven, uh you could have done the same thing with gradle as well. We see that exact same output, detecting a bunch of build packs, contributing the jre to the layer in this particular case.

A

It's jerry8 because that's how we we built this particular application. We have this command that we ran all spring boot. Stuff gets added image, labels open container, and we see that it actually created this particular image. One of the really cool things that uh building an image this way does because it's inside of a running, build system. It can learn things, it knows which version of java you actually want. Is this a java 8 application? Is it a java 11 application? Is it a java, 14 application?

A

It knows the name of the application you specified what this was as part of maven's metadata and, most importantly, it knows what the version of this particular application is. So we could run docker run tty uh demo.

A

Zero, zero one snapshot, that's what it's called and we see this spring boot application that was just built.

B

So, in closing, uh cloudant build packs, brings a ton of advantages to build packs uh in this docker image world uh through some of the features that uh we've showed throughout. This talk like faster, builds um reproducible images being able to reuse the various layers and what have you? In addition, it provides because of our standardization and higher level, abstraction things that docker files simply can't do and that's not because docker files are efficient.

B

It's just that our standardization allows us to have things like composability that you just can't have with all that power and flexibility. uh Things like the build materials that the bill packs can provide as well as uh stuff like movie. Basing saving you a bunch of time when you actually need to do image updates across your entire fleet um and it's common goal.

B

Packs are available through local development through tools like pac, as well as various cloud providers out there, and one of the big goals that we're trying to achieve with this project is new developers where they are, which is right at their application, where they're focused on delivering value to their customers, so go out and try climbing and build packs a day. We have version point 12 of the taxi line, just go through brew, or what have you to go?

B

Install that pack cli uh go to our documentation, we're fairly active on slack, where a lot of the kind of conversations around development outside of github r, as well as join our mailing list, where you can get the announcements and various things as climate build packs, are being developed.

B

Thank you and we're now open up for questions.