1:29 Introduction to Rawkode Live and Host

1:29 Hello, and welcome to the Rawkode Academy. I'm your host, David Flanagan, also known as Rawkode across the internet. Today is an episode of Rawkode Live where we get hands on with some sort of cloud native or cloud native adjacent technology. And today, we're taking a look at how to improve your build times for Docker images. To join us and guide us today on our session, I'm very excited to introduce Michael Irwin from the Docker DevRel team. Hey, man. How's it going? Doing well. It's good to be here with you today. Awesome. Yeah. I'm really excited. It's always good

1:51 Guest Introduction: Michael Irwin (Docker)

2:05 to and you can take, like, a real problem that pretty much every team has and then give them some insights and solutions on how to make that problem disappear, which I'm I'm hoping will be the outcome of today's session. Absolutely. Could you just take a minute or two and, you know, introduce you if anyone has got familiar with you and your work? Absolutely. So as you mentioned, my name is Michael Irwin, and I'm part of the developer relations team here at Docker. I've been with Docker working full time for about two years, but even prior to that, was actually one

2:37 of the the Docker captains for five years. I've been in the container space for quite a long time, and it's been fun to watch it grow and go through all of its bumps and evolutions and changes and and and just the this entire ecosystem over the last, you know, seven years, at least that I've been a part of it. I also teach a a class. I've developed courses at I teach at Virginia Tech, so courses on containers and Kubernetes as well too, so I I do a lot of teaching those that are brand new to the space

3:05 as well too, and it's a ton of fun to kinda work with industry experts, but then also those that are just getting into the space as well too. And there's obviously a huge chasm between them at times too, and it's figuring out how do how do we better connect people, but it's a it's a ton of fun. So but, yeah, I'm I'm excited to be here today and talk about our our newest product, Build Cloud. Awesome. Well, we're definitely gonna talk about Build Cloud and get hands on with the demo. But, you know, maybe we

3:27 Overview of Recent Docker Releases (Scout, Wasm, etc.)

3:32 impromptu question that you had no idea it was coming. Right? But, you know, Docker's actually released an awful lot over the last three, six, and nine months. Do you wanna just give us a TLDR of anything that's top of mind that you think is interesting and you wanna share with people? Yeah. Absolutely. And so as you mentioned, you know, Docker has been doing a lot. I think most people still think of Docker as mostly Docker desktop or even just the Docker engine and just the ability to run containers, build images, etcetera. But over the last yeah. As you said,

3:58 over the last year, we've been trying to expand the the portfolio and adding more products and more services. So the the first new product that we released, and we announced it going generally available back in in DockerCon in October, was a new product called Docker Scout that really focuses on building a secure software supply chain and analyzing your images, making sure they they meet organizational policies, and and it's it's actually pretty solid, pretty awesome to to work with as well too. So, you know, a lot of people think of, like, image vulnerabilities, and that's just one

4:30 element, but also, are you building on trusted and approved base images for your organization? Do you have open source license issues that you need to worry about? Maybe your organization has the policies of, you know, our images by default shouldn't be running as the root user, and so, you know, are your images meeting those policies? So lots of really cool stuff there. And then, yeah, Build Cloud is our our newest product. But between all those, there's been lots of other new features and capabilities, Docker Debug. There's been Docker Net Panda. Yep. Yep. To help bootstrap new projects,

5:06 compose watch. I mean, there's just been a lot of Web essentially. My favorite. My favorite. The whole Wagons stuff. Yeah. Absolutely. So yeah. And, I mean, it may be hard to keep up with at all. I mean, I'm trying my best to keep up, but, you know, Docker has definitely embraced, I don't know, tooling and experience, developer experience. And they really seem to be tackling really a lot of those challenging problems that people experience, whether they're new to container tech or whether they're experienced. Right? There's a lot of frustrations and it's nice to see Docker tackle them

5:38 head on. Even, you know, the the failment and stuff for people that are running Mac like like me. For dynamic interpreted languages, that has been a pain. And I was really shocked when I used a large PHP application and the performance is night and day from where it was Oh, yeah. Twelve months ago or or two years ago. So yeah. Awesome stuff. Yep. But we're not here to talk about all of that other awesome stuff. We're here to talk about Docker Build Cloud. And let's start with a a bit of context or a problem that I think everybody's probably had at

6:01 Introducing Docker Build Cloud and the Problem of Slow Builds

