0:32 What is Docker Slim? (Origin Story & Purpose)

0:40 Hello, and welcome back to the Rawkode Academy. I'm your host, David Flanagan, also known as Rawkode across the Internet. Today, we are taking a look at Docker Slim, and we have two great guests joining us today. Now I do apologize for it's been a little bit late today. I had a skill run that I had to do, and not only was I picking up my own kids, I had to pick up the cousins too. It's been a hectic day, but I'm really looking forward to sitting down and chilling out with some cool technology. So feel free to say hello in the

1:09 chat. This is a livestream. We ask questions. If there's anything that you're wondering, others may be wondering it too. So type it into the chat, and we'll do our best to answer as we go. Now, guiding us today in our journey of Docker Slim is two fantastic guests. I am joined by Martin and Ivan from the Slim AI team. Hello. How's it going? Hello there. Very well. Hi. Doing great. You know, I've done over a hundred episodes now and you think I would learn. But whenever I have more than one guest, I don't know why, but I just say, hey.

1:40 How's it going? And then expect two people to try and work out how to sequence themselves. I really I just I need to do that better. But thank you both for joining me. Let's start with you, Martin. Can you say hello and give us that brief introduction into you, please? Sure. Hello. My name is Martin Winpress. I lead developer relations and community at Slim AI. And my background is, well, I'm a a longtime Linux nerd. And prior to joining Slim, I was a canonical, engineering director for Ubuntu. And prior to that, working on large compute

1:47 Guest Introductions (Martin & Ivan)

2:14 clusters for black box, aircraft aviation flight safety analysis for ten years or so. So my container background comes from sort of that that world predominantly. Awesome. And Ivan? Yeah. Well, I'm just a long time software engineer with a passion to infrastructure stuff and then with a little bit of software what's this? Like, site reliability experience as well. And I've been, like, moving from being a user, like, a long time user of containers to a finally, a developer of a container related technology. So since May, I am a part of the Slim AI engineering team while doing all things containers.

3:04 Awesome. Thank you very much. And we've had lots of hellos in the chat, and I believe one of your colleagues, we did have a low from BigPod. And I'm loving the icon, the BGP. So I am a bit of a networking BGP nerd, so I appreciate that all the time. Alright. Well, thank you for introducing yourself and sharing a bit more about you. Can we maybe start by just telling our audience what is Docker Slim? Who wants to tackle that? Shall I start with the origin story? And then maybe, Ivan, you can get in sort

3:25 What Is Docker Slim

3:34 of the technical nuts and bolts. So Docker Slim was created by our CTO, Kyle Quest, about seven years ago now. Actually, a Docker sort of hack fest event, and it it won I think it was second place at that event. So that was where it emerged. And really what Kyle the problem that Kyle was trying to solve back then was how do you make containers smaller without changing your workflow? So you're already producing your your Docker files. You're already producing your containers, and you want them to be smaller, but you don't necessarily want to move to another

4:12 distribution in order to get the outcome that you're seeking. So the idea is is that Docker Slim is a post processing capability. So you produce your containers in the normal way, and then you can produce these optimized containers as sort of a a follow on, event and and produce a separate art artifact. So in that in that sort of early time, the purpose of Docker Slim was to take your original container as an input and then create a smaller container based on the artifacts in that original container that has everything inside it that can actually

4:52 run your app, you know, be it a service or a web app or even a command line utility. So that's sort of the origin story on why Docker Slim does what it does in the way that it does it. But Yvonne can give you much more insight into sort of, you know, how it actually works internally and some of the other capabilities that it's grown over those seven years. Yeah. So the thing is that that, like, I'm myself being a developer. I've been struggling with this, like, bloated container images. Like, not because of security reasons. Like, security stuff,

5:18 How Docker Slim Works (Runtime Analysis & Sensor)

5:33 it became popular only, like, a few years ago. But, like, even five years ago, it was, like, a constant journey how to make images smaller. And for me, it always used to be, okay. I just need to be, I don't know, a wizard. I I I need to understand all these, like, distros, which are smaller, which are, like, bigger. Like, what what packages should I install? What what should I avoid? And I should not forget to clean up caches after doing some, like, you know, APT get installed and stuff like that. And, like, it was, like, a craft and and,

6:10 like, a hard earned skill. But then I just well, quite recently, I realized that that's not the only way. My actual my actual acquaintance with Slim Eye, it started from slightly different angle. I I was a long time fan of the portal of the SaaS portal we had. And only later, I learned that there is a tool behind it, and this tool is Docker Slim. And Docker Slim is well, it's kind of a magical tool. It's doing all this image modification for you, well, automatically. And the trick is that it does a runtime analysis of your containers.

6:59 So instead of now following some elaborate techniques to build an image, I could just kind of, go carelessly go with my favorite Linux distro and put there are all the packages I need for my application to run, all the development packet, all, like, the source code dependencies I need, get, like, a one, two gigabyte big image, then give it to Docker Slim. It will run it, analyze it, and produce a minified version of this image, which will be, like, 10 times smaller, and it will still work. But, of course, we need to be careful. Like,

7:45 Probing Explained (HTTP Probe, Exec Probe, Heuristics)

7:45 we shouldn't be trusting this tool blindly. Much like with any other with any addition to your Dockerfile, you wouldn't add, you know, like, a line to drop some caches and then don't check your final image one more time. Same with the Docker Slim. Like, once you minify your image, you still have to be, like, testing it as as a very final step. Yeah. That's how my kind of Awesome. Journey with Docker Slim started. Alright. I definitely have questions there. One, because you said automatic. Whenever I hear automatic, I have lots of questions that I wanna ask.

8:25 But before we get to that, I really wanna focus on why this is so important. Right? Like, if we think back to the earlier container days, something I seen, I was a consultant, so I never actually did any real work back then, but I was helping people adopt containers. And what I often seen is they were taking these very complex vagrant style builds and just decking them straight into a container image. Like, it was not rare to see people with seven, eight, 30 gig container images back in 2015, '20 '16. I've seen a lot of them. So much

8:59 so, I I I wrote an article on how to debug and make them slimmer using really crude tools. Nothing as cool as what we're gonna see today. But literally running an interactive container, running a command, doing a Docker dev, seeing what changed, and then tidying up and then trying to wrap everything together into these little concrete run steps. That was painful, but effective once you got the hang of it. Now what was interesting about what you said there is you says, I can just build my image without worrying about that size. Point Docker Slim to it and it does

9:33 some automatic analysis. So if we're gonna dig into this in any of the demos, we can defer it to LEN, but can we maybe try and understand what that automatic or what that analysis looks like? How does it work out, runtime dependencies? I'm assuming there may be some sort of syscalls or EBPF or something in there. So I'd love to know more. Definitely. I I think I have, like, a tiny diagram to show, like, the high level idea. You could open it, or I can share my screen with that. No. Is that on the HackMD, or do

