0:59 Introduction and Welcome

0:59 Hello, and welcome to today's episode of Rawkode Live. I'm your host, Rawkode. Today, we're gonna be taking a look at Skaffold, a tool to ease development against Kubernetes clusters, something I'm sure we can all agree that we need. Now before we get started, there is just a little bit of housekeeping. First, if you're not already subscribed, please do that now. Click the bell, and you will get notifications for all new episodes of Rawkode Live. Also, if you're not watching live but you have questions or wanna suggest new episodes, please feel free to join in Discord. There's a

1:30 few hundreds of us in there now always talking Kubernetes, cloud native, and technology in general. Come and get involved. Lastly, I wanna thank my employer, EquinixMetal. They allow that we need the time and resources to invest in the shows and produce native layer materials so that we can all learn together. If you wanna check out Equinix Medal, feel free to give us a code, Rawkode. This will get you $200 of credit. You can spend that really, really quickly in about fifty hours with our beefier machines, or you can make it last almost four hundred hours with the smaller machines. So

2:01 pick your poison, use it wisely. Okay. Now today, we're taking a look at Skaffold. And to do that, I am joined by Vic Anglazes from the Google team and Skaffold team. Hi there, Vic. How are you? I'm doing great. Thanks for having me. My pleasure. I'm very excited to try and make everyone's Kubernetes life a little bit easier today. Likewise. Let's make it happen. Alright. Do you wanna just take a little bit of time and tell us a little bit about you, and then we'll talk about Skaffold? Yeah. So, yeah, my name is Vicky Glacias.

2:04 Guest Introduction

2:30 I'm currently product manager at Google working on Skaffold and the rest of our container tools. I've been at Google for five years now, very much in the cloud native space. I've worked on Helm and a bunch of other tools in the in the ecosystem, and now really focusing my efforts on making sure we have good, clean developer experiences on top of Kubernetes clusters as well as a way to bridge that experience into the operator tooling that we use. Nice. Well, that sounds awesome, and I'm looking forward to seeing what Skaffold's gonna bring to the table then.

3:00 WHat is Skaffold? (Slides)

3:01 I believe you've got a little bit of slides, so I'm gonna, just get the screen started. We'll drive straight into the slides, and then we'll have a little bit of a chat afterwards. Perfect. You are live and good to go. Alright. So just wanted to kinda tee up Skaffold, and then, David, you'll take us through kind of the documentation and showing us a little bit more of the nitty gritty of what it is, but just wanted to make sure we have a overview of what we're talking about here. So Skaffold is is the tool we'll be talking about

3:12 What is Skaffold?

3:28 today. We'll go through a little overview, look at briefly the config, and then some use cases that we can have for this tool. So when you think about developing on top of Kubernetes and being kind of having some sort of parity with your, production clusters that are gonna run Kubernetes, you have to do a lot of tasks in order to emulate that production environment, which has a CICD, process behind it. Right? You have to, on your local machine, build a container, test it somehow, make sure you have the right tags to be able to reference it, push it to

3:59 a registry if your cluster is remote, put that reference to those images inside of your Kubernetes manifest, deploy those manifests to the cluster, and then port forward your your service to your local host so you can access it, look at your logs, and then you have to do that all over again whenever you make a change. Right? So that's a lot of effort that you're putting in in order to do that. And some of the challenges there are not just that you have a lot of steps, but you have various tools. Right? You're using Docker to do part

4:24 of it. You're using maybe VIM or Versus Code in order to edit files. You're using cube control in order to apply manifest, and and really just gets tedious to do all these tasks as fast as you want them to be. And so what we really wanted to build was hot coker loading for Kubernetes. You update a file on your file system, and that is automatically realized inside of your Kubernetes cluster with little to no effort on your part. And so that's why we've bar created Skaffold. And Skaffold is open source. You can find it at the Google Container Tools slash Skaffold

4:51 The Skaffold Dev Workflow

4:56 repo on GitHub. And it takes all of those commands that I showed and all those processes and all those tools and condenses it down to one command, which is Skaffold dev. So Skaffold dev is gonna automate that whole workflow of building, tagging, pushing, rendering, deploying, updating your application inside of your cluster, all with a declarative config and with a very pluggable architecture so that you can choose the tools underneath the hood. For example, when you're managing manifest, you might start out with raw manifest on disk. You might then go to Helm because you see a lot of values that you wanna template

5:28 up. And then from there, you might go to customize or some other tool in order to manage those manifests. And we wanna make sure we support you along the way. And at at in your workflow, all you have to run is Skaffold dev. You don't have to think about those underlying tools. One thing I did wanna point out is, the awesome team that we have behind Skaffold. These folks are super passionate about container tools, super passionate about making the best possible, experience for our users and for our community. Just wanna call out Nick, who's our TL,

5:41 Meet the Skaffold Team

6:00 Tajol, who you had on last week, who, was talking about Canico. She's our engine manager. We have Brian, who's our Glue TL. He's able to understand the entirety of the tool chains underneath the hood of Skaffold, which includes build packs. She includes the way we debug. All of those pieces need to integrate well, and he's got all of that stuff mapped in. We've got Marlon who's working on a lot of our usability and onboarding tooling, who worked on some of our complex, config management, which we'll show later, and then Aaron who's just joining us, after returning to

6:32 to the Skaffold project. So now that we've teed up, we've got a a tool that helps us for development. We've got an awesome team behind it. What can you do with it? Right? And there's really three categories that we think about. We think about being able to do can discontinuous development loop, right, being able to quickly and easily get that hot code reloading feel out of your Kubernetes applications. But, also, we wanna help you with your continuous integration and GitOps journeys. Right? We wanna make sure that you can reuse what you've already configured in your dev loop for these

6:37 Skaffold Use Cases

7:03 CI journeys and to get those manifest ready for committing into your GitOps repo. The last thing we're able to do is is help you with your continuous delivery and make sure that you deploy your manifest in the same way that you did during development. So what do you need to do in order to get comfortable with Skaffold? First and the most important part is probably getting your config file. Right? And so our config file, for those in the cloud native ecosystem, probably looks very familiar. This is a Kubernetes resource model config. We have an API version kind and then

7:15 Skaffold Configuration (skaffold.yaml)

7:33 some config blocks under that. Right? So the the config blocks look like build, test, deploy, render, things like that. And, really, as you kind of build out these configs, you see that you can swap each of the tools in each of these pieces, which makes it really nice for transitioning between tools and not having to change the way your developers develop. Right? It may be that an operator wants to change out the way they handle manifests. It may be that developers have changed the way they wanna build their images. With this abstraction that Skaffold provides, those teams

