0:30 Introductions

0:36 Hello. Welcome to today's episode of Rawkode live. I'm your host, Rawkode. Today, we're gonna be taking a look at Kaniko, a tool for building container images in Kubernetes. Now before we get started, this is a little bit of housekeeping. First, if you're not already subscribed, rude, but you should subscribe now and click that bell. This helps other people find the content, plus you'll get notifications for each of the new episodes coming up. Also, if you're not watching live and you have questions or you want to make suggestions for new technologies to cover on Rawkode Live, then you can join

1:07 the Discord. There's a few hundred people that a few hundred people that are now talking about cloud native Kubernetes and everything in between. So come and say hello. And lastly, I wanna thank Equinix Metal, my employer, for allowing me to do this. You can check out Equinix Medal using the code Rawkode. This will get you $200 of compute. That's anywhere from fifty hours to four hundred hours depending on the machine that you choose. So, you know, have fun or use it wisely. That is up to you. Now today, to introduce us to Kaniko, I am joined by from

1:33 Introducing the Guest & Tejal's Background

1:38 the Google Container team. Hi there. Hi, David. Thank you for having me. No. The pleasure is all mine. I'm looking forward to playing mechanical today and showing that to our to the people that are watching. Do you wanna just take a moment to tell us a little bit about yourself, and then we'll get started? Yeah. Sure. So my name is Tejal. I was born and raised in India. I came to United States for my master's a decade ago maybe. And after completing my masters, I've been working as a software engineer. I've been working at Google since pretty much

2:17 last five years, mostly in container developer experience and container tools. I'm currently the maintainer of Kaniko, and I'm actually working on another awesome container development tool, which is Scaffold. I manage Scaffold at Google now. Awesome. I'm a big fan of Scaffold as well, actually. It's a really cool tool and Kaniko. So I'm looking forward to Yeah. Pulling both these tools off. I actually have someone from the Scaffold team joining me next week to do an episode there. Yes. That'll be awesome too. Yes. Alright. Do you want to just will we start with a a little bit of

2:55 What is Kaniko?

2:57 a brief introduction? It's just like what is Kaniko and and what is it for? Sure. So Kaniko was started at Google maybe around three years ago as a way to build images in your cluster securely. Before Kaniko, people used to actually install Docker inside their cluster. And, you know, Docker inside the cluster is not a great idea. It has a lot of, you know, security concerns because you expose the Docker socket. So anybody could tap in and, you know, just just take advantage of the Docker socket and end up, you know, corrupting your Kubernetes cluster or, you know, send a malicious

3:45 run malicious code or anything like that. So for that reason, Kaniko started as starter project one of the projects that, you know, in Google, you end up giving to a new engineer. But we found out that it has a lot of potential. That was something that was missing in the market, and people adopted it and became one of the popular tools now. So Kaniko lets you help build container images inside the cluster without the need of Docker. So what it does is, it spins up a a container and runs all the commands in your Dockerfile.

4:27 It'll run it on the operating sys on the container itself and detect what changes a particular command run ended up doing to your file system and would build image layers based on those changes and then produce Docker image. Okay. I think I understand some of that. So let me try and repeat some of that back. So I I understand that running Docker inside of Kubernetes is is not a good idea because we have the Docker socket that allows people to do bad things with their containers, particularly in the older days where Docker had to run its root. I know there's some changes

5:09 and advancements there. Then Kaniko came along and tried to provide a a secure way to do this. Now so does Kaniko still launch containers for each of the layers or is it doing something magic within the existing container? Like, I'm I don't think I understand exactly what's happening there. That's a good point. So let let's dig into the internals of Kaniko. So you actually spin up as a bill as someone who wants to build image, you would spin up a pod, which runs a Kaniko container image. Kaniko itself does not spin up any container images

5:27 How Kaniko Works (Internal Mechanics & File System Snapshotting)