10:07 you want me to go to the Slim AI website? What you Yeah. In the doc. It's the first. It's Slim. In the HackMD, it's there, but it's also now GitHub repository, which is, like, Docker Slim dash Docker Slim or slash Docker Slim. Alright. Docker Slim Docker. Me make sure I've not got a oh, I got a four zero four. Github dot com slash docker slim? Docker dash slim slash docker dash slim. The pepcack. So Alright. I have it. So I'm gonna share my screen. So this is your GitHub repository for the Docker Slim projects. Am I gonna say images or the read

10:43 Github Repository

10:48 me? Just scroll down. Just scroll down a bit. There we go. Sure. Here we go. Yeah. So as I already said, it's a runtime analysis. And by runtime analysis, I literally mean running the target image. So it's not like we will be examining the images content or the Dockerfile or whatever. No. Instead, we'll just I mean, Docker stream will just spin out this container using the so called fat image. I'm not sure how appropriate is this language for our auditory, but that's what it's called internally. Like, we take the original fat image, and we just run it.

11:35 And and Docker Slim, it's like a two two fold thingy. It's a driver app, the one you actually interact with, the app called Docker Slim. And the second part is a Docker Slim sensor. It's also a binary, and it's get injected into the target container as a volume. And then it becomes the pid one in this container. And it's like the thing that is actually doing the well, we call it monitoring. But, actually, it's some sort of of a a tracing. So it's literally a p trace call, like, in a loop in a huge loop,

12:25 and it takes the used to be entry point of the container, and it starts profiling it. And while doing this, it just keeps all the system calls that were made, analyzes them, and extracts the any path related parameters. However, this is not the only thing the sensor does. Sensor actually is pretty sophisticated piece of software. It has a lot of heuristics and different, well, sort of know hows about various, like, execution environments, like Python, for instance. Because Python, it's a good example. It has some sort of of a optimization with this, you know, like, pi

13:18 c files that are, like, compiled Python modules. And when a new module is imported, apparently, only the this PYC file will be accessed by the Python in interpreter. And the sensor actually knows that if it detects a file read that ends with a PYC extension, it should go and look up a corresponding source file. And it's full of such heuristics for, like, various languages. Well, another good example probably is when a sensor detects a binary file. And if this file is a binary execution file or a shared object, it would just go and check the l

14:05 LDD for this file and see all its dynamic dependencies to also look them up even though they might not be accessed during the execution. So in the end, when the underlying containerized application is done or we decided to stop actually probing it, we will have, like, a huge list of all the files or potential files that are actually needed for the execution of this application. And, yeah, that's how the runtime analysis actually looks. Okay. Yeah. Now one of the things you touched on earlier was your nervousness about things that do things automatically. And whilst there is some sophistication

14:44 Application Intelligence & The Role of Testing

14:51 and as Yvonne has just described, a lot of sort of heuristics, the AI in our, you know, company name, it is application intelligence rather than artificial intelligence. It's this knowledge of different language ecosystems and frameworks that's that's baked in. But you're quite right to suggest that, you know, purely automatic systems can be prone to error. And one of the examples we're gonna show when we actually get into the sort of the hands on examples later is how you can feed the Docker Slim process additional hints about where it should go and look and probe the application.

15:35 So I I'm not gonna I'm not gonna talk about that example specifically, but sort of one of the best things that you can do is if you've got integration tests for your application. So you produce your container image and you have integration tests. One of the best things you can do is when you produce your Slim container with Docker Slim is instruct Docker Slim to run those integration tests whilst it's observing the application because that should exercise the application broadly, hit all of the different execution paths, and gather all of that application knowledge in order to produce

16:14 a minimized optimized container that actually has everything inside it that the application requires to run. Now there are examples where that doesn't work. For example, we we did an example recently where we created the world's best image carousel app because we were experimenting with different technologies. And we did that on a livestream, and one of the things we discovered with that is because, the images weren't precached in the carousel, the container that was produced didn't have all of the images that should have been inside the carousel. So one of the things you can do is you can tell Docker Slim, actually, I

16:54 know I have static assets in this app. So in this path are my static assets. You should always include everything in this directory when you're minifying the container because I know everything in there you're going it the the application is going to require whether or not it got hit during the the the censoring and observation that that Docker Slim does. Awesome. Thank you for all of that context. I wanna make sure that I understood it, so I'm gonna try and surmise that all in, like, two sentences. But Docker Slim will run my container image, inject in a PID one, which then subsequently

17:20 Output Images (Scratch)

17:32 runs the command that my container image is built to run. It does Cisco monitoring, which means it's looking for things like f open for any file that is opened on that machine. It keeps track of some sort of graph or table, and then those are the files that are propagated down to the Slim image. This makes sense. Now I have a question about that Slim image, but I'll come back to that in a moment. You also mentioned you've got some smarts application intelligence, and I love that use of AI. Actually, that's that's probably the only valuable use

18:02 of AI I've ever heard. Now and what it's doing what it's doing is you understand Python. I mean, that's a it's just a problem for interpreted languages rather than compiled languages, right, where they have these different dynamics where they're trying to speed up that interpreter as much as possible by doing binary cache in some layer. So, yeah, you've got knowledge for Python. I'm assuming maybe Ruby, PHP, other things like that so that that just works as best as it can. You've also told me that I need to write tests, so I'm I'm obviously guilty of

18:31 taking a little bit lax on the integration test, but I can understand their You don't need to, but it will be beneficial. Because it increases the coverage of the code path for the Slim AI intelligence, which I get. Okay. So I understand the collection. I understand what it's doing. I see here on this image, which I love, is generate security profiles. The fact that you're doing, I'm assuming, seccomp and Cisco stuff is you can help build that seccomp profile. I don't know if that's true, but we can talk about that later. My main question right now is about that

19:01 image that comes out the other end. Now are you taking all those files from the table graph and then putting them into a scratch image, or are you using a small base layer that Slim AI has approved with some tooling or substrate? Like, what what does that output look like? It's a scratch. Like, literally a scratch. And the well, we will actually see it. If if you go through this tiny little demo, the very first one on our list, we will see exactly how the unified image looks like. Yeah. Alright. Well yeah. Go for it. What

19:36 you'll what you'll get is a single layer container image that only contains the assets that are required to run your application that came from the original image. Okay. So, yeah, it's scratch image where you just throw a lot of stuff at Okay. Nice. Yep. I think we should run through the first demo then when we move on to the the hands on component. And then if anyone in the audience has questions, please feel free to put them in the chat, and I'll keep any questions that I have coming as well. So I have a nice small machine here for

20:06 Demo 1: Slimming a CLI Image (CentOS + Curl)