8:06 don't really have to coordinate those changes. They can just coordinate them through the configuration files, which is a really nice way to do it. I talked a little bit about the the structure of the Skaffold YAML. You have your API version kind, and then you talk about your builds, how you're gonna get images, how you're gonna test those images, and then how you're gonna deploy those images. One last thing that you can do is create profiles that allow you to have kind of configurations that are specific to a particular environment or a particular use case.

8:34 Cool. So now you've got this configuration file. Now you wanna iterate on your app. Well, we take all of this flow that I talked through earlier, and we turn it into one command, and that's Skaffold dev. It's gonna do all of these things, build, test, tag, push, render, deploy, forward, and update as you change files within your IDE or within VAM or Emacs or whatever you're using as your editor. So then once you commit that file into your repo and you wanna have another teammate use that same config or you wanna onboard a new team member, all they have to

8:38 The Power of Skaffold Dev

9:10 do is git clone your repo and run Skaffold dev. And they've got your best practices for development already on their machine without having to do anything else. So that's a really powerful tool, and we've seen a lot of customers use this for their onboard. So now you've gotten that iterative dev loop going. What do you wanna do next? Well, you wanna deploy to production or staging. Right? And we can use Skaffold as a bridge between that dev loop and the CICD pipeline. And the way we're gonna do that, you saw those blocks in the config file. Right?

9:28 Integrating with CI/CD Pipelines

9:40 You have the build and deploy block. Well, we're gonna take this big pipeline that we had and chunk it up a little bit and run only individual pieces when we need it. For example, you might have just the left side of this pipeline running in CI and the right side running in c. So let's see how that might look. So, for example, in CI, you wanna build your images, tag them, and push them. So you can take that same configuration that's in your repo and run Skaffold build, and it'll only do that chunk. Right? Build, tag, and push your images. Another

10:11 important thing that it does is it takes that those images that it built and puts them into a file called artifacts dot JSON, And then you can use that in other pieces of your CI system. For example, when you wanna go to deploy, you can pass that artifacts JSON to the Skaffold deploy command, and Skaffold deploy will take care of rendering, deploying, and forwarding your logs for that that service. Right? So now we're able to run individual commands to do just pieces of this pipeline, but we're sharing the same config between our development loop and our

10:41 CI process and our CE process. You might also wanna do GitOps. Right? So you can take the Skaffold render command, which will not only build, tag, and push your your images, but it'll also take those references to those images and put them into your Kubernetes manifest and give you back raw YAML that then you could apply into a cluster if you wanted, or you could commit that directly into a repo and have a GitOps operator like Flux or something else pick that up and push that up to to production or staging. Finally, the other part that we've added, very recently

11:11 Skaffold Apply

11:14 is to take that manifest that's been put out by Skaffold render and apply it into the cluster while doing health checks for those services and and deployments that have been put out. Again, these are the same health checks that we use during development, so you get that unification between your dev loop and your CICD pipeline. The last thing that I'll mention is a lot of iterating, in the development loop is wanting to debug something that's wrong in your app. And we have Cloud Code, which is our Versus Code and IntelliJ extensions, which lets you have this hot code reloading

11:33 Cloud Code and Debugging

11:48 field through your IDE by just hitting your run on Kubernetes button or f five, or you can also have it connect directly to those applications via the debugging functionality. So this is transparent to you as the as the user. We connect to your app. We put in the right debugging tools into your pods and then connect back the port onto your local host so that you can hit a breakpoint inside of Versus Code, and it'll hit the breakpoint inside of your your Kubernetes application running in your cluster. So super powerful stuff. Definitely check out Cloud Code as kind of

12:20 an interface around Skaffold that can make it easier, especially to get started and definitely for debugging. And that was it. So that's how I wanted to tee up things, and I think now we can get into some of the new Yes. I think I just lost your audio, though. Is it working? Oh, it works when I bring your screen back. Oh, okay. So There's a fun bug. Alright. Let's try. How about how about now? Yeah. I have to keep bringing it I'm gonna click the x on it and see what happens. And if I can't hear you, you might

12:28 Transition to Hands-on Demo

13:08 just have to share it again. Let's let's see let's see what happens. Say hello. Hello there. Alright. Okay. We're we're live. Well, wouldn't be a livestream without the hookup. That's That's amazing. Hello. I mean, I I've gotta say, They said they took it to be true. Well, let's see. Let's see how far we can get with it to to to figure out that story. I think the the big part is getting the config right. And then from there, it really does work like magic. Those are some I mean, the amount of functionality being packed into what Skaffold I mean, to be completely

13:45 transparent, I haven't looked at Skaffold in probably two years, at least eighteen months, but probably more than two years. And I I it just it's always added a lot of really great features. And I've been able to slice and dice, you know, all those different components and the actions to break down to fit the workflow that, you know, my teams, my orgs, whatever wanna adopt. Just seems great. So I'm really I'm really excited there. Definitely really excited there. But I think we should get my screen shared and we should start kicking the tires on this a little

14:13 bit. Cool. Alright. So for anyone who wants to follow along at home in their own time, you have Skaffold.dev, which is the documentation and the examples that we we working from today have gone ahead and cloned the Skaffold repository because they have a whole bunch of examples here that we can kick our tires on and play with today. And I don't see this a lot. I cover a lot of open source projects and it's really refreshing to see a directory full of examples tailored to different workloads and different languages and stuff like that. So really

14:15 Exploring Examples and Quick Start

14:46 excited to see that as well. Now if we just click on the docs, I do have Skaffold installed. I spared you all the the brew command to see how to do that. Alright. So now should we start with quick start? Is there anything here we should just kind of do the really basic one before we start picking a few examples? Yeah. I think this this goes into the example. So you're kind of streamlining that part already. I think if you go into examples and and check out the, yeah, the microservices example is probably a nice representative one.

15:00 Microservice Demo

15:19 And I think, yeah, just c d into microservices folder there. That's one we can check out. Awesome. Alright. So should I just pop this open in code, or are we just gonna work directly in the command line? You can do either. So I I would just do a Skaffold dev here. And maybe, you know, before we do that, can look at the Skaffold YAML just to see what's in there because I think the configs are nice to look at. Sweet. So we'll just kinda go block by block here. So you have your build section, which

15:21 Microservices Example Config

15:51 is saying, what images do I wanna build? And we call them artifacts. Today, we're very focused around container images. So we have two images that that we're building in this app, but it's actually using a third image as a base. Right? So you have Leroy web and the Leroy app that you supposed to see require the base image. So here, what Skaffold's gonna do is it's gonna first build the base image and then build those two other images after that point. So you can kinda share a a base. Right? You may have a GoLang app that uses the

16:20 same Go version or that you wanna keep in sync somehow or you have some pattern for, you know, dealing with your, you know, authentication or logging or whatever, you can put that into the base and then use it from your two application containers. Then from that section, after that section, you have the deploy section, which is gonna just use raw Kubernetes manifest. You can see there deploy, kube control manifest. So it's gonna deploy, manifest with kube control, and those are stored in those directories, and we use a blob to describe where those are. And then the last section, I think, is