6:10 some point in their container latest. Right? And that even s k c d has a meme that's often swapped out from it's compiling and we're running about our chairs sword fighting. And I see all the time with my Docker images building because these things can be can be slow and there's a lot of foot guns, which I'm not saying Docker Build Cloud has got effects, but there are a lot of foot guns for people that are new to containers that don't understand how layer caching works and then cache invalidation and all this stuff. But use Docker in it and it's gonna

6:41 help you avoid some of them things. But Docker build cloud can give us some dramatic performance numbers. Your blog post that I was looking at prior to this episode says it could speed up a build by up to 39%. That is not a trivial number or performance and benefit. So do you wanna give us a bit more details on what Build Cloud is Yeah. And why people should pay attention? Yeah. Absolutely. And and I'll even I'll just do one small correction. The the blog post, so it wasn't 39%. It was even 39 times. So there's

7:03 Build Cloud Features & Benefits (Shared Cache, Multi-Arch, Speed)

7:12 Of of course, you know, numbers can be, you know, a little hand wavy at times, but we have seen pretty significant improvements with with the build speeds. And so, yeah, a a couple things that you mentioned there. So when when I'm building a a container image, there's there's a lot that goes into that. And especially if I'm building on my local machine, if it's the first time I've done that build, I'm having to do the build from scratch. And we're we're looking at those builds, you know, there's lots of dependencies and compilation or, you know, just depending on what language

7:42 and what tools you're using. You know, if we look at the layers, my source code may be layers seven and eight, but I still have to build, you know, layers one through six at least to populate my cache and and get things in a good place. And, you know, if then we look across an entire team of developers. If there's 10 developers on a team, well, then that means all of those, you know, initial layers are having to be rebuilt across the entire team. It's like, at the end of the day, there's a lot of this layer caching and whatnot. Like, how

8:12 can we make it so that one person can build once and then everybody can benefit from that shared cache environment? So that that's kinda one aspect of of Build Cloud is this, by having the shared runner, one person can or even a CI pipeline can populate the cache, and then everybody else can benefit from it. Another thing that we heard quite often was, you know, for larger projects, compilation may just take a long time. Either there's lots to compile or, you know, if I'm on a team that's looking at multi architecture, for example, and now we're having to do AMD sixty four

8:43 and ARM sixty four, but, you know, maybe I'm on Apple silicon, so I'm having to emulate one or the other. Maybe it's a Rust project, and it's just slow. Yeah. Exactly. And, you know, so there's just times in which, like, can I just attach beefier machines to my builds? And and and so kind of internally, we call it remote where it's kind of remote, but it kinda feels local. And so in many ways, that's what Build Cloud's trying to do, like, give that remote experience to, like, just enhance the the local experience with remote capabilities and remote

9:15 horsepower, but then, you know, everything still works as you would expect it to locally. Okay. So would it be fair to summarize all of those amazing features you're just gonna cover to is like just Docker Build Cloud is a remote build kit, build service for anyone building container images. And the fact that there's remote means that you can do really cool things with the caching. That's kinda what I'm taking away from this. Yeah. Absolutely. And so, yeah, the the remote yep. Shared caches, native multi architecture, and hopefully, as as you see there, hopefully, it's the 39 x speed improvements that you

9:23 Summary: Build Cloud as a Remote BuildKit Service

9:53 get. That native multi architecture. Yeah. And maybe that comes out in the demo. Right? But I'm gonna I'm curious. When I do Docker builds and I'm using Docker build cloud, is that understanding that there's multiple jobs that need to be run and literally scheduling them on different machines with the architecture native without any emulation whatsoever? That's exactly what's happening. So, yeah, when I do the build, basically, it's handing off to the a a build kit endpoint that then is basically saying, alright. What builder behind the scenes actually needs to take care of this for me? And, yeah, delegates

10:25 the works to either AMD sixty four or ARM sixty four, and there may be a few architectures that support or, you know, machines that support other architectures as they come out. But, yep, everything runs natively. Nice. We got a not a question, but a comment from Russell on the chat. So he's got a project. It takes thirty minutes to build, and the presses sound greatly. Yeah. I mean, when I used to work in an office, I loved those comp completion times or build times because that meant you can go get a coffee, you would chat