20:09 us to work with today. I I just love typing h top in this machine, so I'm gonna do it one more time. I mean, I can even type. No. My terminal died. Uh-oh. I know what I've done. Oh, should I help you? Yeah. I've when I've added your public key, I've removed my public key. I'm gonna I'm gonna sit. Sit. That gets repaired, I I can I can give an example of a use case of Docker Slim that we see from our customers to sort of fill fill this space whilst you recover your access? Alright. Well, just quick quickly, Ivan, I

21:09 have sent you my public key in the private chat. Could you add it? Yeah. Thank you. Alright. Martin, take it away. So, one of the use cases that this is not the exclusive use case. One of the use cases we see for Docker Slim is this. Because you can take literally any image and make it small and optimized, and there is we're seeing a trend. So one of our colleagues, Aisha, did a she looked at over a hundred of the most popular containers at the end of last year that are published in Docker Hub and produced a report, a container report, sort

21:15 Docker Slim Use Cases (Dev vs. Prod Images)

21:43 of the the state of the container ecosystem. And one of the things that we spotted in that is the proliferation of test QA and infrastructure infrastructure tooling that makes its way into containers that are considered production ready that are published in Docker Hub authoritatively by the various projects and what have you. And it's also something we see, you know, software houses doing as well. So one of the uses is this. You can have large, well instrumented containers that are suitable for developers to use for local iterative development that have all of your tooling baked in. But then when you want to ship

22:27 those containers to production, you can run them through Docker Slim as part of your CICD pipeline in order to take that sort of dev environment and transform it into a production ready container suitable for deploying in the cloud, which has the shells and utilities and infrastructure tooling removed such that if there is unfortunate bug in the application that you're writing and that somebody is able to compromise that and land inside your container, they're now inside a sort of a barren wasteland where they have no tooling that they can use against your infrastructure to disrupt your operations

23:10 as opposed to landing inside sort of a richly instrumented container, which has all of the necessary tooling inside it for them to potentially island hop and disrupt the rest of your operations. So that's one use case we see. Transform your dev test, sort of well instrumented containers for iterative development into production ready containers. Alright. Awesome. Okay. Let's try this again then. So finally, I can run htop. So I spun up a pretty fun machine on Equinix metal just because I thought it would be fun. So we have a terabyte of RAM, which I'm excited to start using

23:51 because, you know, sometimes you need a terabyte of RAM and we have a 28 cores or threads at least. The only thing I've done Just a tiny note. It's not a requirement for the. No. It def it's definitely not a requirement. I I I I just wanted to have some fun. Usually, use twice bigger machines. Okay. So what have we done to this machine in preparation for today's demo? The answer is not a lot. I have installed Docker. We have kind available. We have not spun up any Kubernetes cluster, and I was also requested to make sure

24:33 that we had make and get available. I believe that was all the prerequisites. So pretty much just a basic into install with a couple of little tools on the top. Last question then. Ivan, am I allowed to is this the HackMD public? Is this something I can put in the show notes so people can follow along on their own time? Yeah. Pretty much, sir. It's nothing secret. Alright. And what I will do is I will just open it here as well so that people can follow along as we work through it. So there's that diagram, and we're gonna work through

25:06 demo one basics. So I'm I'm gonna work through a couple of these ones to get a feel for it. You just took and please feel free to add context and history and all that other good knowledge, and then Ivan is gonna do something bit more fun as well for us. I'll try. I've got a lot of confidence in you. Don't worry. So first thing we need the OC. First thing we need to do is pull the CentOS image. So this demo one is going to make a curl only image from a full blown CentOS distribution.

25:38 So this is that case where you have this chunky image, but when you go to prod, you wanna minimize that as much as possible. And so we we just want a Slim image. Yeah. That was pretty fast, which is good. So now we're gonna Slim it. And for that, we need Docker Slim. So I haven't installed that upfront. I rarely like to do that upfront. So we're gonna go through the install process too. Let me jump back to that GitHub repository. I'm assuming I just pull a binary from the releases. Is there a prepared I can. Okay. Is there a nicer way?

25:52 Installing Docker Slim

26:10 Can do that. There's also there's also a simple script which will do all the magic and grab the latest version. It's all in the read me and the in the installation section. I don't read read mes. Come on. Oh, I know. How tedious. Alright. Installation. So if you scroll down, there we go. Scripted install. If you just grab that, that will that will do what you need. Oh, there's a homebrew as well for people on Linux or Mac with brew available. Right? And a Docker image. Alright. I will trust your scripts, which I'm assuming is curl and pipe into bash. So Don't.

26:46 Don't. Yeah. Yeah. Well, essentially, it's just like two binaries, the Docker Slim itself and the Docker Slim sensor, and a move of these binaries to the, well, USR local bin, I guess. Awesome. Alright. So we've run the script. It was successful. We jump back to our tutorial. So now we're going to run Docker Slim, and we're saying that we want to build an image. We have a target, which is our base layer, I guess, and then the tag, which is what our small image is going to be called. Yes. I'm not sure what the issue to be probe

27:07 Running Docker Slim Build (Demo 1)

27:22 is. We can come back to that, but we do have a command to execute. So I'm assuming this is what is run for the intelligence to kick in, understand the files that are being used, and then spits out the small image. So let's kick that off. And I'm curious. You wanna give me a bit more information on the HTTP probe? Yeah. Of course. So one thing that haven't been that hasn't been specifically mentioned is this probing. So while doing the runtime analysis, we have an idea that the target image or the target container, it should be probed.

28:03 And probing could be, like, done in different ways. Probably the more since most of the time, we are trying to minimize our, like, services, like, web services images, the problem would be calling the HTTP API, and that's where the HTTP probe comes in. But you can also try to minify a an image for a CLI application, like in this example, where we just take the base image and try to minify it to keep only the curl executable in it. So in this case, we don't need HTTP probe, which is enabled by default, so we are disabling

28:44 it. Otherwise, the will start complaining. And instead, we use another probe, which is an exec probe. And the exec probe means run a certain, well, executable inside of the target container. Okay. I'm just Yeah. Skimming the output here. One of the things to look for there is, in caps, it says minified. So it shows you the size of the original image and then the optimized image so you can see what the reduction looks like straight away. Wow. So we've taken a base CentOS image, which is 231 megs, and we've optimized that down to just 13

29:28 meg of an image. That's quite an improvement. That's actually much larger than I much more of a compression than I expected, to be honest. And remember, these are the that compression point is in is is important. We used to get asked quite a lot, you know, are you just compressing the images? These are not compressed images. So this is just a raw image versus a raw image. Yeah. Maybe I just compressed there in the slightly wrong context. I'm I'm not I'm not criticizing. It's just that, you know, sometimes people think that all we do is compress images, and

30:05 that's absolutely not what we do at all. Yeah. Okay. So the things I think are interesting here, obviously, the size is dramatically smaller, which is nice. We have some sort of report dot JSON. I'm not sure what that is yet. We have something called X-ray if we want to learn more about the optimized image. Now we could take into each of those, but I think first, I should just run the image and make sure it still works. Yeah. You can you could probably go with the docker images first to really see the difference in size, I mean.