16:53 is really cool, and this is something we recently changed. When you put this port forward section in, you can describe what resources you want to be port forwarded and what ports you want them to be on. And then Skaffold will automatically port forward these when you run Skaffold dev. So then after the app comes up, David, you'll be able to see on Port 8080 the web app of this application. Alright. I think that all seems pretty familiar, you know, like, maybe to like other tools, you know, it doesn't look like Docker Compose, I'm defining containers that I wanna run. I'm

17:25 seeing how to deploy them and I've got my ports. So it's kinda there's this familiarity to it at least. Absolutely. I quite like that. So what you're saying is if I just run this magical Skaffold dev command, it's gonna spin up these images, expose the port locally, and I should be able to browse to what port 9,000 and see our web app. That's right. So alias on the I'm gonna assume this may take just a few moments. So while that does that Sure. We've got requires here for the artifact that's requiring a container image. What

17:46 Running Skaffold Dev (Microservices)

17:57 what's the alias of base? Why are we? Yeah. I I don't think I understand what this means. Yeah. So if you can actually maybe pop open in a in another window the the Docker files, you'll see that we're passing an argument into the the Docker build process. Yep. So you wanna take So then in base yeah. It they base a Dockerfile, and that should be relatively simple. Right? It's coming from distroless. We're setting a environment variable there, and then we're saying what command to run. So that's kind of our basic config. And then if you go into, like, Leroy app or Leroy

18:38 web, you'll see that we're using that alias that we defined previously. So you see arg base? That's what lines us up there, and then you'll see from base in the bottom. So the arg kind of passes from the Skaffold YAML into the Dockerfile and then becomes a from block in that Dockerfile that that's kind of the leaf node there. Right. Okay. Yeah. That makes sense. I think I understand that now. So it now seems to have built our images. And by waiting for deployments to stabilize, I'm assuming is that just waiting for the pods to

19:14 spin up, probes to maybe start passing, and I think that. I do that correct. Alright. Moment of truth. Is this working? Alright. Of course, it is. There we go. There it is. I mean, it's easy to get text to render in a browser, but it's hard to deploy that text into the programs cluster sometimes. Cool. That was nice and simple. Yeah. So now you should be able to update the text of that app and have it rerun the loop relatively quickly on your behalf. Alright. So this is a Go application that is just doing a format print. So

19:41 Code Changes and Reloading (Go)

19:56 you're saying I should be able to add Rawkode says hello. Yep. And just save and then go back. Cool. So it's picked up that change, and now it's gonna redeploy or rebuild the the Go app in this case and redeploy it. Okay. And that's just using Docker under the hood right now because we haven't really told us to do anything otherwise. I'm I'm I'm able to take advantage of layer caching and all that other goodness based on how I configure my Docker file. Yeah. And actually running Skaffold dev is how I've optimized my images over time because you start

20:35 to kinda watch it pretty intently, making sure that your layers are right. And when you change a certain file, and it doesn't do, you know, weird things, so you can kinda segment the the the the files in your repo a bit better. But what we do in Skaffold is actually look at the Docker file to find out which files are important to watch. Right? So if you're doing, for example, a copy dot dot, so copying the entire source tree into your doc file, yeah, the whole source tree is gonna be active. So anytime you change anything there, you're we're gonna rebuild.

21:04 But if you have very specific things, like maybe only copying the Go files or your Go binary things, it will only update when you change those. Alright. Well, I'm definitely impressed with our first little demo there. It's nice to see that working end to end. I can see how that development workflow is really you know, we're I guess what every developer wants is that really fast feedback loop from when I change my code to when I see the results or what I want. And That's right. Skaffold is automated in that entire step from saving the files to building the

21:35 image, pushing it to Kubernetes, deploying it to Kubernetes, and then port forwarding it to me. That's right. That's what I wanna see. I like it thick. So should we jump into another example? Yeah. Sure. So we can try maybe a file sync example. So let's take a look. I do have a question there. Just something caught my eye. I control c that, and it's also got a signal handler on it. And it seems to have deleted those deployments as well. That was pretty nice. That's right. Yeah. So it'll clean up by default, and then you can also have a flag dash

21:48 File Sync Example (TypeScript)

22:07 dash cleanup false if you wanna leave things around. And that's usually for folks that have something that takes a while to boot up, and and they wanna make sure that they have a running version in there to get back to where they were. Yeah. Cool. Yeah. I was I I thought there when I control c that I was like, oh, that's probably not the best way to do that, and I'm gonna have to clean it up, but it surprised me. Yeah. We'll handle those pieces for you. Alright. So that was a compiled Go application. Can we take a look at something that's

22:30 TypeScript Demo

22:35 interpreted in a bit more dynamic, or do you wanna jump into something else first? What what you think? Let's try the you like TypeScript? Should we try a TypeScript example? I actually haven't run this, so we might as well, you know, ask the demo gods to to bless us with the TypeScript payment. Alright. Well, I will repeat the same process, and I'll run Skaffold dev first, jump jump over to the other tab. We can take a look at the Skaffold. Yml. That makes sense? Beautiful, that's good. Alright, so we can jump out of this. Yeah, test script, there we go.

22:42 File Sync Example Config (Profiles, Sync)

23:13 But I suspect this is probably gonna be very similar until I say that. And of course, we've got some profiles thing going on here. So I'm gonna shut up and let you just take that away. Let's see. So in here, we have a few things that are gonna be different. Right? The the image part, the the artifacts is very basic. Right? You define what the image name is gonna be and then the context of where that image's Dockerfile is, for example. In the profile section is where we define kind of a different SKU or a different way that we want

23:47 Skaffold to operate depending on the commands you pass to it. So here, this team, if we wanna imagine it that way, has a development profile. And so when we run Skaffold dev, we're gonna pass dash p for profile dev, which is the name of this. Right? And that allows you to run this particular dev profile. But you can also see that we have an activation there that says anytime we're running to the Skaffold dev command, that it's gonna use this pro profile by default. Right? So this is another way to kind of catalog the procedures

24:23 or the the the workflow of your team. And then the the real change here that we have is that we're building the artifacts with Docker, but we're also gonna sync files to the container. Right? So in some cases, with interpreted languages, you're gonna wanna make sure that you don't have to rebuild from scratch every time because, really, what you wanna do is just shuttle your files from your local file system out into the running container and, you know, restart your your running process. And so that's what this is gonna do here. Right? And so you can see, you can define the specific