5:47 or or any containers to build individual layers. What it does is on your container, executes the commands in your Dockerfile. So if there is the first command of your, Dockerfile is from, then it'll go and, given that the Kaniko container has access to your image repository, will go pull the image, the base image, and then, you know, untar it and extract it. Then it'll take a snapshot of your file systems. Now we'll run the next command in your Docker file If it is meta command, which is just like, you know, sending work directory or setting user permissions,

6:33 then it doesn't do anything much. It'll only update the image manifest and metadata in the image. But if it is a docker run command, which actually ends up manipulating the file system and adding new files or generating new files, Kaniko will run that. It's as whatever user you've set it to run as, and then it'll take a snapshot of your file system now. So with the snapshotting mechanism, it can detect what were the changes that happened between your first command Dockerfile command and the next Dockerfile command. And then it'll pull up all those changes, create a image layer

7:17 out of it. Okay. So in my naive understanding then, is it fair to say that Kaniko is, like, doing a char root and with the layer file and then running a command? Is that in a really simple term? I'm sure there's more going on. But In the simple term, yes. It is actually executing the commands in your Docker file and figuring out what changed. Okay. Cool. That actually helps a lot with just the the basic understanding of of how it's putting this together. I think it maybe is important to note for the the viewers at home

7:52 then is that there's nothing particularly special about a container image. Right? They're just literally what you said is a bunch of tarballs that happen to have some JSON manifest data to tell it ordering and semantics and metadata and that's it. There's nothing particularly special. Cool. Awesome. Then I think what we'll do is we'll jump over to the screen share and we'll try and build a container image. I say try. I should have more confidence, shouldn't I? It's like, we will build a container image. Alright. So this is the Kaniko GitHub repository. It's available at github.com/googlecontainertools/kaniko.

8:20 Building an Image

8:32 There is lots of documentation. I noticed as I was kinda poking around earlier. I'm assuming we're just gonna go to the tutorial to get started. Does that sound fair? Let's do that. Alright. Okay. So the getting started tutorial or are we scrolling down this page? I think let's get to the getting started tutorial. Okay. So prerequisites. Kubernetes cluster, check. I have a Kubernetes cluster. I also have Docker for Mac if we need to fall back on that for whatever reason. I do have a Docker Hub account if we need to get the token for that.

8:46 Setting up the Build Environment (Required YAML files)

9:13 I'll do that sneakily over here. But I think two texts on the prereqs, which means we can just go jump straight out and build a container image. Yeah. Before that, we need to actually mount your source code onto, you know, your Kubernetes clusters. So I think the several next configuration files that are there, the pod dot yaml, the volume, and the volume claim helps you do that. Okay. So let's see what this is. Let me just zoom in on that a little bit. So this is just a part called Kaniko that runs the Kaniko executor.

9:59 Just looking for some volume there. Yes. So, Kaniko, go for it. The interesting part is from line eight onwards where we are actually mounting your secret as well as we are also mounting storage where you would end up mounting the source code that you wanna build. Okay. So if I'm using a remote Kubernetes cluster, is that a problem? No. It shouldn't be. Alright. Okay. So you just want me to copy this and save it locally. Right? Yeah. Yeah. Okay. And this is just gonna be our pod dot yama. I did pop open codes so we can just

10:46 the new file. Save as pod dot yama. And we need the two other ones. So here is my volume. So just so that I understand. Mhmm. So I understand. Is there a CLI element to Kaniko that I execute on my local machine? No. Kaniko cannot be executed in your local machine. It has a binary, but the the Kaniko design is based on the fact that you're running it inside a container, and it ends up entering your root file system, manipulating your root file systems, and deleting certain things and, you know, registering certain special directories. And if you run Kaniko

11:12 Why Kaniko Must Run in a Container

11:51 on your local machine, we might end up deleting certain files, which is something that you would not wanna do. Yeah. That is, like, a terrible idea. Okay. So I do see that we're using host path here in a persistent volume. So if I'm working with a remote cluster, how do we get the data into that location? That is a good question. I think this this tutorial actually assumes that you are running in a remote cluster. Let me go back and check. Oh, no. Okay. So once we get the SSH into the cluster, I think, just to provide the build. Yeah.

12:04 Troubleshooting Initial Setup (Volume Issues)