30:34 Docker Images

30:42 Yep. So here is my curl image, the 13 meg versus the latest, which was two thirty one. We can do a Docker container run r m cuntos curl. I can't remember. Does it modify any of the metadata, like the entry point, the command, the labels, the environments? Are are those all persistent? Is this Yeah. The entry point is persistent. So the shell is there, which is not something you usually would do. And the environment is persisted as well. And we still can curl. There we go. That's pretty cool. I like this. So if we run

31:24 history on it, what will we see? The same metadata and then just a blob ad for that. Okay. Okay. Let damage works. The history, I can see you've added the 30 meg blobs. There's a single layer. We have a report, and we have an X-ray command. What's the report? What would I use that for? Well, for the report, we can touch up on it later. Essentially, it's the information about the Cisco made and files accessed and maybe some extra stuff, like what was the architecture, like what was the detected Linux distribution, and what was, like, a language runtime environment.

31:47 Analyzing Slim Images with X-ray and the Portal

32:16 It's not something you check usually. Like, it's more for us. But, usually, like, alongside with this report, you may also find other artifacts, like like auto generated seccomp profile or FRR profile. So the concept of these artifacts, like monitoring artifacts or, like, intelligence artifacts being shipped from inside of your target container back to your host machine is an important one, but report is probably not something you are interested in at the moment. X-ray is, like, a more valuable thing to show. X-ray is for analyzing images. It's a command of the. And you can actually use it for any image,

32:56 X-Ray

33:12 not just a slimmed image like anyone. If you wanna investigate what's inside of a well, your production image or of some public image from Docker Hub or whatever, you can just run Docker Slim X-ray, the target image, and we'll show you some intelligence about it. Let's try it for the image. Yeah. I think we have a command here. Yeah. So Yeah. It's pretty simple. X-ray target and then export all data artifact. Well, the second part is not mandatory, but let's keep it. Okay. So is this just a list of all the files? By layers and also with some extreme information

34:03 about the layers. Yeah. It's kind of important information if you wanna understand your images. The problem with it is that it's not really presented well. It's not really human readable as you can clearly see. And that's why there is this second flag. Now since you used it, it also saved the same information in the entire archive. And we have a tool to actually visual visualize these X-ray reports. So it's for, like, savvy, Docker steam users. They can upload this tar archive to our SaaS portal, and it will show the same information but in a much,

34:53 like, more need representation. Okay. So if you wanna see it, you could SCP this archive to your machine and just open the SaaS in the browser just to give an impression of the contents of this image of, like, the layers and to the meta information. Okay. So let me pull that down, and then we've got a couple of questions in the chat that we'll tackle. So let me do s v p. We're at data artifact. Okay. I can I can feel the question from from Russell who asks, so is X-ray a bit like Dive? Certainly,

35:39 the content of X-ray exposes the kind of information that you would need to get that sort of dive like experience. But what we're about to show you now is the Slim AI portal. So you can upload this tar of the artifacts, and you will get a visual representation of what just happened. And in fact, when we started at Slim, we started implementing all of this doing the optimization in the SaaS platform, and the overwhelming feedback was what the heck just happened? What happened to my container? So, actually, we rolled all the way back, and the first thing we properly implemented in

36:26 the SaaS platform was really deep sort of introspection and exploration of container images wherever they might be. So the SaaS platform is a bit like Google for container images. You you can connect to all of your public and private registries. You can search them. You can access your containers, and you can do deep introspection and security analysis of those container images. And what we're about to see is just a tiny bit of what you can actually visualize with the container images by using Docker Slim to upload, you know, these artifacts into the into the visualization tool.

37:08 Alright. And we have one more question from who is asking if Docker Slim works on the m one Mac and if that's something that's coming. Yeah. I I have I have something to share. So there is a known problem with it. So it does work. Like, there is nothing unsupported currently for m ones. But when you are on when you are on an m one mug, you actually can have two different modes of container execution. If it's an R built, then it will be like a native run, But it could be an, like, a traditional

37:12 Docker Slim on M1 Macs

37:52 inter Intel x 86 run on an ARM processor. So we will have to use emulation for that. Like, what whatever Docker desktop on Mac OS actually uses. And in this case, the sensor has to be all the same architectures, of course. But the traditional or, like, the default installation method, it just pulls in two binaries, the Docker Slim itself for ARM and the sensor also for ARM. So if you try to run a non ARM container on an ARM machine, will inject an ARM sensor into it. And, of course, it will not work. But, yeah, but you can be smart enough and

38:39 just download the right version of the sensor from our GitHub and replace it on your machine, and then it will inject the. It will inject it, and everything will work. So it does work, but we have to fix the installation procedure. We have to be, like, smart and understand the target architecture of the container and inject the right sensor. And this is something well, if someone wants to contribute, we will just love this, but it's open source. But this is on our list, definitely. Awesome. Thank you for tackling that question. Hope that helps. In fact in fact, to dive

39:17 into this particular sort of thorny issue, we did a couple of livestreams recently where, first of all, we created our own derivative OS for the Raspberry Pi specifically. So we created a a container operate a a a of Ubuntu derived operating system specifically designed to run containers. So that ran in just 98 91 megabytes of of memory. And then we created our own optimized base images to then build our apps on top of as well. And then we were generating a whole bunch of different applications in containers using that, you know, because it's ARM 64 and ARM 32,

40:01 and then uploading those into our our platform and using Docker Slim to see where all of the rough edges were to sort of document where where the issues are, where we where we need to improve. K. Alright. So we should probably, like, speed up a bit if you wanna see some more advanced use cases. Yeah. Alright. We'll we'll tackle one more question very quickly, and then we'll we'll get back to the the terminal. So George Castro is at the chat saying, very big long comment. It's not gonna affect my screen. But it would be neat to

40:25 Adoption Drivers (Kubernetes, Bandwidth, AI/ML)

40:35 see Slim containers on something like a large Kubernetes cluster. I imagine there would be lots of bandwidth saving implications, especially when you have a cluster with lots of nodes. Is that like, what are the main drivers you see people adopting this kind of technology? That is a use case for sure. When we were at KubeCon, there are a number of people stopping by that were already using either Docker Slim or Slim AI specifically to address either sort of, you know, savings in bandwidth costs or in some cases, just being able to deploy their containers in

41:09 the first place. When you look at AIML containers, they can be multi gigabyte containers. They they sort of grow and grow. And Docker Slim can really help, you know, get those under control, get those into a manageable size so that deployments aren't just quicker, they're actually reliable. And also, you know, when you're pushing them around multi cloud environments, for example, can really save some sort of transit costs. Alright. Awesome. Thank you. Alright. Let's get back to the terminal so we can get through some more of these demos. So we've taken a look at Slimming down an image.