24:55 files that you wanna be synced over. So here, we have a manual sync, which means don't try to infer what my syncing strategy should be. Sync these files, source the full glob, anything TypeScript into the destination, which is the source folder on that side. And so we should see very fast updates here with no rebuild like we did in in the Golang example and no compile, for example. Cool. So the sync that's happening, I mean, is that just running our sync into the into the pod, or is it the, like Not not quite our sync. Even even more,

25:33 I think, rudimentary than that. We're just tarring things up and then copying them over to the container and exploding them over there. So we have the keep control copy command is, I think, is being used under the hood or maybe that was how it was done previously and now we've done something fancier, but it's a pretty basic implementation there. Yes. So you're not actually modifying the container image that I use from application in any way. You're doing this purely over the APIs exposed through Docker or Kubernetes, etcetera. That's right. Okay. That's right. Alright. So this is now

26:01 Running Skaffold Dev (File Sync)

26:01 running. How did we expose that? Well, we don't have any port thing here. So by default, it should expose the port that is running there, but we might have to if you go up, did it any green lines of the port forwarding info show up? Looks like not. So we'll have to do the dash dash port forward flag because no port forwards were defined in the config file. So this is just a way when doing Skaffold dev to expose a port without modifying the Skaffold configuration? That's right. So let's just do, yeah, cleanup and then dash dash port forward.

26:40 Let's see. It should auto detect. It should just be the port forward flag with no arguments, and it should be auto detected in there. Should is my favorite word on this show. Oh, yeah. I you know, like I said, I haven't done this this one before, so we're gonna figure it out. So we got a question, I guess, we could tackle just now. Is asking, can Skaffold be used for GitOps environments? Yeah. Definitely. So one of the things we try to do is kinda chunk up the pipeline that we have for Skaffold dev and let you do individual pieces. Right?

27:11 And so what you can do with, for example, the Skaffold render command is all of the steps that we showed except for the deployment piece. And rather than deploying hey, Instead of deploying, you're going to get a YAML file that has all of the things that you needed in that file or all the things from your configuration in that file. And so you can put that into your Git repository, and then that will be synced with whatever git GitOps tool you're using. Okay. Cool. Thank you. I think a few members of the team are also jumping into

27:42 the comments and answering questions. So, yeah, thank you to Jal and Nick. Okay. So this is exposing port 3,000 locally on 3,001, I think. That's right. We're gonna get a lot of hello world web pages, I think, today. There it is. That's about as far as I take my side projects anyway, so I'm quite familiar with this page. But you gotta buy the domain first, obviously. Oh, we oh, don't give me a start. I don't know why I feel so compelled to buy domains for all every great idea that I have only for them to set zero.

28:17 And then I renew them four times, and then I go, maybe I'm done. Then maybe I'm late. No. You keep it. You keep it. So that's a hello world, we're gonna make a modification to this application then. So let's see. We got our back end source index. There we go. Cool. I'm just gonna save this. Change is happening. Re exposed. So I guess with like a node JS or a type script project, they have a concept of like hot module reloading themselves. Is that something I'm gonna be able to get to work or would I

28:30 Demonstrating File Syncing

29:01 quit running yet? Yeah. So you should so your app is gonna need to do whatever it needs to do to be able to detect the change. Right? So for example, like, I've I've used Django in the past, and you have to pass a particular flag to it to, know, actually reload itself. And so that would have to be set in your application. What Skaffold is gonna do, its part in this is getting the files over to the new container or the the built container. Yeah. I guess just because this is looking at the code now, this is just a

29:30 really simple express express application to show how that interpreted thing works with the sync. So this that's probably not gonna have hot module real. But I can imagine if I were to use Next. Js or one of these other fancy frameworks that may just work out of the box. I'm gonna leave that as an experiment for another day, but something I'm curious to try in my own project. So that's pretty cool. Yeah. I wanted to show something from these examples and how the images are placed into the configurations. So if we go back to the Skaffold

29:52 Image Naming and Registries

30:00 YAML, and we see that we define the images and their names, we didn't really give a fully qualified name here. So if you look at build artifacts on that first image, it's called node TypeScript example. That name has to match what's in your Kubernetes manifest. Right? So that's how we know the thing that we built is the thing that needs to go into your Kubernetes manifest. So if you go back into that Kate's folder, you should see a deployment that has that specific image name in there. And that's not something that necessarily is, you know, for

30:35 example, on Docker Hub, which is where, you know, Docker would look first. So we make sure that we replace that with the one that's locally built. And since you're using Docker desktop, which has the Docker daemon shared between Kubernetes and Docker, the image is built locally and then runs straight off of that Docker cache. Right? And that's how we get some speed improvements there. But you could also, for example, use a flag on the Skaffold build command or Skaffold deployer, any of those that says, tack on a prefix to this. Right? Where the prefix might be, you know,

31:09 gcr. I o slash vix. Right? And then that'll tack on that so that it goes to my private registry when it builds. Right? So we have that flexibility to be able to do things kind of in a streamlined way in in development and then point it at a more production style approach via flags and config. Alright. Cool. Yeah. I was actually curious about the the image stuff, so it's nice to get that kind of clarified. We just understand how that actually works and what's expected from that. We kind of end user there too. Yeah. Alright. So I'm gonna let Skaffold clean that

31:30 CloudNative BuildPacks Demo

31:42 up. We'll jump back into examples. This is the normal LS. So we've taken a look at compiles with Go. We're taking a look at Terpitude with TypeScript. Let's see what catches our eye. Build packs build packs example. I don't know how many folks have used build packs in the past, but build packs is a really easy way to get kinda streamlined image builds without having a Dockerfile. And Skaffold is a really easy way to get going with build packs, and we'll see that in the Skaffold channel for that one. So is this cloud native build packs or

31:50 Buildpacks Example

32:14 the classic kinda Heroku build pack? This this is the cloud native build pack. Specifically, the GCP build packs, I think, are what's configured in this, but we support any of the packers that are available. So if you look at that Skaffold YAML, it should have the, yeah, the builder config in there. So you see our image has another block under it that says build packs. By default, we're gonna look for a Docker file, but you can configure Skaffold to grab create images in various ways. Right? It could be did a session with you on Cameco.

32:27 Buildpacks Example Config

32:50 Right? You wanna run-in cluster with a Docker list build. You can do that. This is another approach which uses build packs, which actually pack your image from source code directly. So you don't even have to have a Dockerfile to tell it how to build your image. It just detects, hey. You have a Python app. Python apps generally have a requirements dot TXT. I'm gonna get your dependencies in place with that, and then I'm gonna go ahead and build that image for you and push it to the registry. And so the way you define how you

33:17 want those images to be built or what standard of of building you want is via that builder configuration there. So does this mean when I run a Skaffold dev, we're gonna see something slightly different from what we're seeing in the presentation? Yeah. Specifically in the image build, you'll see a lot more happening than your usual Docker files. Let's take a look at that. Let's see. So it's pulling the builder image. So this builder image contains all of the code that understands how to go from source code to a built image in the OCI context. I'm assuming for multiple