10:52 to people, but now they're all sitting at home. I think they're just sat watching them, and and maybe that's just me. Or I I think maybe I'll squeeze on an episode of, you know, the office or whatever. Well and and, yeah, that's one of things that, like, I'll admit as a developer at times, it's like, enjoy those those downtimes, and, yeah, I can pull up YouTube for a little bit or, you know, whatever else it might be. And so, like, on one hand, I'm like, okay. Great. This means I have to work more. Is this actually what I want to

11:18 do? But at the end of the day, like, that's that's where I love actually spending my time building applications, solving problems, etcetera. So in in many ways, it's like, how can we keep you in that flow more? Because, yeah, then it takes more time to get back in, you know, all of the context switching is just fine. You're framing us too nicely. I think we need to change the flow. Well, actually, you're taking away developers' coffee breaks and their Netflix. Why do you hate developers? Yeah. When you put it that way, gosh. Alright. Awesome. If you do have any questions,

11:48 people are watching us, please feel free to leave them in the comment section on LinkedIn, on x, or on YouTube. We will do our best to tackle them as we go today. Alright. So I mean, you've already sold me on this. I want this native compilation across different architectures. I want it to be faster and I wanna build cache that works across multiple machines. I very much take advantage of working at home to the point where yes, I'm in my office now for a stream and I do some work here. But I've got kids. I'm at dance class

12:00 Transition to Hands-on Demonstration

12:19 and I when my daughter's there, I get my laptop out and I start working on that. Not having my build cash there is really painful when I'm on a four g or five g connection and I'm struggling to build on the bait, so I need to or whatever. So I want this to be better for me well. And I think with that, we should dive into your screen share and start to take a look at how people can take advantage of this this cash flow awesomeness. Let's do it. So was trying to think about the opposite

12:48 of snake oil there was, and I couldn't think. I was like, what is it? It's like just a awesome product. So Yep. Alright. Here. Let me screen share, and we'll go get this window. Alright. Alright. We see the Docker Yeah. Homepage or the Build Cloud homepage at least. That's right. So I just wanna start here. You know, it's it's a good place for anybody else that's kinda just getting started with with the Build Cloud. And and so, yeah, there's lots of the the same things that we talked about are are scattered throughout this page as well too. One of the

13:23 things I will call out, and this is kind of a a a fun little thing there, there's this savings calculator, which you can kinda say, you know, how large is your team and salary and how much time spent, and you can save this much or whatever. And, of course, you know, there's a lot of wiggle room in here and whatnot too, but it's it's kind of a fun thing to just play with there. And there's some little fun demos here of kind of a local build versus build cloud. And, actually, you were just talking about, you

13:48 know, taking your your laptop to dance class and whatnot. Let's see. It was actually back in October. I was flying to San Francisco for GitHub Universe, and I was working on a a React app or whatnot, and I was like, man, just downloading all the the YARN dependencies and everything while on a plane Yep. Haven't helped me kind of thing. Like, it's gonna take forever on that Wi Fi. But I was like, you know, let me switch to Build Cloud and did my build and everything. And so all of the the build actually happened in the cloud, and then it's just downloading

14:19 you know, instead of making thousands of connections to download everything, it's just, you know, those couple image layers, and the build was significantly faster. So it was kinda fun to say I'm doing a build using Build Cloud while literally in the clouds and and everything, and it and it worked out really well. It was pretty cool. So with that, I'll jump over. So Build Cloud has its own web UI, and when I jump in here, the the first time I come in, it'll walk me through building a builder, and that just takes three to four minutes just to

14:40 Setting Up Docker Build Cloud (Web UI, CLI, Docker Desktop)

14:49 spin up all the infrastructure and everything. But once that's in place, you're basically given this screen that says, hey, here's here's how to configure everything. All you have to do is do a Docker login, and then you basically set up a what's called a Buildx builder. And if you've never used Buildx, Buildx is a kind of the latest, greatest build engine and provides a lot of really cool capabilities. We can talk about that later, but basically what we're doing is we're just creating another builder here. And you'll notice that the difference here is that we're specifying a driver

15:24 of cloud. Now this is one of the the new things that we've we've brought to to Buildx here. And I just give it a name, and then from there, it sets up all the other magic behind the scenes. It connects to the endpoint. And then from there, I can either, when I specify a build, say I wanna use that particular builder, or I can just say, hey, just use that builder by default, and so build x use sets as the default and goes from there. And then so all my builds, all my other, you know, even