12:42 Okay. We can do that. Yeah. That's not a problem. Okay. And it wants me to create the secret. I'll do that when we get there then. So first things first is we just want to go on to one of the machine. Mhmm. Okay. I guess if I use Docker for Mac, that's not really a problem. No. If if you wanna run Kaniko in right now as a docker container, it's just one docker in command. It's not part of the tutorial, but it is on the read me, and we could try that first and then switch

13:21 to this flow. I I think we can just use the so the Docker for Mac shops with a Kubernetes API that handles all the volume as far as. I reckon we just go with that and see what happens. Okay. So we'll we'll stick with the tutorial. I'll just pop up in Docker. I'll make sure I'm on the right context. I'm just gonna try it as it is. So if I just that also means I won't have to set up the registered token secrets either. So, you know, double win. So what we want here is oh, I don't know the MAC pass. I

13:53 really should know that. Let me get that. So I'll call this context. I think that's what the tutorial roughly said and then I'll copy this. And that should just work. I'm saying that as a question and a statement at the same time. So you can tell how confident I am. But I reckon we'll be okay. And if not, we'll work around it. Okay. So Okay. This says okay. It says create Kaniko. I've got context. That's fine. And then wants me to create a very simple Docker file that I can do. Command forgot how to Docker.

14:45 There you go. Entry Docker. I'm doing well today. Alright. This this is my context. Docker. Well, I created a context there. There we go. That looks better. That's actually suggesting Ubuntu bash echo hello. I think we'll be okay with mine. If not, we can blame me for breaking. Okay. Now it wants a secret. Now because we're using Docker for Mac, I think I can just sneakily log in over here. I was worried that when I take my password into one password, it's magically just gonna show up somewhere because I'm on the wrong box. But I think I was okay.

14:50 Setting up Docker Registry Secret

15:36 It's not showing up. It's just I I think I've I've flashed a password twice on this show now. It wouldn't be the end of the world. Okay. So let's confirm my hypothesis before we move on. Oh, I'm in the wrong context. Oh, no. Oh, I probably have with this. Even I I said that things go wrong and it's always me, that was no word of a lie. Okay. Here we have. No. Okay. We'll see what happens. Okay. Let's let's assume that I've got maybe everything working and it may work. Now are we just moving straight down to the

16:30 Applying Kubernetes Manifests

16:32 create resources in Kubernetes section, which is just to create, I guess, those three YAML files that we've set locally inside of our Kubernetes cluster? Yep. Oh, it should really be in the right directory. Okay. No. I wish I'd given them better names too. Oh, it's three f's isn't it when you do it. There. Okay. So get pods. And I'll assume Kaniko was just pending because we're pulling the image and not because I've made a mistake. No. It could be because there is something wrong going. So it's still Oh, okay. It's complaining about my volume claim.

17:30 Debugging Volume Claim Issues

17:43 Mhmm. Alright. I guess I'm debugging already. Okay. Docker fail. Local storage. Oh, come on, Docker for Mac. Why are you being mean? Well, it's just bound now. Was it just slow? Yeah. Oh, great. Yeah. I was I I wasn't worried. No. Not at all. Yeah. Container creating would mean we're pulling an image hopefully. So we'll give that just a few seconds and we'll see what happens. And we'll see what the tutorial tells us to do. Mhmm. So it's suggesting we just take a look at the Kaniko logs. Oh, so well, there's something I hadn't realized then. So

18:49 by applying the pod dot yaml, we have now actually triggered a build. Is that correct? That is correct. So Kaniko executor is the entry point for the container image that you just created a container for, and it's gonna start executing the build. Okay. Let's see if it's still pulling orbit. Maybe. Yeah. Successfully assigned. Oh, the volume. Oh, the red grid. Alright. I was hoping Docker for Mac was just gonna take care of that for me. But we I should learn by now never to skip a step in the tutorial. Alright. I will also do that in secret.

18:54 Watching Build Logs & First Build Attempt