33:39 Running Skaffold Dev (Buildpacks)

33:56 languages, giving the number of layers and the size of it is that it's probably like a It is ubiquitous super It's a bit chunky. Yeah. So, yeah, this will have all of the things you need, and it's that builder v one that we have in the the Skaffold YAML, and it'll be for Java, Python, Node, all those languages, all the same. So you only really have to pay this, quote, unquote, tax one time, and then you should be good. Alright. Doesn't seem too bad. Yes. Sorry to go. Quickly. And so this will be kind of the

34:26 initialization in a lot of cases with, you know, these dev loops and containers is getting the right bits into the right places. And then from there, we do fun tricks with layering and a bunch of other stuff to make things fast from that point. Cool. So we just pulled the builder image, and now it's actually gonna look for the run image. So how do I run this image, which may not be the same way that I build this image. Right? It's just how we do kind of distroless images for security purposes and things like that. It'll actually build a really

34:57 lean image when it runs, but have some more content in there for for when it builds. Okay. So you saw at the top there it's detecting? Yep. Yeah. I was just gonna say it's to try to detect what kind of code we have inside of here, it has correctly identified that we have Python. It seems to bring in that there's maybe some sort of pep file, not looking at the code, but that would make sense. I'm not sure what the analyzer is doing with this, but then it just starts to build. I guess that's good.

35:30 So then I don't even need to write a Dockerfile. I can just leverage build packs, and it'll do the right thing, hopefully. That's right. And, like, it's not the hardest thing in the world to get, you know, Docker files written, but to get a good one that's lean, that has the right dependencies, and that works cross language is definitely harder. So this can help you kinda standardize things down and have one less thing to worry about in your ecosystem. Well, yeah. I mean, it's one of those things that, you know, if you can draw an experience of an entire community that are

36:01 focused on maintaining these build packs to produce production images for runtimes and languages, like Exactly. Who who wouldn't want to take advantage of that, really? And build packs are something that I I think are really cool. I just I've always thought it was maybe just too early from what I've seen, but maybe that's changed. Maybe it's maybe it's getting better. I think one of the challenges is just getting build packs. Right? Like, how do you run them? You have to have a CLI. In this case, Skaffold is running all of those pieces for you. So it's just adding

36:30 that little config block that you saw, and then Skaffold takes care of the rest for you, which I think is is a ease of use improvement that that build packs needed a nudge towards. But they have their own CLI if you wanna run this, for example, in CI or whatever. Okay. So I have noticed that this one has, you know, taken a little bit longer than the first two examples. Is this something that is gonna be a lot quicker as I make changes to the application? Like, we're not gonna have to watch all of that

36:54 again. Right? Right. So you you'll have actually in we have an integration with Buildpacks to do syncing as well. And so you'll get some optimizations again through how Skaffold does all these underlying tools to automatically sync the right things over to that container when necessary. And maybe we can get someone to post the the link to those docs. If not, I can find them real quick. Alright. Well, it looks like we have our Python application running, but I don't think I've seen the port forward. Maybe that we need to add that. Yeah. The dash dash port forward command might

37:32 be necessary on there. Alright. So let's just try that again. And then we'll see what happens with the speed here. Yeah. It's it's just been straight to deploy. But I guess that makes sense. Nothing has actually changed in the the application. Right. So, yeah, eighty eighty one. Cool. What is the hello world message? Oh, lowercase hello world with a comma. I like it. Mixing up. Yeah. Definitely. Alright. Okay. So we got web dot py. Hello, world. Let's just standardize this. Let's save. And that's now going through the build pack stage again. And so it's reusing a bunch of the

38:17 things that it already did in the past here. Don't think in this case, it's actually syncing. Yeah. I was gonna say, I don't think I see anything here to suggest that it was maybe just syncing the fails into the running container. Yeah. It looks like it's rebuilding in this case, and we may need to actually set something in that example to get it to auto sync. Oh, you know what it is? I think it's only for Go, Java, and Node. Js. So have we picked a different language? Maybe. Yeah. That's it. Right? Blame me. That's fine. Whatever.

38:52 I think I think I was the one who chose the Python. So Yeah. I think you said build pack, and I was like, oh, let's do Python. But yeah. Okay. We could try another one as well. I guess, if anything can make Java fast, that's definitely a one in many people's books because that's almost a point of a point of frustration for people developing against Kubernetes. At least the people I speak to, it's always a pun of frustration. There we go. Yeah. And we actually have a a Java specific builder as well called Jib. So if you look in those examples,

39:10 Jib Builder for Java

39:17 you'll see another very similar approach to to building images that are that are lean and and fast is the the Jib examples in there, but that's specific only to Java. So if you go to, for example, Jib, just the regular Jib example, this should let's see. Oh, you might need to have Maven installed for this one. Why would I need Maven installed? Because Jim actually uses Maven under the hood. Well, it is a part of the Maven build process. So it gets involved with your actual Java project and builds the image in a very efficient way for Java applications and then can

40:00 Multiple Config Demo

40:00 update that image in a very efficient way. And so you see, we the way we define that here in the artifact section rather than having build packs under the image like we did last time to tell it we're not using a Docker file. It's actually using JIT there. Okay. Well, I don't believe I have Maven, so maybe we should move on to We can go on to a a different one, and maybe we'll just do maybe multi config microservices. I know Thomas has been waiting for this one to show up. Maybe more as well. Let's see.

40:29 Multi-Config / Modules Example

40:38 Cool. Okay. So it looks very similar to the last microservices. So I'm expecting we're gonna be to see something different in the Skaffold. Let's check it out. Oh, look at that. A little bit different. Little bit less context at the root folder here about what's going on in the repo. What we're doing here is using a feature that we call modules or config dependencies. Right? And so this allows you to take a kind of broken up app, which maybe it has Helm charts plus Kubernetes manifest in the back end and the front end or, in this case, the app and the web,

40:50 Multi-Config Example Config (Requires)

41:14 and create individual Skaffold YAMLs for each of those and then reference them from a a common Skaffold or root Skaffold. So this way, I can have dependencies on other services that live maybe in my repo or maybe outside of my repo. And this requires block lets me pull those in into my local development environment. So you can imagine you depend on a back end service that, you know, your team doesn't really own. You can point at their repo and pull in their latest, you know, stable build so so that you can develop your app against their app at the same time.

41:55 Great. Okay. That makes sense. So I could have I I'm trying to say, guys, it's up to work, like, in practice. So if I've got many teams teams all built on their own microservices and their own repositories with their own Skaffold configurations, I could have, like, an app of apps repository that would allow me to spin up everything by reaching out to all of those other repositories. That's right. And so here, we're we're using the path way to configure this, but it could also be pointing to a Git repo, right, and a and a specific branch within that Git