41:46 Demo two is something called advanced HTTP probing, where it's a more real scenario to modify the image of a Node. Js server with a nontrivial HTTP API. Yeah. Quick question. I I will look into the contents of the minified image first or not, which is fine also. We can just skip it because I think everyone already understood that that is, like, a one single layer image. Yeah. Yeah. We can do that if you want, or we can move on to the next demo. Which which you think is more fun? I mean, real quick. Let's I think because

41:49 Demo 2: Slimming a Node.js Web App

42:24 there was a question about Dive. Yeah. Yeah. So do you want me to export it and then open it, or is this what the artifacts are? Let's upload it to the It's take that artifact to the portal. Of course. Yeah. Sorry. Alright. Let's go to the Slim AI portal. So what am I doing here? I haven't done this before. Yeah. Just you see this X-ray mentioning under under the search box. Mhmm. It's exact specifically for Docker Slim users. Alright. So where did I download that to? That's the question. There we go. Okay. Oh, shiny. So Russell was asking about Dive. This is,

43:21 you know, a visualization of, you know, what the container now looks like. Okay. So you can see essentially clicks through the stuff or click on the filter, and it will show you some, like, brief information about the number of binary files or a number of the other type of files. Yeah. Yeah. Remember, it was a center as distro, and we tried to extract just curl out of it. So if you go to the filter and filter it by binary files, you will see actually how many dependencies a curl binary has. Yep. There's all the dynamically linked files there.

44:09 Yep. Yep. And if you look at the overview on the on the left there. So this is quite useful. You know, one of the things what you can do on the platform when you're actually using this platform directly is you can have a look at your containers in your registry and your Slim containers in your registry, and you can compare them side by side. So if you want to see exactly what happened as a result of optimizing your container, You can see a side by side view of this is what was removed. This is the security profile as a result of

44:46 the the minification process. For example, there are no shells in this container, and you see there files with special permissions. If you were to look at the CentOS base image, you would find, like any Linux distro, there's a bunch of files with set UID and set GID, you know, stickies on various binaries, and those are gone. So you at a glance, you can see sort of the changes that are made here. There was a shell in this image. Yeah. Because it was an entry point. So it's it's not like you execute curl. You do it through, like, a Sage

45:21 run curl. Yeah. Because I when we filter this by the binaries, there was user Ben Bash here. Yeah. It's not expected behavior because that's what's part of the entry point, which also could be changed if you are, like, careful enough. You can use the array version of the entry point, and then the shell is not mandatory. Got it. Cool. Very nice tone. Good for seeing what we have. I love the filters as well. I've been able to break that down to binaries and text. Very The idea the idea here is to provide the same kind of

46:00 user experience for your minimized images and for any other image. I don't really wanna feature the portal here. But if you can go if you go to the search, don't do it now. If you go to the search, you can actually search images, like, from any other public registry and then see exactly the same in the exactly the same UI on the same kind of information. Yeah. Let's get back to the more real demo. Okay. So step two is we're gonna take a Node. Js a Node. Js HTTP API, and we're gonna slim that down.

46:34 So I'm just gonna clone your Docker Slim examples here. Yeah. So the thing is that the previous demo, it wasn't really well, it was rather artificial. Like, I I don't think there are many people out there taking, like, vanilla Linux distro and trying to make it, like, I don't know, one tool image out of it. But this is much more real example. So this image is just a typical Node. Js web service with a nontrivial HTTP API surface. So it has, like, a bunch of methods. The thing is that we would like to make to

47:23 probe it not trivially by just calling, like, you know, the slash endpoint, but instead to go over all the exposed API endpoints. And we don't want to do this manually. Like, I'm not in, like, in in the mood to actually list all the endpoints. So instead, Docker Slim has one of its built in capabilities. It understands API specs. Like, if you go with an open API with the spec and point to it, it will actually understand all the available endpoints, and they'll try to probe them one by one. So let's try to run this example.

48:10 Of course, first, we need to make to build the fat version of the image. Then it just ran make, but make is not a part of of Docker Slim in any way. You can see that, actually, this make resulted in a very simple Docker build command. Okay. So we're currently doing this. And then you want me to do a run and a curl? Oh, yeah. Just do them one one by one one by one because the like, what what you're actually doing now, you are running one of our examples. So Docker Slim in a separate repository.

48:53 It has a, like, tens of examples how to minify different images and how to, like, go from these trivial scenario to more advanced one. So but all of these or most of these examples, they follow the same pattern. Just build the fat version of the image, run, see that it works, go build the Slim version, and run it and see that it works. So we are just trying to follow it. Okay. So we've run all those commands. We can see the build has built a one gig image from this application. And we ran it. I curled it, passed

49:33 it through j q. Things are good. I shut it back down. So the fun part is gonna be the make Slim build. Right? Right. And if I just take a look at what Oh, no. Please don't. No. Just run it and see the command. Yeah. Well, okay. And just try to find the very first command, yeah, after the after the make call. Yeah. So Docker Slim build, HTTP probe, and we point it to the spec YAML, which must have been as where the open API spec is. We tell it to crawl, and then we tell it the image that we

50:10 want to crawl again. And in the in in the chat that we share, I've shared a link to an article that I wrote that explains how to use probes and includes and what, you know, what they're used for and how to use them to achieve, you know, different results. So if you want to share that in the chat, then there's a a reference there that people can dig into to sort of look at how these things can be utilized. Okay. I will put this in the show notes for people to read as well. There. Lots there.

50:50 Thank you. Okay. So we did get a question in the chat, but I think, like, Paul just handled it. Russell was asking, so if your archive uploads to the portal private to the uploader, I e, if I had a private container, can I still use the Slim portal to analyze it, or would it make my image public? Well, we don't make anything public. It's just the metadata to describe the container that has been produced through the Slimming process, not the container itself. Yeah. That I think that's really important. We did not upload a container image to the

51:27 portal. We uploaded metadata about the container image to the portal. Right. But it also will stay available only for you. Yeah. Now that said, if you want to use the portal and you have private registries, you can connect to private registries and do those comparisons on the portal using, you know, authenticated sessions for either individuals or teams within your organization. But what we've just shown you, it didn't expose anything private to the world. Alright. Okay. Let's talk about less compression then. So we went from a one gig image, and this is telling us that we spout

52:11 out something that is 91 meg. Again okay. Just over 91 meg. That is a huge difference. I mean, that's massive. Yeah. That's a 10 times reduction right there. Yeah. Very, very cool. I like that. Yeah. We could probably achieve, like, a comparable result if we just go and carefully craft this production version of this image, like, using, I don't know, distroless Yeah. You know, like, this node. Js distroless from Google and, like, carefully copying all the needed packages and, like, doing the staged Docker build, whatever, will would be pretty much the same in the end,