19:38 And you said that as our the push into a container registry isn't our only option as well. There's a few other ways that we can work with the built image? Correct. We can. We can create a tar, and then, you know, skip pushing by using a flag. No called no push. And is that something that you see often, or is that pretty much standard just to push it straight to a registry of Kin? There are a few folks who requested that plot. I'm not sure what the use case was, but the standard use case is pushing.

20:22 Okay. So I have created the secret, the Docker server. I don't know if it said it in the docs. Is that just Docker? No. No. I have to use this. It's gonna say, of course, it says in the docs. Let me fix that. Edit secret. It's all weird. Alright. I need to just recreate it. That's what I get for just thinking. I could type docker.io and get away with it. Okay. I've created a new secret. So I don't know if I'll need to should I maybe delete the pod or do you think we can just give it a

20:24 Debugging Registry Secret Configuration

21:12 little bit of time and it'll work out what's going on? Let's give it a little bit of time. Think it should be recovering. Maybe the scheduler will just be, you know, delay the retrial. It's still saying not found. The secret Rashgrid does exist. Yeah. K. Forty seconds ago. You're much more you're much more patient than I. I would have deleted this part of my Start again. Yeah. Why not? Just apply in a pod. Well, in theory, we should see it spin up pretty quickly because it has already pulled the image and the secret should exist.

22:15 I think also in the pod definition, was there few things that we had to substitute? Yeah. Here, the destination needs to be substituted with your username and repo, line number 11. Uh-huh. Okay. Rawkode, Kaniko demo. Would that work this time? Yeah. I don't think we need to change anything else. Yeah. It's even nicely commented for me. Again, just not paying enough attention. And this allow just works. This is the name of my secret. Okay. Let's let's try that one more time then. There it is. It is pulling the image. Yeah. It looks much better. There we go. It's

22:57 Second Build Attempt

23:16 running and everything. I guess we expect because this is just a pod executing a single task. It's either gonna say complete and I've not messed anything else up. Yeah. Also would have said error and I probably had a little tear, but we're okay. So this is now built. Correct. So file. Right. We could now look at the Kaniko Podlogs to see what got build and what was the image pushed and if there were any issues in the build. All info. I mean, I'm pretty confident that worked. It should work. You should see a image. You should be able to pull it.

24:05 Running the Built Image (Troubleshooting Output)

24:05 Oh, yeah. I could just run it. Right? Docker run RM Rawkode Rawkode. Kaniko demo. And I'm assuming because I never specified or tag, is it using latest or is that something I should have specified? No. It should push to latest. I think it kinda worked. Okay. Except for I didn't get my actual echo hello. Yeah. I was confused about that too. So that could just again, me not doing things very correctly. So why don't we make them change to our Docker file? So Alpine uses ash, dash c is the same as bash, and then o echo.

24:52 Updating Dockerfile for Output

25:06 Okay. So I can just well, I can't reapply this because we'll have an existing pod. Is that right? So I'd probably just have to delete that anyway. Oh, no. It doesn't seem to Oh. Oh, I haven't changed anything. Yeah. I'll clean it up. Oh, yeah. Zero force and apply again. And I'm assuming if we just watch that, we'll see it. Can I just I can just watch the logs from there, right? Yeah. I see the Docker file is now pushing. Okay. Let's try again. Oh, docker image. I don't know why my container is not talking to me. But I'm feeling slightly hurt

26:13 because of it. Should I I think what I'll I'll just copy this one. Maybe that would be a good idea. Okay. Let's I'm not sure. Oh, no. You know what? I am just being really silly today. We're not gonna see the output if we don't assign it to you to why. Maybe? No. Okay. Clearly, I just have no idea what I'm doing. Okay. Let's try it one more time. I will have a container say hello to me if it's the last thing I do today. Logs. Started yet. There. Still pretty quick considering it was pulling an Ubuntu

26:16 Debugging Output Display

27:06 image. That was a lot faster than I was actually expecting that to be. Let's just pull the latest tag. Yeah. It's a bit bigger now. I guess they've been to images. It must be available for some weird reason. I guess. And I said There it is. I have I don't know what's wrong with the Alpine one. I'm I'm I'm not gonna dwell on it but I'll bet I lose sleep over it later. Okay. Cool. That's it. We built an image. Yeah. So I think one of the mostly used feature of Kaniko is the caching feature.