42:23 repo or a specific folder and branch within that Git repo. And it's not just for the app of apps kind of pattern. It could be just to have your particular slice of dependent services. Right? So you might have, you know, a front end service that requires x, y, and z back end. You don't really want the whole universe to be built. You just need the three other services or the two other services that you require. And so you can kinda just get that little DAG built out in your your local environment. Okay. So I I I've got one more

42:57 question. I don't know if you just answered it, but I'm gonna just ask it anyway to see if it changes anything that maybe just doesn't click into my head. So if I just want to so I've got a I've got an application that's got three services. I'm working on one service, but I need the other two. And I wanna use the app of apps or best kind of config where I have the required on the three services. Like, can I say that I want to launch all of them in like a not not production, but almost production manner, and

43:29 then one of them in, like, a dev profile where I can do the iteration on it? Is that all possible? Right. Okay. Yeah. Yeah. So you can start to kind of tick on and off flavors of the various apps and and pieces that you want. But if you look at kind of the the Leroy app and the Leroy app, Skaffold YAMLs, they'll just look like normal Skaffold YAMLs. And what when you require one of these, we pull in the config and kind of mash it together so that you get the right order of events. Right? All the images are

43:57 built together, then all of the deployments happen together, for example. And so it's a really nice way to kind of break up this microservices dependencies and let you have a unified way to to develop between services. And is it possible to not do the build and only leverage, like, the actual deploy aspect of some of the apps, but then do the build for one specific? Yes. Yeah. Nodding. I'm happy. Yeah. No. That that and I think that's probably the pattern that that we want the most is, you know, if you do have dependent services, you don't really wanna depend on their

44:30 repo, probably. You wanna depend on some, you know, stamped out version, a stable set of manifests. Yeah. Right? So you could have a module that only has a deployed block in there and just pull in those static manifests because, really, you want a working version. Right? In some cases, though, you might wanna actually develop on both. And so you can do both of those patterns, whether it's, like, static manifest that pull in the stable or the upstream kind of trunk version of their app, including their source code. Okay. I like the scent of all of

45:02 this. So I am just gonna go and run our Skaffold dev. And I expect this is gonna be super uneventful, same as all the other examples and just work, and I'm not gonna have any good questions for you. But I like it when things just work. It's a it's a nice change from my actual day job where nothing I do works. Don't worry. It's taken a lot of effort from a lot of folks who are are in the chat here to make sure these these samples work, and I think they're they're a great example of kind of the the

45:06 Running Skaffold Dev (Multi-Config)

45:30 breadth of functionality we have. One of the things we're definitely gonna be focusing on in the back half of the year is how to put it all together. You'll see, like, a lot of our examples are very pointed towards specific features. So we'll start getting some more complex examples that show a bunch of different pieces being stacked together. Cool. So that looks like it's, well, it's just worked. We got our services exposed on port 18001. I'm gonna hit 9000 and assume I'm gonna get a hello world. Oh, the Leroy app. Okay. There we go. Alright.

46:07 Yeah. I think it's definitely starting to make a lot of sense now of how I would want to structure this. I I just think that require with the path and the repository based way is where I naturally wanna start taking my applications. Because I think it's how you know, I I don't really want, like, a monolithic configuration for everything to run my thing in production. I really want each team to have the autonomy to say how to develop and run their app. One thing we might wanna check out while we're here is the Skaffold, like, the individual

46:33 CI/CD Workflow with Skaffold Commands

46:36 commands. Right? So we've seen kind of the the loop, and people have been asking about DevOps or CI or how this fits in. So if you cancel out of here, we can do the Skaffold build, and you'll see what that does, which as you can imagine, all it does is it's gonna build. Right? Just do the build, and we can tell it to output the artifacts. So if we do Skaffold build dash dash file output and then artifacts dot JSON or whatever, it's a file dash output, actually. Yeah. I I thought it was gonna be that, but

47:05 then changed my mind. Okay. Art of dot JSON? Yep. Cool. We already have the images built, so it's no no extra magic there. We're just using the caching. And then it let's take a look at that file and see what information is in there. You might wanna do it with JQ or Beth. I guess. I think you can just do j q, can't you? Yeah. I think so. Oh, I need a dash f for something. Yeah. Let's do it the way you there we go. Alright. And so not nothing special in here, but just to show that, you know, we have

47:46 the images named. We have the specific tag that we built, and then we can pass this into other places we might need it. Right? So you can imagine your CI process when you've committed to main, you know, runs this and then creates this artifacts. JSON is saying, here is the latest images from this particular commit. Then you might wanna pass that into your CD process. Right? And so here, we can do Skaffold render and then pass it in that file. We might need to do help because I don't remember the exact I think it is the build artifacts

48:23 flag or dash a that will pass in the file. So this is saying, hey. I have a bunch of Kubernetes config that I want you to, you know, put these images into. And so we'll pass it that file, and it should spit out a bunch of YAML. Great. So now we can see in the specs for the deployments, it's taken those image names that were kind of the basic name, Leroy web, Leroy app, and put in the fully qualified tag there. So then we can go right back to exactly that image that was built. And so you might wanna, for example, put

48:57 this into a file and then run Skaffold apply against it, and Skaffold apply will apply it into the cluster. I probably shouldn't do that. Oh, yeah. But there you go. So let's see. Apply. We can do dash f just like It is just the file name as a positional argument. That that'll be the the Skaffold commit. Yeah. So, again, very, you know, simple. Right? But you get to take the same configuration file that you've defined all of these reusable parameters for. Right? These things don't change that much, and then apply them at different stages throughout your process. And so that's a very,

49:50 you know, powerful thing that you can kind of bidirectionally influence folks. Right? The developers can opt you know, influence how the deploys are gonna work, and the operators can influence how the development might work. Right? And so that's something that we haven't really had in the past to as as kind of a a key feature in these tools. Mhmm. Okay. So you mentioned something earlier during your slides is that, you know, Skaffold gives me the ability to kind of hook into other tools. Like you said, for the build layer, I can use, you know, Canico or I can use

50:10 Manifest Management (Helm, Customize)

50:20 Docker or something else. What about for the render layer? Does it have the ability to hook into to customize or helm or other things? Like, I can imagine if I want to develop my application, it may have a requirement maybe on some helm charts or something like that. Yeah. So we do support that. So if you go to the examples, we support both Helm and Customize today. We also have alpha support for kept in there if folks are are looking at that tool. But, essentially, yeah, we're we're looking to kind of abstract the idea of manifest management so that you can run