52:32 Docker Slim vs. Manual Optimization Methods

53:02 like, on the same order. But it would take us, like, a lot of time to actually learn this, how to do this, and also then to to prepare the, like, accurate version of the image. And with Docker Slim, you just actually saw it took us, like, I don't know, less than a minute to produce the end result. And that that speaks to the origins of Docker Slim. You know? Keep your existing workflows and add this process on the end that does the optimization for you. If you're using something like Distroless, then now it's you need to,

53:43 learn the process of doing multistage builds, for example. If you're using Alpine, you need to learn the process of the sort of additive packages. I'm starting with something very small, and now I'm a distro maintainer because I need to know what are the packages that I require application requires in order to build up from almost nothing to something that supports my application. Whereas what we're doing is tipping things on their head. Start with something large that fully supports your application that you're probably familiar with or your teams are familiar with. In this case, I think this is an Ubuntu based container,

54:21 and I know you're using Ubuntu in the on this server here, and reduce that down. Now I've been recently experimenting with things like Alpine and Distroless and and also containers that do conform to best practice that are built on top of, you know, Debian and sent well, not sent to us these days, but, you know, Alma and Ubuntu. And seeing, well, if I take an Alpine and a distroless container, can I still optimize those with Docker Slim? And the answer is, well, yes, you can. And in the examples that I've been working with, I end up with container images that have

55:03 gone through the the reductive process. Starting with Ubuntu, for example, I get something that is 25 megabytes. This was a simple Python application that implemented a RESTful API. And I put the same app inside an Alpine base image and a distroless base image. And within one or two megabytes, the optimized containers were the same size. So you can optimize Alpine and Distroless as well even if you've well prepared those Alpine and Distroless containers because there will be things inside them that your application doesn't require. I did this last week with the team at Influx looking at

55:43 some of their containers, which are statically compiled go binaries inside container images, some of which are using Debian based images, some of which are using Alpine based images. And even on the Alpine base images, we were looking at a 20 megabyte reduction on the optimized container going through Docker Slim. And on the Debian side of things, it's a bit like what we're looking at here. It was, you know, hundreds of megabytes smaller. Nice. This seems like one of those things that's just almost a no a no brainer. Like, I I meet a lot of people that are

56:11 Important Considerations (Testing & Validation)

56:17 adopting containers and Kubernetes, and, you know, they don't know how to make their images smaller and optimize them. Really, they just wanna get shit done. They just wanna build an image and deploy their application and not worry about this. They're not container experts. They've not been doing this for six years. Sometimes they've been doing it for six weeks. And they've been able to say, hey. Just use this Doppler slim thing in your CI pipeline and then, you know, push through your image to a registry and then jump that. Like, I I I've struggled to see why more

56:45 people just would use this by default. Let let's let's be careful here. So so and, you know, like, every magic, it comes at a price. So, like, first of all, I have to be, like, fair and and just say it out loud that I used to be skeptical about Docker Slim s two, not because of its value, like, not because of the like, it's the value is huge. Like, if I can reduce, like, a one gig to 50 megabytes in no time, well, the value is huge for me. But I was skeptical about the quality of the results

57:24 because, well, I just don't believe a tool that removes 90% of my image and claims the end result, like, workable. Well, no way. But after learning how much of the intelligence is actually there is inside and and through how many different use cases we already over this past seven year been through, the success rate of the produced Slim images, like, to be functional is actually extremely high. I wouldn't expect this to be that high, But the number of stories we have on GitHub, the number of users we have in my our, like, cumulative community, and the number of reported

58:14 success stories, well, I still don't like, cannot believe in it, but it's it's, well, it works. But even with all this pretty high success rate, I would not advise anyone to put a Slim image in production without putting it through as thorough testing first. Right. Like, probably, the the very first step, and this is another motor of our, like, company, is you need to understand what's inside of your images. So not just slim them down, but also understand what's inside. So whatever your preferred way, that way, dive or Docker Slim X-ray and then upload it to the portal or

59:02 some like, I don't know, Docker Docker extract command. Whatever. Just go and see what's inside. Because you, as an application developer, probably know that, okay. I have this or I the this static assets folder. It should have been there, but it's not there. So probably the optimization wasn't smart enough. Well, you have to kind of be careful about the produced results. And if you detected something like that, Docker Slimming has, like, just tremendous amount of of knobs to actually configure these extra included files or some excluded files or, like, changed permissions, whatever. Like, it has a lot of

59:43 knobs. So you see, by default, the build command, it just accepts, like, two parameters, but you can go up to, like, a hundred to fine tune the end result. That's one thing. And another one, go like, push this image through testing phase. Like, if Docker Slim is a part of your CICD pipeline, it cannot be the last one before actually shipping the image. It should be, like, the penultimate one before pushing this image to acceptance testing. And then once it's tested, then you can go to production. That's, like, an important kind of, I don't know, point to to

1:00:25 focus on. Awesome. I mean, those points are also just good container hygiene as well, though. Like, people should be testing their images regardless of the tooling that they're using before it goes to prod. So it's good that you're kinda doubling down on that and just saying, like, you know, seriously, run tests against this container image because you just never know. And testing, it doesn't literally mean that you have to write tests and execute them. Testing could be done in production. Well, like, I've been doing it myself, like, in different setups. If you can limit the amount of traffic

1:00:59 that you send to this new version of the image, like, do the standard canary thing, you can minimize the image. You can deploy it and just either mirror traffic to it or shed some minimal amount of of traffic to it and see, like, your metrics if you don't have enough test coverage, which is also fine. Yeah. A good project for that is the captain project from the CNCF, which does auto remediation based on header header rates. Yeah, that would be a good a good partner there. Okay. We we we've been talking a lot. So let's get back to our demos here.

1:01:36 Let's take some commands. Yeah. So We could we could probably skip so let let's decide. We have two more. We probably don't have time for both. Like, one is auto generated second profiles. Since Docker Slim actually part of its intelligence is the graph of system calls, we can just leverage this data to produce a second profile to auto generate a second profile that would be a good starting point. I would not say it's the, like, second profile you would put into production, but it's a good starting point. And you can just fine fine tune it further and

1:01:49 Auto Generated Second Profiles

1:02:21 then ship it. That's one example we can see. Or we have something rather secret that hasn't been announced yet. It's Kubernetes support for Docker Slim. Despite the name, Docker Slim, we understand that there are different run times at the moment to run containers, and probably the most popular one is Kubernetes. So we are starting adding more run times, and Kubernetes is the first one. So which one? Well, I mean, you saw that Kubernetes one pretty well, so I feel that we're gonna have to do that. Right? Plus, it sounds like the riskiest one. So, you know, I do love a challenge.

1:02:46 Kubernetes