27:42 Introduction to Kaniko Caching

27:48 Kaniko caches images and only runs command if the command has changed. So when I say caches images, it means it'll end up caching the intermediate layers based on your command and then few other things that we find out if the previous commands of previous lines have changed, which could end up affecting the current Dockerfile command or not. And then based on that, we will either use the image from the layer cache if it's something that we think that nothing has changed. If things have changed, then we'll rebuild it. So a lot of folks, you know, use that feature.

28:10 How Caching Works & Cache Configuration

28:36 We cache the copy command and the run command. Run command has the greatest advantage because that just means that if you're actually, you know, installing things from, you know, PIP install or anything crazy with AppGet, then if we already know that a particular layer is cached, then we'll not run AppGet blah blah blah and, you know, install. We'll just take it from the cache. So we could try that command with a more complex, Docker file. Yeah. So where is that cache part of either of these volume claims, or is that doing something else there? Like, where does that

29:20 caching information live within the cluster? That's a good question. We currently support remote caches only. So Ah. We you can specify what your cache you know, where you would want your cache to live on the remote. We if you do not specify it, we make a guess. It's just based on your destination and then slash cache. That's where all the caches would be. There is an outstanding feature to support, you know, caches persistent caches, but we just haven't had time to actually go implement it. Okay. Yeah. That makes a lot of sense. So is it fair to kind of

30:09 is is it like the cache from parameter where you can specify another image when if I were using, like, the Docker CLI? Is that kind of what the remote cache is like with Kaniko? So you have to specify, it as a flag for the Kaniko executors. So if you look at the pod right now here, like, you have dash dash destination, there is a flag called cache destination probably, and then minus minus cache, which is which will turn on, caching true. I might be wrong on the cache destination. Maybe you'll have to go to the read me.

30:40 Exploring Cache Flags & Parameters

30:40 Yeah. Oh, yeah. Let's see. Forget it. Let's you're right. Let's get a slightly more advanced Dockerfile, and we'll try out the caching. Is that let's see. Is that gonna show up here in this tutorial, or should we need to No. Okay. No. We have to go to Okay. So if I just search for cache, we get all of these flags. Okay. So we've added cache through. I'm assuming cache repo or cash dir. So again, cash dir and cash repo are optional. If it's not provided, then we just make a best guess based on your image repository.

31:26 Right. Okay. So I I don't even need this parameter then. I can just do dash dash cache, and it's gonna work out the best way to do this probably. Okay. So if I grab my Dockerfile and that it probably helps that it moves to Ubuntu now, so we can do something in which we would consider relatively heavy, which would be like an app installed then. I'll just make it in fact, we'll bring this one in next. Let's let's run this first one first. Does that make sense? And then we'll add in your app commands and

31:46 Enabling Caching with a More Complex Dockerfile (App Install)

31:56 I guess what you're saying is if we view the logs of the Kaniko build executor, we'll just see it saying skipping the step or using the cache or something similar. Yep. Okay. Let's apply that. Run get pods. And not quite yet. There we go. Well, it looks like did it you have a cache there? No. In this case, it did not because this is the first time you're building. So we only have a cache per image. So if if you it's this is not a global cache. It's just for your repository. Right? Yeah. Yes. So it just says it was checking

32:48 for a cache, but it doesn't find one. We can now see it running. Mhmm. Oh, I didn't specify the the yes flag. Let me delete and apply one more time. So I I'm curious then, Are there any based on the way that the executor works where it's fetching the image, extracting it, doing some sort of chirou in a command run. Mhmm. Does that mean that if I want to build the an ARM image, I have to use an ARM Kubernetes node to do that? Yes. Currently, we do not support cross platform builds. Again, a lot of people ask for it.

33:10 Discussion of Cross-Platform Build Support