50:50 something like Skaffold Render. And, you know, you can imagine as you kinda put this into the CICD pipeline, you can have a very standardized CICD pipeline where the teams themselves are using a bunch of different tools. And as an operator, you might not have to care whether they're using Helm or customize or anything else. You're abstracted away from that. So if we go on, like, for example, the Helm deployment repo, we can see an example of Helm. Okay. So Helm deployment sounds like I might be deploying my application with Helm. I like like the sense

51:00 Helm Demo

51:22 of dependencies because it makes me think that I'm using something else for my app and Helm for a dependency. That's it. All right, okay. So I'm gonna take a look at Skaffold. It's a bit bigger. Yeah. We got some sort of helm release. And so here, you can really just kind of define it. Know, essentially, we're extracting just how you run Helm. Right? So you can see a lot of the flags that you would pass to Helm are now inside of our Skaffold YAML, and we're kind of putting those as as code. Right? You have, you

52:02 know, skip build dependencies. You have artifact overrides. You have set values at the bottom. So it's really a way to kinda catalog the procedure of how you use the tool underneath the hood. We have very similar pattern for customized. You'll see a customized flags and and things like that. Yeah. I think the dependency thing there was a little bit different as expecting, but it was still useful to see what we could on there. And they So you're kinda looking at, like, I have a Redis chart or something like that that I depend on. How would I

52:31 bring that in? Yeah. You know, I'm working on some sort of roster, Alexa application. It has Redis post grads as backing stores for cache and stateful stuff. Like, I still wanna be able to run those services, but I wouldn't necessarily have, you know, a build step or anything like that to to orchestrate that. Yeah. So in that case, think what what you would want is, like, chart path to actually be a URL. Right? And so then you can point at a chart somewhere else in the tarball for that chart, and we'll put it in. In this case, it's just

53:00 React Hot Reload Demo

53:00 the path on the local file system, but it should work with remote dependencies as well. Yeah. And I guess to this deploy block, I'm just adding my own application stuff as well as that helm dependency for the charter that need. So Exactly. Exactly. And part of our, you know, effort over the next, you know, couple months is to make that separation a lot cleaner and make sure that you can combine a bunch of different tools. Right? You can imagine on your side, you're building with your config with customized, but you depend on something from Helm. Right?

53:26 And so we wanna be able to have both of those be living in harmony. Right now, it's a little clunkier than we'd like. Yeah. Even the customized example is nice and simple. I I just they wanna deploy with customize, and then it just uses my straight up customization dot YAML. So That's it. Yeah. Same defaults where we where we can have them. That's sure. Alright. Nice. I I like how all the bits are kinda joining together. And the just so far, the configuration has been pretty simple, which I like. Though as we were kinda talking and looking at

53:54 React Hot Module Reload Example

53:56 this direction, the React reload one caught my eye, and I think that's exactly what I was talking about earlier. So if I mean, if we're feeling brave, I really wanna jump in there and see if that does what it says it does. Let's test our bravery here. What are we gonna jump into? I've never run this example, so it'll be a surprise for me too. Oh, again, that disclaimer end early. Nice. Alright. So, yeah, it's got a sync, which is exactly what I wanted. So really what I wanna see here, and I'm hoping this does

54:22 what I what I expect, is that when I run Skaffold dev, let that build, we'll have deployable browser application. And I'm gonna just move my terminal over to the browser, but I expect that when I save the file and let's get that ready to so we add real we add reload App index, not source. That's the change of React bit. Man. Nope. Components. Right. There we go. We should be able to change this and I'm curious if we will get that. Like the browser is gonna detect that something changed and do the reload for me. That

55:06 would be really cool. Let's see. That happens, I'm buying you a beer. I'll take it. Take as many as I can get. We'll we'll do an IOU for that one. Yeah. Yeah. Definitely. Keep going early maybe. Sounds great. So NPM install, I mean, no tool in the world can speed that up. But I I think it's Sorry. Yeah. We we haven't gone to tackle that yet. Maybe maybe if we get enough issues, we'll see what we can do about NPM install. Alright. We're almost there. So let's just pop this over. And we'll port. Oh, it's not there yet. Almost.

55:51 K. So it's compiled. Did we do the port forward command on this one or no? Or flag. Yeah. From now on, every Skaffold dot YAML I work with is gonna have the the port forward stuff in it. Yes. That is that is one of the things we've now started recommending it as a as a best practice. We should probably go put that into the examples here too. There we go. Eighty eighty one. That's good. That's the most beautiful hello world we've put together today, I will say. It has color for once. Right. So I've changed it, but I've not saved it. So

56:17 Running Skaffold Dev (React HMR)

56:33 it worked. I did not touch my browser. That was awesome. Very nice. Good choice of example. Let's just for the sake of maybe changing the CSS, I I only know, like, three color codes. So we're just gonna do that and save. What we wanna see. That's really nice. So let's see what actually Skaffold was doing there. Now because it's the sync, I'm assuming it's really just the NPM tool chain. Yeah. And Skaffold, other than checking the files into the container, you're just relying on all those native tools to do their job. Right? That's it. That's it. We we do the the most

57:30 basic thing we can, and a lot of the tools like like this one have that piece figured out. Alright. Well, Thomas Stromberg had fingers crossed and sadly, Dan is also a witness to the free beer. Yeah. Yeah. Dan, you can have a beer too, whatever. Alright. Thank you. We got one slash comment slash question from Aiger. I thought Skaffold is for building containers. No, that is Canico. We had an episode on that last week. You should check that out. It was also a very very cool tool. And I guess Skaffold, I could just set the builder to Canico and have that do

58:02 the thing there too, which would be That's right. Pretty nice. Yeah. And we try to do, like you said, you know, try as little config as possible based on how those tools work to to make it work. So, hopefully, it makes it easy to get with Buildpacks, Canico, any other builder that you can think of. Cool. Awesome. Well, we're kind of approaching our now. Is there anything from the examples that you wanna show before we move on to, like, the I I can. We can do the the test one, but I can also show a

58:20 Custom Command / Test Demo

58:30 little bit more complicated example. I think we've shown a lot of the different features, and I have just one kind of mega example that I can walk through with various pieces stitched together. Yes. But you want to show show us the test one then and then switch over? Yeah. That's good. Yeah. Is is that the structure test or something else? Custom test is the the one we recently added. So one of the things we didn't really have in in Skaffold until recently is the ability to, like, run your unit test as part of that loop. And so that's what

58:58 this functionality does. For each of the images that's built, you can run a command when that image gets done building. In this case, they're gonna, you know, echo hello world again, run a test script, and that's gonna run locally on your machine. Right? So after the image build, you might run a Docker image or you might do Go test or something like that, for example. Right. Okay. So it runs locally on my machine. It doesn't run-in the container or anything like that. Today. Yeah. Today, our the functionality is to just be in kind of the the local