1:03:06 I mean, especially when I'm not doing the typing. Okay. Let's let's go for Kubernetes then. Alright. Shall I share my screen? Yeah. Let's do it. Window. Yeah. Works. It does? I'm just popping it up now. Alright. You're on the oh, can you hold on. Your window's a different size. Yeah. Can you I think your terminal's a bit tall. Can you Yeah. It's better now. I can see I can see the I don't know if I can see the the bottom, though. That's fine because I'm not at the bottom. Ah, okay. Yeah. Perfect. Yeah. Thank you. Yeah.

1:03:17 Demo 3: Slimming a Workload in Kubernetes

1:04:00 So before we we jump to to the to typing, as I just mentioned, like, Duckers Slim, it does runtime analysis of images to minify them. Like, in 2021, I think there is very few people who actually run their production images, like, in standalone mode. Most likely, your service has, like, I don't know, a bunch of sidecars and, like, several external API dependencies and maybe a database. Like, it's gonna be hard to optimize, like, to slim down such an image that actually requires five different other endpoints to be available. So the first thing we implemented for Docker

1:04:52 Slim was Docker Compose mode support because this is much more realistic scenario when you have your image surrounded by all your dependencies. So one of the things Docker Slim can do now is actually take instead of target image, take the whole Docker Docker Compose file, like the YAML file you you, like, normally write, And then you just tell it what image out of the all images mentioned there are to optimize, and it will start much like Docker Compose up the whole scenario and just go and do the probing for the target image out of these

1:05:37 images specified in this YARL file. But I wanted to show something slightly different. Pretty much the same thing could be done for Kubernetes. So what we can do, we can try injecting the sensor, this tiny little sensor of Docker Slim a workload that actually runs as a Kubernetes deployment or as a Kubernetes replica set or, like, daemon set, whatever you you want, and start probing it using well, whatever. And once we have all this intelligence in an artifact file generated, we just should ship it back from the cluster to your main driver app, which is like

1:06:27 the CLI itself. And then the rest is exactly the same as for any other scenario here, as for the stand alone mode, for instance. So we will produce a slim version for a workload that actually runs on Kubernetes. But once we get into the Kubernetes world, like, the possibilities become just endless. Because in Kubernetes, we can start doing, like, traffic shifting right in your cluster. Why not? Like, you you you if you have a deployment of 10 different port of 10 ports, you can actually try slimming it down right in production. Just start up the eleventh port,

1:07:15 send some traffic to it, optimize it, and slim it down. So let's see how it works. What I did here while we were talking, I cloned our main repository and built from the main branch because it's something that hasn't been released yet, but it already it's already been merged. So, like, nothing fancy here. Just go build. So now we have the Yeah. I think it's in the dist. And this is not on our machine. Right? No. No. No. This is that Intel machine. Okay. So now let's let's do a nasty thing. Let's move this this binaries to the

1:08:31 to place where they will be reachable. I think it's a fresh one. So if we now get back to these examples folder, there is a new example mentioning Kubernetes deployment optimization. So first, we have to create a cluster, and we have a kind already preinstalled on this machine, so this should be done in no time. But the cluster is not really a requirement. So you can use, like, any cluster. Remote one is also fine as long as you can run images on it and to to, like, keep still CP like things. So when the cluster will be up,

1:09:05 Create a Cluster

1:09:37 we will just deploy an application which consists of two of two components. The one is a deployment. It's like a regular Node. Js service that runs as a Kubernetes deployment. And another one is a Redis deployment. So we assume that this Node. Js application to run, it needs to call Redis well, to store some data or, I don't know, retrieve some data. It doesn't doesn't really matter. The idea is that you won't wouldn't be able to do a runtime analysis of such an application without having a radius running around. So let's review the application itself.

1:10:30 So we have, like, a server, which is, like, trivial. It's a API for the server part, and it has Redis package installed, and it creates a client. And then upon a get request, it goes and calls Redis and reports success. That's pretty much it. So it's packaged as a Kubernetes deployment. Like, nothing fancy here. Just a simplistic deployment that exposes a port. Like, this place called, there are such as to make these examples reusable, but, essentially, you can just put app names there, like, literally. And the well, it's fronted by a service. Again, create standard.

1:11:32 And a very similar thing for Redis. Again, trivial deployment running a vanilla server Redis image, and it's exposed via service. So we can make build the fat version of the image. And, again, this I hear you, I I know you hate the way the make files are made because they are full of includes, but in the end, they generate super simple commands. So, like, you see, it was just a regular Docker build. Yep. And now we can run it. And oops. No. Before running, we have to somehow deliver this image to the Kubernetes cluster. Otherwise, it will not be able to

1:12:32 Oh, we don't have kubectl. Yeah. I'm grabbing it now. Yeah. I've I've used many kubectl for everything, and I never thought. Alright. Download. While we are waiting, just notice how long it takes to actually inject this local image to a local Kubernetes cluster just simply because of its size. Like, these fat images, they are insane. Yeah. I thought you were gonna hit the test there and say, look how long it takes them to copy and paste some commands, but I'm glad you didn't. Alright. You should have kept control now. Sorry about that. And we are still copying the image.

1:13:34 How big? Yeah. We're done. Oh, yeah. If you if you're on and just see what's what's in there, like, we all know how Kubernetes deployment looks like. Right? Just a regular app deployment, a regular radius deployment, like, should be working. Yeah. We're trying to do some port forwarding and calling it with curl. And as a result, we get, like, a response. So okay. The fit version works. So let's try to minimize this image that actually runs right now in a Kubernetes cluster. So we have a command, a make target, actually, and it says, make me a slim version of the image

1:14:45 from the running version. So if you run it, you'll see what what's actually happening here. A familiar already familiar Docker Slim build command, but the target this time is not an image. Is not the local one. Like, remember, during the very first demo, you pulled the center's image first to your machine. But in this case, we're not pulling anything. We are just targeting a workload, which could be, like, a deployment or a daemon set or a replica set and maybe even Cruncher. I don't remember. That that runs in Kubernetes. And we just say what tech to use

1:15:32 the Slim version of the image. Like, we have this beautiful colorful output as as always. There was some probing in the middle, so it also port did like, Docker Slim driver app, it also did some port forwarding and probed. In this case, the probing was the standard one, which is quite simplistic. It's just a plain HTTP get request to the slash endpoint, but it was done. And then the the paged port actually was killed, and we and we got a minified version of the image. And it says it's 93 megabytes. So we can now do

1:16:21 docker images. We should see that the original version of the image was also around one gigabyte one gigabyte. Yeah. Right. And the minified version is 10 times smaller, and it was done inside of a Kubernetes cluster. So if you now stop the fed version and instead load the Slim version into the cluster, it should be much faster. And try to run it. I hope it will work. So, again, to run it, we just apply these manifests. So what do we have here? The fat one is still being terminated, and we have something for the Slim one.