33:41 We also have multi arch Kaniko images. So right now, if you look at our release page, we end up publishing Kaniko images for ARM and AMD, 64, and then maybe one more that I'm missing. But, yeah, you could you basically need to run on a cluster of that target type. If you are building Go images, then we have a way to specify the arcs, like custom platform, and then you would have to add that. Write a Docker file where you said the Go OS and, you know, Go Arch, the right ARC and operating systems, and do a cross

34:24 platform build support which is supported by Go. Okay. I think we had a small problem there, and I don't think Docker Hub, like, was trying to push to slash cache. Oh, okay. I I I don't know if that's expected, but I I see the yellow one. I'm kind of like, oh, maybe not. And it says fail to push. Oh, is it because you already have something over there or it shouldn't happen? Never seen this. Well, I don't think Docker supports the slash username slash repo slash something else. At least I've never seen that before. Oh, okay.

35:16 Correcting Cache Repository Parameter

35:16 Then you could use the destination parameter, the cache d I r or let's see. Oh, yes. So I can set a flag to specify a local directory for cache for patient issues. So this cache d I r is just for caching base images. So a lot of people, especially in CICD case, you know, you your base image is the same. Right? You don't have to pull it every single time. So you could we also provide we could get into that later, but we also provide a way to load your base images. And then instead of pulling it during your

36:04 build, we'll just reference it from that destination directory cache d a DIR. What we need for caching is the cache repo flag. Alright. Okay. So we can actually dash dash cache. We can just override where it's gonna store the cache for that. Right. Oh, let me do that. See. I could just say Rawkode mechanical demo cache. Yeah. Okay. Cool. That makes sense. So let's delete our old pod. But I'm gonna assume just with the delete pod, create pod, delete pod. Can is it Kaniko a tool that you expect people to run-in a local dev environment, or is it targeted more

36:44 Second Build with Caching (Demonstrating Speed)

36:59 at machine automated CICD kind of processes? Mostly for it's it's used mostly in GitHub workflows and Tekton CD pipeline for CICD cases. For local, usually, you know, Docker build is fastest. Enterprise users who don't allow Docker to be built on developer machines can also use Kaniko. Yeah. I can see how this has worked really well with with Tekton actually just with its ability to kind of create those pods as the the workflows or the jobs come in and then build those. Yeah. Right. I definitely picked something that was time intensive to cache because it's a bit longer than I expected it

37:48 to be. Nice. Pushing it now. Perfect. Yeah. It seems a lot happier this time. Maybe. I guess my upload is not as fast as my download speed. Yeah. We go. Think you're building a big image. Yeah. I'm I'm I'm really regretting my decision to to say to install them into this. However, I feel like we're committed now. So. We could install something light next time and see. Make sure that it's not cached. Alright. So does that mean if I delete our pod and I just create that as is, is it it's just gonna use the cache and

38:44 not do anything. Is that kind of what we would expect to see? Yes. That is that should be what that should happen. Let's see if it happens or not. Should is is my favorite word on this show. That's for sure. And cache there. There we go. So This was much faster than our previous run. So we can delete that. We could continue to iterate on our Dockerfile knowing that Mhmm. As long as we don't modify these cached layers and only add stuff to the bottom, we should always be able to leverage that cache for faster builds.

39:35 Understanding Cache Keying

39:35 Right. Just the cache is based on I mean, is this just like you just create a a shasham or something of each of these instructions? I think you said earlier that Right. Internally, we do create, like, a shasham of what the instruction is, and it's also keyed on the commands above. Because sometimes, you know, a previous run could end up, you know, changing the files the consequences for the next following run up. So if the previous cache previous command also changes, we take that into account by, you know, keying the cache the hash keys for command seen

40:00 Image Snapshotting

40:17 so far. Awesome. I think that's all very cool to know that I can do this safely inside of my Kubernetes cluster without resorting to any, you know, privileged containers or any Docker sockets or anything like that. Just have something that I know is is secure and safe. Is there any other features of Kaniko you'd like us to quickly take a look at? Sure. So we could go to, the read me. So like I said, you know, Kaniko ends up taking a snapshot before the command run, after the command run to figure out, like, what file changed.