59:31 machine, but we're looking at what it might be look like for running inside a cluster or running somewhere else. If you have input here, you know, please reach out. Awesome. So you want me just to run Skaffold dev as normal here or Skaffold test. Right? Or Yeah. Skaffold test. So, actually, you should be able to just do Skaffold dev, and that should run the whole thing. Alright. Let's see what happens. The certain or a container image build. What's in that test fail? Should we take a look at that just now? Yeah, let's try. Oh, I thought my computer was up there.

1:00:17 It's just that tab. Oh, no. I just computers. Oh, no. It's very unhappy. I think my computer's Our demos have been going way too well. I think something needs to go wrong at this point. Yeah. I struggle a little bit, but I think it it'll cook. It'll be fine. Yes. This is just running go test then. Yeah. So just something basic, but, you know, out of that all whole flow that I was talking about, having to run anything out of band kind of breaks up the model. Right? So you wanna be able to loop in as many of the things that you

1:00:54 need. Some other, you know, examples like I'll show is maybe you wanna test your manifest, right, and doing something like conf task, for example. So is this the logs from my application? We haven't seen that yet. Yeah. Yeah. So most of the other things didn't log arbitrarily. This one shows an example of the log streaming back. So when I said, you know, port forwarding and logging, right, you need to both be able to reach your app, but then also see what your app is doing. So those are are both part of the Skaffold dev loop, and you can also get

1:01:05 Viewing Application Logs

1:01:25 that to run on Skaffold deploy. Yeah. You know what? I'm not sure why that caught me off guard because we were looking at the note logs, and we were looking at the other logs. But for some reason, this one just stuck out in my head. But, yeah, we're getting the logs directly. Yeah. It's hard to differentiate the build from the server starting and not saying anything else. So here, you can kinda see the live streaming part of that. Okay. Nice. Okay. So if built our image is deploying it, it runs a test step here. That worked successfully,

1:01:47 Handling Test Failures

1:01:51 so it just deployed it. If the test were to fail, does that change the the workflow here? Does it does it exit? Does it deploy the older image? What happens? So it keeps the old image if it fails. So it would show, basically, a red text for for the failure, and it won't deploy the new version. We're gonna look at how we can make that configurable and make it do different things if things fail. But at the moment, it will just stop. It won't stop the loop. The loop will keep going. So if you fix

1:02:00 Advanced Demo (Using it all together)

1:02:21 the test, then you can keep going, but it won't redeploy. Okay. Perfect. Alright. That's all awesome. I'm really excited by what I've seen. I loved the little live reload. I'm I'm really glad I caught that directory and we got to see that work into the test stuff is and just all the different components and the ability to slice and dice the commands to do the each step that I need for my worked really well. So why don't we hop over to your screen now? Cool. You're gonna walk us through something a bit more feature complete complex. I'm not sure what word

1:02:58 to use, but I'll let you take it away. I think that both of those should apply. So so, basically, what I'm gonna try to do in in this example is is tie it all together. I'm gonna close all my my tabs so I can get oh, and it's closed. One too many. There's a cool Versus code plugin called macros, and I've got, like, command l map to close all the window tabs. I recommend it. I will do that after this, I guess. Let's see. So reopen here. Apologies for that. So I've got kinda just show the structure here of things.

1:03:00 Complex Multi-Module & Policy Demo

1:03:34 So I've got this sample app. In this case, I don't have tree installed. In this case, it has two components. One is the back end, and that's gonna have its own Kubernetes manifest. And it's a Go app that is built with a Docker file, and then it also has a front end. So very similar to our microservices example. It also uses a base image. So then I have, basically, my user creation in in my base image. I have command to run within the app in my base image, and then I leverage that in the front end and back end. And the way

1:04:08 I'm tying that together is with a root level Skaffold YAML, which brings in three different modules. One is the test module, the other is the back end module, and then the front end module. And the front end module, as we'll see in its Skaffold YAML, depends on the back end and the testing module and the base image. So let's go ahead and go into the front end. Let's say I'm a front end developer, and I want to run my dev loop. I have at the bottom here, you'll see my port forward's already defined. So if I just run

1:04:45 Skaffold dev, that should work. Let me just real quick. Oops. Let me get my Docker socket back. Alright. So now I have my dev loop right, and you'll see in here that I'm doing the test phase, and that's gonna run a Docker image. Right? So I get the image that was just built, and I run a a script inside of it. And what I'm gonna do with that script is this validate script is gonna build my configuration and then run contest against a set of policies. And those policies can be in your own repo. They can be in a shared repo.

1:05:25 But it's things like, you know, the containers not being able to run as root. Right? So if someone were to change, for example, the Docker file or change the app in some way that required it to run through, they you would be able to block that via the contest. So so here, I have my application running. And let's say I wanted to you know, I was slightly a nefarious developer, and I wanted to run my app as as a as root for some reason. I would go and try to change this, you know, run as non root to false.

1:05:59 And if I did that, my dev loop would start again because it's part of my application that I want, you know, realized in my cluster, and then it's gonna test. And I can see here that it actually failed. Right? And so I can now have this feedback about my configuration at the time that I'm developing. So then I can change that back and get back within, you know, the organizational policies that constrain me. And now I can develop again, and it's deploying, and everything's back happy. Right? So I just wanted to show kind of the the whole end to end with modules

1:06:31 connecting to the each other, right, from the front end and back end, shared base module for an image, as well as the ability to have some shared testing framework, like, for example, for your Kubernetes manifest that you can use across multiple repositories. And that was basically it, unless there's any other questions you have there. Nice. That was awesome. And let me get us back to. There we go. Cool. Well, I think that was quite successful. We actually I thought I got broken this and that's rare. I I am, you know, I am counting my lucky stars. I I think today's a lucky

1:06:50 Conclusion and Wrap-up

1:07:11 day for me because I've never seen, like, six or seven demos run pretty flawlessly. Maybe it was the operator that really did it. Yeah. Definitely. That's exactly what it was. Just no. I'm really impressed. Like I said, it's been a long time since I've played with Skaffold and it's really nice to just see how it's bringing a really almost like fluid, almost intuitive developer experience to have us just want things to work. So really impressive stuff, and I'm looking forward to seeing what's gonna come next with the Skaffold project. Awesome. Thank you so much. And if folks wanna

1:07:43 Get Involved with Skaffold

1:07:45 engage, we have the Skaffold project on GitHub. So please, you know, meet us there with some issues or comments or questions. We're also on Stack Overflow. Alright. Well, you heard it there. Check it out. Play with it. If you have any problems, reach out on GitHub, Stack Overflow, etcetera. People will do their best to help you. Vic, thank you for joining me today. Really cool. Really happy with that. I will speak to you again soon and have a great day. Awesome. Thanks, Dave. Bye.