15:53 if I just do Docker Compose up, which we'll we'll do here in just a second, I can see all that. Now one of the other things that we did here, because, you know, a lot of us are probably very comfortable in the CLI, but not everybody is. I can jump in the Docker desktop as well, and there's this new builds tab that shows up on the the left hand side. And and here I can see lots of detailed output. I've got a filter on just for my failed builds right now. Let me put that back. And so I can see

16:00 Live Demo: Using Build Cloud for Faster Builds with Shared Cache

16:23 my build history, and I can go up into builder settings, and I can see all those different builders, and I can basically just click connect to builder and then, you know, use this as my default builder. So I can do everything through the GUI. Under the hood, it's basically just running those same commands that the build execs create, but if I'm more GUI oriented, that's an option for me here as well too. And so with that in place, then really, I can just jump into a project, and I'm gonna switch over to Versus Code here. And

16:53 I've got just a a really simple React app. Nothing too crazy. There's a Docker file that does multistage build. It'll, you know, build my my React app and and take the compiled assets, transpiled, whatever you wanna call it, the the the final assets and put it into NGINX container. But I also have another stage here that I can use for development, and in Compose, that's what I've got here, that it's gonna use that that particular stage. So even though I've got this other other builder here, what's pretty cool about this is if I and I'll even show that

17:27 there's no smoke and mirrors here. If I do an image l s, you see I had no images locally on my machine, so there's no pre built caches or anything already on my machine here. But if I just do Docker Compose up, it's gonna say, well, hey, I need to build this particular image here, and you'll see that it's using my my DevRel builder here, and within just a couple seconds, you know, downloaded all the layers that were needed, and now I've got my application up and running. K? And I didn't have anything already downloaded,

17:56 and it was, you know, spun up pretty quickly. Now I can start my development right away. And so what's cool about this, again, is I don't have to change any of the commands that I'm using. I don't have to add additional arguments. I just simply run Docker Compose up, and the Compose will use whatever the configured Buildx builder is, and since I've set my Cloud Builder as the default, it'll use that. And and what's also cool about this then too is that, again, if I'm in an environment where, hey, maybe I don't have good internet connectivity right now, and

18:20 Switching Between Cloud and Local Builders

18:26 I don't want to use it, and I just wanna stay local, then I can just switch my builder back to my local builder and continue on my way. So again, I've got the choice of do I want to use remote, do I want to use local, and I can pick and choose between each of them based on what my current needs are. And I don't have to change any of my commands, I just change my configuration. So maybe I'll pause there for a second. Any questions coming up yet? Oh, I think you're muted. Or maybe I could maybe I just can't

18:48 Q&A Period / Technical Difficulties

19:01 hear you. The fun of livestreams. Yeah. This one, do a little song and dance. Right? Not hearing anything yet. Okay. Yeah. Go for it. So maybe while he's doing that, I'll I'll just continue chatting through some of the demo whatnot. And so maybe if you throw the screen share back up, then we'll here we go. So so, yeah, I can do a compose up here. A normal build first. And, also, I'll just call this sample React app with the final dot to do my build here. And, again, we'll see that this is going to use

20:45 the that cloud builder. And since I built this earlier, k, on the the remote, again, using this remote environment, all of build layers are cached here. And so even though I didn't have the image locally, I haven't built it locally, anything of that sort, since it's a shared cache environment, I can leverage that cache even though, again, I'd had nothing on my local machine. And what's cool about this then is that if I pass this off to a teammate and they clone this repo and do the build, they're gonna get the same cache, and it's gonna build immediately

21:17 as Now if I go in here and I change some of this to, you know, hey, let's make this more exciting, add some more exclamation points, and then do another build, in this case, obviously, that's gonna the cache is gonna be a miss here, and we'll actually see the the build. I'll download those layer, the the new layers, and good to go here. So, again, by having this remote environment, any any member of my team that's building with this is helping populate a cache that then the rest of us can all leverage, making our builds theoretically faster.

22:01 I'm still not hearing you. Weird. Now I'm wondering if it's or maybe if a viewer is watching, maybe confirm if if it's just me or not. I guess I can pull up the stream too. That's why I do a little song and dance. Okay. Can't hear either. Okay. I at least pulled up the stream from a couple minutes ago and confirmed. Okay. Yeah. We finally silence. Hey. Hey. Getting getting some fun comments coming into chat. Strange. Yeah. I still can't hear you. I'm just gonna have fun with chat here. So our host is muted here.

26:07 Interesting. Okay. Sounds good.