40:41 Snapshotting Modes for Performance (Full, ReDo, Mtime)

40:56 The default snapshotting strategy, I think if you could go at the end of the read. Maybe explain a little bit about, what are the snapshotting strategies, in the snapshot mode. There is a full snapshot, which actually ends up also hashing the file contents of all the files, which could be time consuming. So we have three snapshot strategies. This is something that we ended up doing, especially for projects like, if you're building, no n p if you're running NPS, or node install and it or app, you end up generating a lot of files. Right? And then we are actually hashing the

41:42 contents of these thousand files. So snapshot full wasn't very, you know, fast enough for users. Like, it would end up snapshotting for maybe fourteen or fifteen minutes. So we ended up, you know, introducing another snapshot mode, is redo, which ends up actually only hashing the metadata about the file, like the time, the size it was motivate size and time it was created or modified, owners and blah blah blah. So, it is big it has proved to be 50% faster. Nice. And then there is another one which is just time based on m time, but, again, there are certain, you know, limitations related

42:30 to m time because, you know, time can move forward and pad like, time can jump around. So those are a few things that you could if you see, like, your build is slower, I would suggest try the snapshot mode. Cool. So is the snapshot filled yeah. That is the default. It says here. Okay. Yeah. It is the default. It works for most of the cases, but only for Node. Js projects. We've seen, like, peep people have complained about the snapshotting time. I guess that's because of that huge Node modules directory that a lot of these Node.

43:05 Js projects have. Correct. Yeah. Yeah. I I I think that's just a a general problem I hear when I speak to people at conferences when that was a thing is that working with it was always kind of interpreted languages never compiled and the amount of files and vendor stuff that they have going on was always kind of difficult in Docker build steps. Yeah, I understand that. Yeah. Is there anything else you wanna cover? Sure. I think one thing, we have we support a bunch of registries. We also support something called as reproducible flag, which is

43:33 Reproducible Builds Feature

43:44 a lot of people do end up using it in production if they would want to make sure that the image is reproducible. So we end up stripping the time stamps of the built images so you could exactly compare two images and understand if there are any file changes or not. So I think Google, we have a base image repository project where we end up publishing, like, you know, images that you could use with just, like, minimal things, and we use the reproducible flag over there, to create those images so people, can end up understanding, what were,

44:31 the differences, and it's always reproducible. The time doesn't change for the image, built. There's single snapshot. You could create, like, one snapshot of the entire, Docker file, instead of, like, having those intermediate image layers. There are a bunch of flags that, you know, you could just go and see. But the interesting thing is about the cache warmer. So we have if you go to our release page it's a little bit out here. So we have a bunch of images available. There is executor, which what which is what we're trying right now. There is a debug

44:53 Kaniko Image Types & Cache Warmer

45:14 image, which only has the busy box installed in it, so you get the shell. So if you wanna debug your Dockerfile or debug your builds, you might end up using the demig debug image. So you could run all the, shell commands available. There is slim, which is something that, was requested with Tekton. I think with the executor, image, we bundle a bunch of binaries. Like, we support different types of context, not just local store local file, but even, like, you could pull a git context, Azure, GCS, and we end up, like, bundling a lot of binaries,

45:54 for those. For Tekton, usually, like, the the code is checked out and everything needed is already present. So slim, works for the for them, because all you need is the Kaniko binary. And then we have if you go down, actually, warmer image. This is the cache warmer. It's not on the release page. But the cache warmer could be used to download your base images. So when you are perform and mount them, store them in volume storage for your Kubernetes cluster. And then when performing build, all the base images would be extracted from that one mount and wouldn't be pulled. So

46:44 you could again make your CI build faster because, generally, your base images remain same. You know, you would upgrade them once in a while. So you would first, whenever you wanna upgrade your base image, just suppose you were on go 10 and now you're increasing the version, then you run the egg the cache warmer executor once to download your new base images in a cache directory. And then from then on, you just use the executor to reference those base images. Yeah. That makes sense as well. So I guess this is something that if I'm running if I, you know, if I wanna