1:17:19 So if we if we just look at this port, we should see probably we should see probably the Slim version of the image in use. So, yep, it's a slim one. Nice. But does but does it work? That's, I guess. Yes. It does. Magic. Very cool. Yep. This is not something that has been released, but it's already in in master. So it gives me some hope. Very cool. I like that a lot. So what's the the plan around the Kubernetes support? Is there, like, a broader mission that you have as Slim AI to bring more

1:18:11 Kubernetes Automation Strategies & The Future

1:18:20 automation with that inside of the cluster? Like, what I'm trying to understand in my head right now is, like, should I adopt Docker Slim at a CICD layer and build images and push the registry? Or is there gonna be, like, a secret sauce and cluster thing happening at some point? Like, how do you see these two different paths for Slimmington images differing? I don't Martin, do you have something to share? Yeah. So I think there's room for both. You know, the the original process of running something through CICD and producing a unified image that you run through validation and acceptance

1:19:05 testing, that's all well and good. But one of the use cases that was presented to us talking to people at KubeCon earlier in the year was they wanted to deploy the fat containers into their clusters. They wanted to have Slim containers automatically generated. They wanted to roll those Slim containers into the service requests automatically, then use observability to determine if they were successfully handling the load or not. If they were not, they wanted to fall back to the original containers and then report back the status of those observability reports in order to inform what needed to

1:19:48 be changed or improved about the minification process that those minified containers, the next time they they get automatically generated in the cluster, succeed with what they needed to do. So I think that was a very Kubernetes take on, like, how to do, you know, the minification. I've got this massive cluster of computers, and computers can automate away a lot of this for me and just tell me where stuff is broken, if things are broken indeed, and how to how to remedy that. So I I think there's there's there's a place for both, and I think the Kubernetes solution is very

1:20:28 much talking to those people that just love to use clusters to solve problems at scale. Yeah. I think another cool effect from doing it within the cluster. You know, I think I I my my own personal way here would be to Slim and CICD push to production, but I still think bringing Docker Slim into the cluster is good from the seccomp part of it as well. They've been able to do a continuous profiling of those test calls in my application and update the seccomp profiles in real time could be a shit. Those security challenges there because

1:21:02 what's a real request versus what's a fake request? I don't know. But, yeah, there's definitely some interesting stuff here, I think, for for playing around with it. So yeah. Yeah. Like, you know, like, not not everyone is on Kubernetes, and not everyone should be on Kubernetes. Yeah. Sorry. I'm sorry. I don't use Kubernetes. I don't run my blog on Kubernetes. I know I should be, but no. Sorry. Yeah. But so we have to support people who is not on Kubernetes yet or who want to be ever. So we have to target, like, all the other

1:21:38 scenarios. But for people who is on Kubernetes, they are probably like, they probably know what they are doing. So for them, we could provide, like, a much more sophisticated solution. Like, it could be an operator. It's not something that we, like, really have on on the road map. I'm just, like, thinking out loud as an engineer and as someone who actually have been operating Kubernetes services. Like, we could ship an operator that would be doing this image optimization, leveraging Docker Slim under the hood right in your cluster. So So you could, I don't know, annotate your services, like your

1:22:17 deployment that you would like to see slimmed down. And the separator would be watching from all the new deployments having this annotation. And then do this optimization right on production cluster by spinning up, like, one extra port for every deployment and sharing some traffic to it, removing it if it produces, like, too much noise and, like, stuff like that, and then generating an image for you, pushing it to your registry, and triggering another CI pipeline to actually ship a Canary deployment of this slim version of the service and see if it's not noisy. Like, if it's not too

1:22:54 noisy, maybe just continue to the full on rollout. So, like, as I already mentioned, like, possibilities are endless once you get into this Kubernetes world because, like, you all can automate everything. And that's just why I love Kubernetes, like, because of its API and automation capabilities. You've started the Kubernetes trolling now in the comments. So I love the group that's going on with case at the moment. Yeah. I've been using Kubernetes a long time, and I still have no idea what the fuck I'm doing either. So there was a in line with what Ivan was saying, a

1:23:32 big pod left a comment as well to saying that, actually, the complicated images where the probing could be tough, bringing us into the cluster and doing it over a certain period of time with real user traffic. That's a really good avenue as well. And another one I thought of as you were kind of talking is, like, third party images as well. Like, you know, I I don't really build NGINX even though I know I can make it smaller. I don't really build Redis and Kafka or all these other post queries, MariaDB's, etcetera. Because the images are built and they're official.

1:24:02 And, yeah, they could be smaller. So I wonder if bringing for third party images that may cluster, bringing Docker Slim into the cluster actually is quite an interesting way to do it as well. And because I don't I don't have a build pipeline for them, and I don't want one for them either. If I had that demo well, in fact, you you did it, which was the the curl example at the very beginning. We have another example which uses the NGINX official image, which does exactly the same thing for NGINX. So if you're using NGINX in production as

1:24:32 a reverse proxy, you can automatically generate, you know, a much smaller image that's in there much faster to deploy and push around your infrastructure. Yeah. That's that's And the the reduction in size was similar. It was a 10 x reduction. Yeah. I think all the reductions we've done today seem to have been around 10 x. That's your magic number, and it's a good one to have as well for for me to starting point. Ten ten to 30 times is usually what we see depending on the sort of application language framework. Awesome. Alright. Well, I mean, I'm happy for people

1:25:05 Wrap Up and Community

1:25:05 to keep trolling Kubernetes in the comments section, but I think we should probably see any last words, any last questions. If you wanna get them in now, audience, now is your last chance to get questions for Martin and Ivan. Do either of you have anything else you wanna share before we finish up for today? No. Other than to encourage people to if they if they like what they've seen and and that and they see some benefit for using it in their own environments, give it a try. Docker Slim is fully open source. It's available on GitHub. Just come and grab

1:25:38 it and test it. Have a play with it. We're always interested to hear new and interesting and unusual use cases. So if you find an edge case, tell us about that as well. So hey, Nuno. It's good to see you. So, yeah, try Docker Slim. And, also, the Slim SaaS platform is also free to use as well, which can do all of the things that we've just demonstrated to you in a web platform and connect all of your public and private registries. So give a try. And if if you have success there, then maybe take

1:26:12 a look at the SlimSaaS platform as well and see what additional insight you can get about your container images, including security analysis, for example. Alright. And, of course, like, if you have any further questions, like, just join join our Discord. Like, we are always happy to to chat about this. Even if it's not a question, just just you feel like talking about containers, join our Discord. Alright. Awesome. Well, thank you so much for for joining me both of you. It's been an absolute pleasure learning more about Docker Slim. All of the demos work as well, except

1:26:50 for the stuff that I broke by not having control available, but, you know, we got past that. And so, hopefully, we'll speak again soon. Have a a great day. And to everyone watching, thank you. We'll see you next time. Thank you very much.