47:18 Scaling Kaniko Builds in CI

47:21 use my Kubernetes cluster to be building all of my container images in a in a CI step, like, because this is all, like, mechanical executors can find a single part and it is working on its own and it's pushing to remote caching and stuff, like, I could scale these just horizontally by as however many bells I need to run at any one point in time? Yes. You can. If you have a lot of notes, there shouldn't be a scheduling problem. You could run as many, as you want in parallel. And is Tekton the approach that you encourage

47:52 Integration with CI/CD Platforms (Tekton, GCB, GitLab)

47:54 people to use to to use Kaniko? Or, you know, are you using just a a straight up Kaniko? Like, is there is there a decision to be made there, how do I make that decision? So Tekton, I think, is more of an orchestrator. So you could end up designing your pipeline. For the build step in your Tekton pipeline, Kaniko is recommended or one of the builders that you could use. Kaniko GCB, Google Cloud Build, also support Kaniko. So you could run a Kaniko build on GCB and take advantage of all the caching. I know a lot of users, Kaniko users

48:39 use GitLab workflow. I haven't looked into it personally, but there is a tutorial dedicated to Kaniko on the GitLab. People fix a bunch of issues related to that in Kaniko. Yeah. As someone who has used Gitlab CI an awful lot over the last however many years, getting the Docker builds to work on it was always an absolute pain. And looking for something like this would have made my life a lot easier. Definitely for sure. Okay. I think I've got like one more question and then if there's anything else you wanna cover, we'll do that. Mentioned Sure. During our chat just a little

49:17 Alternative Build Contexts (Git, Cloud Storage)

49:19 bit ago that can I you said a git context for the build? I can use a git repository for the build context. So I guess that would remove that persistent volume claim mounting thing. That something that's just supported in Vanilla Kaniko, or there's nothing else I need to do there? Well, you need to provide your Git credentials so that we could check out your Git repository. But if you go a little bit up in the read me, there is a section. If you go to the top of the read me, you would see the link for

49:55 Kaniko build context. And there are these are the context that we end up supporting, GCS, s three, Azure. Because Kaniko is open source, you know, a lot of developers who are using Amazon, AWS, or Azure, Microsoft, they end up they have ended up contributing these features to Kaniko. Okay. So that means let me just okay. So I could just drop a get URL into new Your part. This yeah. Yeah. That's it. Right? Yeah. Yeah. Oh, awesome. Yeah. Okay. That actually helps just understand how I would actually use this I think a bit more. But I can provide a secret for private get

50:50 repositories. I'm assuming for open source repositories. I don't hopefully maybe need to provide anything there. Could just drop in my Git URL and see build this and then it would just go away, work, and I'd be quite happy. Okay. Yeah. That that makes a lot of sense. Cool. We covered quite a lot there. Is there anything else you wanna cover before I let you go back to your day? No. Nothing that I can think of. No. That's quite alright. I think what we've what we've done is we've had a really good look at Kaniko and how it works.

51:06 Summary & Community Involvement

51:23 I love the the simplicity of it, the way that it works, and it it's the caching thing I think is really cool and having the flexibility to tweak those cache parameters and how I want them to work to speed up build teams is particularly useful as well. So let me just move my screen. Awesome. Well, thank you very much for joining me today. It was nice to kinda be guided through Kaniko, show people how to get involved, how to get started. I'm assuming as it's an open source project that people can come to the repository,

51:41 Conclusion & Farewell

51:55 find some simple issues, help contribute, and and be a part of the community? Yeah. Yeah. We I am the maintainer. I end up, like, releasing every month. So I look for maybe today, third week of every month, I go through pull request. I help people get those over the finish line if needed. And, again, like, we have issues, triage, and, you know, what labels help one day, like the general open source logistics. And then, you know, you get anyone can pick any any issue they want and add features to Kaniko. Awesome. Alright. Well, people should definitely get involved.

52:38 Check that out. Have a play and let us know how you get on. Tajal, thank you for joining me today. I hope you have a great rest of your day, and I will speak to you again soon. Yep. Thank you so much for having me.