Overview

About this video

What You'll Learn

  1. Write a Tiltfile in Starlark that defines local services, Docker builds, and Kubernetes resources for each dev run.
  2. Use Tilt live update to sync code edits directly into containers, with targeted rebuilds for edge cases.
  3. Load Kubernetes dependencies with Helm through the kustomize/helm remote flow inside a single Tiltfile setup.

Dan Bentley and Ellen Korbes show how Tilt automates the inner loop for Kubernetes development. We write a Tiltfile in Starlark, build a Docker image, deploy via kubectl and Helm, and use live_update to sync changes without rebuilds.

Chapters

Jump to a chapter

  1. 0:00 Holding Screen
  2. 1:15 Introductions
  3. 2:00 Is developing against Kubernetes easy?
  4. 2:45 What is Tilt?
  5. 4:20 What does Tilt achieve?
  6. 6:00 Can I use Tilt to develop ALL applications?
  7. 7:45 Tilt doesn’t use YAML, y’all!
  8. 9:40 Should all development teams use Tilt?
  9. 10:40 Installing Tilt
  10. 12:00 My first Tiltfile
  11. 13:00 As usual, I mess up. We need a new plan
  12. 15:00 Incremental Tiltfiles (This is cool!)
  13. 16:00 Building a Docker image
  14. 17:00 Shit, create a Dockerfile very quickly
  15. 19:30 Adding Kubernetes manifests
  16. 20:00 Adding VSCode plugin
  17. 21:00 Using Tilt CLI mode
  18. 23:15 Exposing our application locally with a port forward
  19. 27:00 Adding dependencies to Kubernetes
  20. 29:00 Improving performance with a .dockerignore
  21. 51:15 Deploying dependencies with Helm
  22. 1:02:00 Looking at the available build-in functions
Transcript

Full transcript

Generated from the English captions. Timestamps jump the player to that moment.

Read the full transcript

1:15 Introductions

1:15 Hello, and welcome. You know, I used to really like the ending of the intro, and that noise is really starting to create on me after 18 to nineteen fifty six. Oh, I like it. I mean, the noise is a bit grating, but, no, it's like it's a joke. Like like, it has a narrative. I like it. I took a lot of inspiration from the IT crowd. I don't know if you've seen that. At the end of their intro, it's like this annoying crashing noise. Yeah. Yeah. Yeah. Have you tried turning it off and on again? Exactly. Exactly.

1:43 And so thank you for joining me today. I'm here with Dan and Alan from Tilt. We're gonna take a look at how to make development against Kubernetes easier. Welcome. Thank you for joining me. Yeah. Thanks for having us. Good to be here. Yep. Looking forward to talking a bunch about, you know, containers, crashing things, that kind of stuff. Well, isn't the goal in dream of containers that it makes all of our lives easier? So, you know, developing against Kubernetes should be by association easy. Is that correct? That is Yeah. Should be. Sorry, l. I think I spoke over you

2:00 Is developing against Kubernetes easy?

2:23 there. Yeah. It's kinda hard to coordinate. Right? We should have, like, a little arrow or something. No. Yeah. So developing Kubernetes should be very easy. Unfortunately, out of the box, it's not. But fortunately, there's people like me and Dan working on tools to make that the case for you. So not all is lost. There is still hope. So let's start with a basic question then. What is Tilt? Yeah. So Tilt's like a little it's a program that runs on your laptop and it watches what you're doing. So, like, as you're coding, it sees what files you're

2:45 What is Tilt?

3:05 editing, and it will run workflows, like building container images and Kubacuddle applying them and everything you need to do as you're developing. It will run those workflows, and then it will show you what you need to see, which sometimes is logs from the running containers. Sometimes it's build errors from the build. Sometimes it's, hey. Your YAML is misconfigured. Sometimes it's this unit test is failing. And to to save you from having to play, like, 20 questions with Kubikudal to figure out where the problem is as you're developing. Okay. So Tilt is a sorry, Tilt is a tool that allows me to

4:02 describe my application components, and then it monitors my source code, and then makes magic happen, and my things run on Kubernetes. And then you go a little bit beyond that and you allow me to see logs. Is that a good summation of what you said? Let me let me interrupt you a little bit. So Dan talked a bunch about basically the headaches that Tilt saves you from. But I think it's also important to note like what it is that it achieves once everything is up and running. And then basically, right now, basically by default, let's say, Docker and Kubernetes,

4:20 What does Tilt achieve?

4:40 As you're developing your application, every time you make a change you have to kubectl apply, docker build, docker push. You have to do a bunch of things. It takes time and most importantly, in my opinion, it takes cognitive effort. So as a developer, you have to stop coding and then get distracted typing a bunch of commands. So one is that Tilt saves you from that. So everything is automated. You basically save your file and your application gets updated live on your developing cluster. Then you can test the functionality that you just wrote or you can go on and keep coding.

5:14 The other thing that it does is, one, it automates it and the second thing is it makes it very, very, very, very fast. So you can have that workflow where every time you make a change you rebuild an image, you push it to a cluster, the cluster Kubernetes spins down one version, spins up the other one, that whole thing. But that takes time. And Tilt also allows you to do what we call it live reload, other tools call it hot reload. Basically, what this means is you save your file, the file gets synced up to your

5:43 cluster, everything updates inside the container without killing the container. And the results of all this is basically you save your file, you blink your eyes, the new version's up and running. So, you get that lots of people mention that they miss that instant feedback from when they were working on, I don't know, Ruby on Rails or something like that. And basically, Tilt lets you achieve that but with containers running on Kubernetes. So it's maximum convenience and zero headache once everything is set up. Okay. So I guess it's fair to say then that Tilt exists to make people's lives easier developing against Kubernetes.

6:00 Can I use Tilt to develop ALL applications?

6:23 Now are there any opinions with regards to the toolings that I can work with, or can I use Tilt to develop any application? Yeah. This is this is really important to us, because, like, some tools like, Bazel or Kubernetes itself are very opinionated, and they're like, we're going to get you to a great place once you adopt everything that we believe. But with Tilt, we're really into mister Rogers onboarding, where mister Rogers, longtime children's television show host, always said, I like you just the way you are. Tilt likes your project just the way it is.

7:04 However you do YAML generation, whatever you use to build images, however you're running things, we want Tilt to have the right, escape hooks so that you can, make it fit with your project, whatever you're doing. K. So that sounds great then. I can use Tilt to describe my application, make developing against Kubernetes easier, and you don't have any you don't mind which tools I'm using. So that sounds pretty awesome so far. I'm impressed. Now do you sorry. One yeah. One important detail is that most tools that are kind of in the same realm as Tilts, they use YAML as the

7:45 Tilt doesn’t use YAML, y’all!

7:46 config file. So the way you declare all your services and you do all your automation and etcetera is using YAML. And, YAML is a flat config. It's not like a programming language. It's not a full fledged thing that can do anything you want, basically. It has tons of limitations. And, a big advantage of Tilt and even before I joined Tilt, it's one of the things I was working for another company in this realm and I was thinking, Oh, damn. If only we could do that. And that is the fact that config files for Tilts, they're made in Starlark.

8:17 And that is basically Python, slightly different. So, you have loops, you have variables, you can open files, you can run system commands, you can do anything you want. So, it's very easy to adapt whatever you have. And when I say whatever I mean it because we have people writing extensions for Tilts that we could not even have dreamed of before. People are automating stuff that we need to stop and think to understand what they're doing because it's something so, basically, so outlandish for us. And what this means is, literally, whatever you're doing, if your computer can run it, Tilt can work with

8:52 it. Okay. So you're removing YAML from my life, which right away gets a tick. I'm very happy with that. But I have worked with with that language before. Sorry. Starlock. Right? That's the one. The same one that Bazel uses. Is that correct? Yes. Or okay. And I have found that quite difficult. So I'm looking forward then today to learning how I can put that behind me then because I I tried to write Bazel build files before. I love the idea, especially as organizations are adopting mono repositories of using Bazel as a build tool. Unfortunately, that means you have to run Bazel as

9:27 a build tool, which I've not really appreciated yet. Yeah. And a part of that is config. The other part is that I generally never have Java on my machine. So there's a few things there. Tilt is not running in Java. Is that right? Correct. It's Go and TypeScript for the UI. Nice. I I like TypeScript, and I definitely like Go. So that's we're we're running there. As far as, you know, Tilt Go, is this something that you feel that all development teams deploying to Kubernetes should be using for their development environments, or are there any caveats

9:40 Should all development teams use Tilt?

9:57 around the usage of Tilt? I we we say if you use Kubernetes in prod, you need Tilt for dev. I could imagine, like, maybe you just have one Kubernetes deployment and, you know, it's it's pretty small, that image of, like, just the one box, you know, on the back of a container flatbed. But if you're if you have multiple deployments, if you're really using Kubernetes, yeah, you should probably be using Tilt, I think. And if not, you know, do at me, which I think is something that people don't say that much. Alright. Perfect. I think

10:40 Installing Tilt

10:48 my my interest is piqued. So I think we should share my screen. We should go through the installation and we should start to see how Tilt is gonna make my life easier. So let me pop up the screen share. There we go. Alright. So I'm on the GitHub repository. Is this the best place for me to install it or should I go to tilt.dev? Oh, I think if you go to docs.tilt.dev. Here you have the here you have the fancy guide and you just copy the instructions. Alright. So I can install Tilt with a nice

11:33 little curl command. And I will allow that to paste. And I'm sure this won't take more than a few seconds. I've never had troubles with installations, and that's a complete lie. Every time I try to install something on the stream, I seem to break through or my Internet goes down or anything. This is looking much better. Finger crossed. Excellent. Okay. So what it's it's okay. So step two is I install Tilt. Let's assume this is gonna complete in the next few seconds. What what's my first step if I have an existing project to to integrate Tilt into my development workflow?

12:00 My first Tiltfile

12:19 If you go back to the docs page, there's a tutorial, the first fifteen minutes. And awesome. So what it says there is you're gonna need the Tilt file and, you know, there's a Dockerfile and Tilt has a Tilt file. It's basically in the Tilt file, you're telling Tilt, these are my services. This is where the the Docker files are. This is where the YAMLs are. Run the whole thing. Basically, that's what that's doing. Okay. So we configure Tilt through a Tilt file and then these these functions, extensions, what do we what do we call these? Functions.

13:00 As usual, I mess up. We need a new plan

13:01 Those are built yeah. Those are built in functions. Alright. So we have functions to represent all of the different tasks that I may have to complete. I guess this is goes back to what you were saying about other people building these integration points for for libraries and tools that necessarily then directly come out of town. Okay. Now I realize I've already made one fatal flaw with my ex I have a application that I cloned and that this is not a daemon. It's not a long running process. So I maybe want to pick something else. Is that correct? What is it?

13:38 It's just a CLI application, which I would never deploy to Kubernetes, and I clearly wasn't thinking straight. So I will quickly grab something else. Let's be brave. So okay. I guess I need to fill in a few blanks here before I see a project. Now as part see, I have a like, this can I deploy today project as a static site, but it needs to be compiled first and to those assets and then deployed into container, and then I could deploy that to NGINX to Kubernetes with NGINX? Is that something that would be a good fit for the Tilt

14:25 workflow? Let's let's see. It it it certainly should be for, like, the first level when we get to how you can really make it fast. There might be some interesting questions and caveats. Can you repeat that description? Because I got a bit lost. I'm trying to think through the mechanics. Oh, yeah. Of course. No problem. It's it's a a Next. Js website, which means what I need to do is build a container image which runs the next steps, which kinda gives me some HTML, CSS, and JavaScript into a directory, which I would then want to bundle into an NGINX

15:00 Incremental Tiltfiles (This is cool!)

15:06 container and have that run-in Kubernetes. Okay. I think I stand with Dan in that we'll see. Yeah. Okay. Sorry. This is my fault. I didn't really think about using the CI application here, and then it just hit me as we were talking. Like, that's not gonna work. Like okay. Because I would never deploy a CI application to the for that. Alright. So I can create a Tilt fail. And I'm assuming I I'm just gonna kinda make some assumptions here. Please feel free just to correct me any point. But I'm assuming the first thing I need to do is

15:43 build some sort of image for my application. Oh, I I oh, we we now I'm I'm the one who's a bit embarrassed that we don't see this more clearly in the documentation. You should just tilt up, and tilt will watch your tilt file so you can like write it interactively. Here here here's what you do. You create a tilt file and just just put a tilt file there first and tilt up and let's see what happens. And then we're gonna increment your Tilt file as we go. Interesting. Alright. I like it. Okay. So I've got the the Tilt UI.

16:00 Building a Docker image

16:31 Okay. That makes sense. That's pretty cool. I like that. So no resources found. So you were looking at the Docker Docker build function. So let's try putting one of those in your in your Tilt file and let's see what happens. Okay. So I'm assuming this is the tag for the image. So can I deploy as okay? So this is the the image name. Is this a tag on the end? Tilt will put those in. So Oh, okay. So what what what's the second parameter then? That's the directory that you'd like pass to docker build. Ah, the context. Got it. Okay. Yeah. So

17:00 Shit, create a Dockerfile very quickly

17:19 I can just put a a dot there? Mhmm. Yep. Alright. Now I guess it would make sense if I had a docker. So we can do this quickly. Copy dot slash code worker code, and then run NPM install. And if I check my package JSON, export. And but I guess right away what I'm noticing here is that I just use my standard dev tooling to a certain degree to get that container image, and then this is where Tilt kicks in and handles all the complicated orchestration components and getting onto Kubernetes. Mhmm. Okay. So we'll call this my deploy step, and

18:21 I'll copy from zero codes. I think it's public. I'll I'll get this wrong the first time, but it'll be it'll be okay. Now should oh, code public. Copy it to here, which is the standard NGINX directory. Okay. So my first question then would be, would it make sense? Because I am not got a % confidence in my ability to write a Dockerfile that quickly. Now should I be running Docker image build locally till I'm happy with that process, or is that something that Tilt can do for me when I add the the function to build the image and get the

19:05 errors back? Exactly. That that latter one. Yeah. So if you just, like, yeah, try saving. Let's see what happens in Tilt. Okay. So let's go back to our Tilt UI. Alright. It it's something Okay. So it says that it's kept my image build because it has nowhere to deploy it. Yep. Now you need some Kubernetes YAML. Alright. Unfortunately, I can generate that pretty quickly too. So let's have a deployment dot YAML. I love this. I don't know who wrote this Kubernetes plug in for Versus code, but it just simplified my life to no end. So

19:30 Adding Kubernetes manifests

19:53 the first question I have now is that I know how to deploy NGINX. What I don't know how to deploy is my Tilt one. So do I just put that first parameter from my Tilt fail, which is can I deploy? Yep. And that's it. Okay. Oh, I didn't add the YAML. Okay. So that's that's first lane here. K. Tilt fail. Is there a Versus code plugin for Tilt? Not that I know of. If you set it to Python, it will be fairly close. It will give you syntax highlighting, but we'll complain about undefined functions. Well, we can just ignore that. So I

20:00 Adding VSCode plugin

20:41 I think someone wrote an extension to parse Tilt files as Starlark. I I think someone maybe that's only when you look at the source code on GitHub. I don't know. But I think there is something for Versus Code. Also, something something that we don't recommend anymore, but it's also a possibility. So Tilt has has a CLI mode. So run it runs things in the terminal and then you you don't use the the dashboard on the browser. You can run that CLI on the terminal inside Versus Code. So that's something you can do. But we are kind of phasing out the

21:00 Using Tilt CLI mode

21:19 CLI and using more the browser dashboard. So I'm not sure I would recommend that, but it's a possibility. So just so I can kinda see it, what was the how do I do the tilt in this command line mode? I guess it's tilt up. I think you do tilt up, but you'll need to kill the other to run Or just or just use another parts just to see it now. So just tilt up dash dash parts and just put, like, ten three five six or something. Okay. So is is dash leg dash dash legacy the mode we're talking about? No. No.

22:03 No. Just tilt up dash dash part and put some random number there. Yep. And now press t. I quite like it. Okay. So I'm assuming that my web one is still running, means yeah. Yeah. Now you're doing all the work twice. So ideally, you would choose Yeah. We'll we'll stick with the web UI. I don't wanna use anything that's gonna disappear eventually. So so what happens here is okay. Let me scroll back up a little bit. So when we added the Kubernetes yep. Alright. So no that's my broken YAML. I fixed my broken YAML. It started building an image,

23:01 which actually appears to have worked. It did not push it and then it deployed my application. So it could actually be running. Yeah. What what you would do now is add a port forward so that you can then access what's inside the container from the your browser and local host. And would I do that using my Kubernetes tooling or is there something tilted? Oh, no. No. Just just tilt. There's a maybe go back to the docs, and and then you can just copy and paste there. Where is the part forward? Yeah. That it just yeah. There we go.

23:15 Exposing our application locally with a port forward

23:50 Okay. So I can I think that's going to be engine x? It's the name of the the name of the Kubernetes object. Yeah. That makes sense. So that's automatically just gonna rerun that again, I assume, and it's now rebuilding our image. I mean, so right away, it's already taken away three of the major pain points I have when I developed against Kubernetes. And now if you go to NGINX on the sidebar? Oh, and if you either opt out or opt in to the analytics, now you can see the port forward at the top. Yeah. Engine x.

24:55 So that also means my Dockerfail worked, but didn't really work. I mean, so let me just clarify that then. Let let's focus on the wins. It works. So I ran an NPM run. I don't know. Export. Export. It was export, wasn't it? Mhmm. And I'm assuming that the public directory was oh, no. It's the public directory. Oh, no. Out. L s out. Okay. So it copies it from public, puts it into out. So I just got that wrong. So now I can update my Docker file. And, this is just gonna just take that change and

25:41 work. There we go. So I guess my question now is, this is leveraging just my vanilla Docker setup to the point that I'm gonna still get advantage of, like, all my build cache. Although my Dockerfile is not really made for caching right now with that copy doc. You know, if I optimize my Dockerfile here, it's only gonna rebuild from certain stages. Okay. Yes. Yeah. Go ahead then. So it uses build kit if you have it installed by default, so you can use those. And now what you're getting is the, you know, automated nature of it and the UI. So if

26:27 you have more services, you can see them in the sidebar and, like, flip between them, but we haven't done the the live update piece to make it faster at all. Okay. So in order for us let's let's assume that this application is a bit more feature complete than, like, in a static site. So say I optimize the Dockerfile so that we don't have to do the NPM install every step. I think that's gonna make this a lot quicker for what we're doing because the export takes less than a second. And then I wanna add a database. Can

26:59 we kinda go through the process to see multiple services here? Yeah. You you would make another call to Kate's YAML with the YAML for your other service. Okay. So let's assume let's add Postgres. Alright. Yeah. So I could so these would be would these be the same production YAML images that I used, or would there be anything there specific I have to do or tweak for this? You might not want as many, like, instances as your production. What we've seen teams do is, like, if you're already using Helm or Customize, you, like, have, you know, a different set

27:00 Adding dependencies to Kubernetes

28:03 of values. So it's, like, the same base template, but you might have, you know, just slightly different values so that you don't have, you know, your development instance taking as many resources as your production instance. But otherwise, the same. Yeah. Okay. So I need to I need to add my new resource. So I don't like this resource. I know I would never do Postgres this way. So I'm gonna do it because I'm curious, and then maybe we could talk about how I would choose and customize to tweak my NGINX deployment, but hang on for my Postgres one. Because

28:44 I feel like if I were trying to build a production, like, development environment, Rawkode, that's the tools I would be that's the tools I think I would choose. Yeah. Yeah. Alright. Oh, Postgres is now spinning up. So does the orange mean it's pending? It's working. Yeah. Oh, no. No? Yeah. Orange means there's an alert, and you can see that it's in a a, yep, back off loop. Yeah. I did provide the passwords, but she cannot spin it up with the telling them the passwords. Environment, postcard password, password, make it secure, one, three. Yeah. It's green. Nice. Okay.

29:00 Improving performance with a .dockerignore

29:41 Although, does this orange bit mean I broke NGINX? That's that's gray bit. Sorry. Let's oh, it's because your Docker context for NGINX is docked. It, like, includes the postgres dot yaml. And so you can there are, like, optional parameters to the Docker build so you can, like, ignore YAML files and things. So Tilt was, you know, being helpful about something. You know, you didn't actually care that this YAML was in there, but but it was. Well, that respect my Docker ignore, I guess. Okay. So I could do a Docker ignore, and I'd say I mean,

30:28 I can just just start on YAML for now and not that fast. But I'm assuming that in itself will trigger one rebuild, and then I'll be back to normal. Okay. Yes. I I agree. Let's see if the computer agrees with I mean, we're up poking it. But Alright. This is this is cool. So I tweak my Dockerfile. I'm using the build cache to avoid a painful MPM install, and this is much faster now. Like, that was a few seconds, and I had my deployment. Now the question is, did I actually fix it or not? So

31:03 no. No? Oops. So I take my challenge now. I will try one more time and then we'll just ignore it. But if I do run our MIT engine x and just go and save this, I think maybe I got the directory wrong. So if I look at the engine x dot conf, take a look at default. Yeah. There we go. So I just mounted it to the wrong path. Easy mistake to make. This goes here. And then I will watch this nice little UI. It should go green pretty quickly. These moments when we're waiting, always like to

31:56 think of silly computer jokes to tell. Like, you know, I I would tell you a UDP joke, but then I might have to tell you again. So Hey. There you go. Alright. So my website, my million dollar application here, can I deploy today? Yes. It is working. Okay. Do you wanna do you wanna make changes to it? Maybe tweak that text and see how long it takes? Yeah. Good idea. So I can open up I mean, don't still have a source code. This is gonna make me millions, but it's can I deploy today? Yes. Definitely.

32:42 And then we come back. Shit. So now we're building an image and that's why it takes a minute. Now I have no idea how we're gonna use, live reload on this setup, but I'm very curious to find out. Well, we could give it a go. And if it doesn't work, I have ahead of time pulled up some of these example applications. So we can always pull down one of these. But we can we can go through the the motions of how we would do this. And then if it doesn't work, we'll we'll reevaluate. And I'm also keen

33:21 if we don't forget just to stop using YAML for Postgres. I'd really like to see that help integration as well. So if you go to the doc site, and you go down yeah. The under enhancements, the first one is faster development with live update. Okay. So And so the key here is it's doing docker build, but, like, with live update, you're telling Tilt, like, hey. Yeah. You can always still do a docker build, but there's also this, like, faster path where I want to sync files from this directory in you know, on my laptop to this

34:17 directory in the running container. So then what do you think we should suggest here? Should we rebuild the NPM export stuff locally and then sync those files to a running container? Or how would you do this? So I think, you know, part of like like, we want Tilt to work with real cases. And so, like, in real and developers come up with shortcuts even though they don't, like, always work. And so what I do is probably have a live update that just syncs, you know, the PHP file to the the right place and kind of skips the

35:03 export, which could get out of sync. And if it does, you can, like, click rebuild in the UI, which will have it fall back to the image build. So I think that will, like, work in the, like, 90% case. Okay. So let me make this easier for you both. We don't need to use the the export. Let okay. I think I know okay. I think I know what we have to do, but what I'd really love to understand is just a little bit about this live update syntax. So what this does, if I've understood correctly,

35:40 is runs a container and is managing the file synchronization into the container and then running an arbitrary command when those files change. So what is the container that is running? Because I have a multilayer Dockerfile. Is that why this is a little bit more complicated? Yes. It's Tilt isn't maintaining a separate container. It's just the container, like, that you're already running. Ah, okay. Right. I got it. I got it. I got it. So the where you have the text highlighted there, the line above it docker build, it's doing the same as you saw before. It just builds a container.

36:24 What happens is when the files specified in the first arguments to the sync function change, it's going to update those files inside the container. And, of course, sometimes you need to run a special command like if your requirements change then you need to pip install your requirements in that example. I hardly ever use the run function, just the sync function. So basically, just tell me if these files change locally, update those files inside the container. And basically, that's it. Okay. So I think I know what we need to do. I'm sure I'm wrong, but I'll try anyway.

37:04 So we want to add a new parameter. So it was just this, and I'll put this down here so it can imagine for example. And I want to think So this run trigger runs inside the container. This sync so with that sync, I mean, it expects me to run, like, an okay. Sorry. I'm not making any sense right now. Let's take this out for two seconds, I'll show you what I mean. Is there comments in the top file? Yes. Mhmm. But they're Python. Yeah. Okay. So we don't need to use the export. If I come into my Dockerfile, and let's

37:50 just forget engine x, then we can run the NPM dev server. Then what we can do is NPM dev, which should give us a more interactive style environment. Let me just check. Yeah. So we can just do this. I think and then do you want that as an entry point? Because I think run will run it, like, while you're building the image. Good catch. I definitely do not want to run it in the image, so that was a mistake. Yeah. So we want entry point. We want dev. And if I look at our UI, let's see what happens here.

38:31 Because this is not a long running process and then you run that container. Give it a second. Well, we broke. Run that. What's developing without a few errors? Always my errors, of course. Never the total. It's just me. You know, that was saying pepcak, you know, problem exists between keyboard and chair. That's definitely true for me. Yep. That's why I use a standing desk, no chair. Alright. We have a dev server. So the first hiccup is this port change, which I can fix. So that port is coming from our app here. Oh, no. So that's a local port. So

39:46 that's not contained Yeah. I think it's coming from the Dockerfile or oh, no. This one. You're right. You're right. Which should reload, and then this shouldn't have changed here. So when that goes green, I hopefully, I can just reload this page. I think I think there may just try it again. I think it it you may just have caught it in the middle of the port forward. Yeah. Didn't didn't oh, there you go. Perfect. Okay. So now I think we're in a position where the live update sets the model that you kind of expect. So

40:30 let's take pause because if this works right now, it's gonna feel just like magic. Let's go and do some magic now. Alright. So I open the Tilt file. I'm gonna bring this code back in. And I think you don't want any run. You just want a sync. Yeah. Yeah. I'll I'll comment that out for now. I I just wanna test the run trigger thing. I'm a I'm a bit curious about it. And then this sync is what the files I expect to change as part of the build statement. Would that would that just be dot, like, when

41:07 anything changes? I think you yes. That should work. Or would it be public, which is where I guess? Yeah. The the thing is you need to choose what's gonna go where. So you need to know what locally is gonna sync to where inside the container. So if you sync dot, it's gonna basically put everything in your everything that's open on the sidebar there into the container. I think you don't want that. Alright. So if I want to sync the pages directory, which is the one I'm gonna be modifying, and then I put that into oops. So where did I meant that? Slash

41:47 codes. Yep. So slash codes slash pages. Mhmm. Mhmm. And let's pull up our UI, which is now my source of healthiness, I guess. And if this works, I should be able to change my my code HTML and set the pages directory, and it will not do any more rebuilds. It would just match Yep. Let's try. Exactly. Alright. So that reloaded. Let's modify. Let's fail again, and let's just revert it. And I got hot reload from from JavaScript. Yeah. That was awesome. That was really cool. And if you go to the Tilt UI, you can see what it did there.

42:42 One zero point one second to get that change onto the container. That's what that means. Right? I thought just made that up. Yep. 0.13, I guess. There's some rounding. I'll take it. That's okay. Alright. Yeah. Alright. That's impressive. Color me impressed. So sorry. Need to go ahead. And the the fun thing is that I think most front end developers are used to having this live refresh depending on the framework they use but not inside Kubernetes. Now you're doing this inside Kubernetes. Sometimes we use a front end application to show what's going on because it's easier to

43:23 see. Then people think, I've seen this before in such and such framework. But that's because we're just showing it using a front end because it's more visual. But this works for Go code. This works for whatever back end language you're using. So anything you're putting inside a container in Kubernetes, you can use Live for Load for. Very cool. Okay. Alright. So this run step piqued my interest. So I'm curious, If I modify my package dot JSON, which is kind of, hopefully, parallel to what is happening with the Python example, is that and I say trigger this failed

44:00 changes, then run so that would be slash code and NPM install? Yes. And you could even say, you know what? I don't want to do that in the running container. In that case, I want to, like, just go back to, like, doing the fresh Docker build. So run should do what you described in the container, or there's also this fallback on function that lets you, like yep. Change it. So it's, the power is in your hands. Okay. I'm sorry. What was the You should do what you said. Oh, so automatically so if that command fails,

44:53 it will fall back and rebuild. Is that Yeah. And and so I think for this to work, you need to also have a sync step for package dot JSON because otherwise, it will go, oh, like, package dot JSON. That's a file that I don't know how to sync. So, like, you know, the idea that we have with a live update is that, like, when it doesn't know like like, you're describing a fast path, and sometimes you fall off that fast path, like, if it doesn't know how to sync package dot JSON. So let's try this.

45:32 Yeah. This should work. Alright. So let's modify package dot JSON, and let's add I guess we could bump up a version here. Right? So let's hope test package is changed. Yeah. Okay. We've got a few versions there. So I just saved this. Yeah. There we go. Cool. That that is that's a very nice feature. I like that. Let's tackle Postgres. How do I how do I okay. Let's how do I get rid of this Postgres book, Yamal? And how do I consume the Helm chart? Or So delete that line, and we should actually check perhaps,

46:35 Tilt didn't delete the resource, in your cluster, which maybe it should, that's a different discussion. Okay. So I think I understand the challenge there. So postcards are still running in my cluster. Now does so what I the first question that popped into my head there is if I remove that from the file, Tilt reloads that file, that resource no longer exists in its vocabulary. Do you store anything within the Kubernetes side on annotations or labels to identify something as a tilt orchestrated resource? Yeah. Yes. There's metadata. There's a managed by tilt annotation, and it turns out that, like, there's a lot

47:25 of different expectations you could have for these. And so I think if you run tilt down, it will delete everything. Yeah. And so it turns out life cycle is hard. And in most of these cases, because it's a development instance, you know, it's it's kind of just acceptable to say instead of figuring out a model that the tool understands and you understand, just, you know, delete everything and start over because, you know, this is kind of a way to make your development instance cattle in as opposed to pets. Alright. Let me throw one and a half

48:11 questions at you there as a follow-up. So does Tilt Care of my Kubernetes cluster is local or remote? Nope. So as the if I have a that was a very quick answer. I like it. If Kubernetes cluster is remote, what if two developers are using Tilt at the same time against the same cluster? Are there challenges there? Or does that just work? So I'll I'll maybe put an asterisk. Tilt works with either local or remote, but it has kinda like like, in it will special case local clusters to, like, you know, push things in more optimal ways.

48:50 Like, it can skip the push, and it will require you to, like, say which Kubernetes context are allowed if it's not a local cluster so that you can't, like, just start up Tilt against a production cluster. And so if this were a remote cluster, you'd have to kind of say, like, yes. I want to use this context with Tilt. And you'd probably also like, there's an extension to add namespaces to objects. And so, like, in the Tilt file, you could, like, take all the objects that you're passing to Kubernetes YAML And, like, you can use you can, like, add your

49:36 username to that namespace by, yeah, using a function called local in the tilt file to run a command. So you'd, like, have a call local who am I, which would return, I don't know, d mckay or Rawkode or, like, awesome dude or whatever your username is. And then that would actually be a value in the Tilt file that you pass in as the namespace. Okay. Got it. That makes sense. I hear a cat. Oh, yep. Oh, yeah. There is a rule. If you have animals, they always have to join us. I'm actually Can you full screen the cat?

50:24 Yes. I can. Hold on. He's our he's our Trigger, which is to say he has three legs. He's a rescue that we got a year ago, and he is a very curious and bitey guy. I'm actually surrounded by animals. So I've got five chinchillas over here, and I've got my my ferret over here who's free roaming, who sometimes joins the stream just to say hello. And I have some some diggers in the other room. And they're just over there chinchilling. They are just chinchilling. Yeah. But I had to turn my desk around. So my desk

51:01 in this office is a really weird angle because people just kept asking me about my animals during stand up all the time. Like, oh, what's that? Sure. Not that I don't like talking about my animals, of course. But Yeah. Alright. Let's do the Helmy thingy. The Helmy thingy. If I just search for Helm, then Yeah. Let's let's see if our documentation's up to date. Yeah. I've been impressed with it so far. So I am just gonna copy the I'm gonna copy the bit more complete one. I'm feeling adventurous now. I'm getting the hang of this. So

51:15 Deploying dependencies with Helm

51:39 I'll be back in a second. Yeah. No worries. Oh, no. That's interesting. Okay. So this is actually creating the YAML and then I'm parsing it into a function. Okay. I need to discuss by my chart. Now would that use Helm repositories that I have configured locally, or it's just something I need to do special there? It oh, you know, one of the advantages of having a team is that other people I'm not entirely sure. So let's see. We also can deploy a remote helm chart, which we talk about. And let's, yeah, let's let's let's venture forth and see which

52:29 rocks we crash ourselves into with gusto. Sorry. I am no stranger to reading documentation. In fact, the original name of the stream was RTFM with Rawkode, but people voted against it on Twitter. So I I got rid of it. So let's see. We can load a remote chart. We give it a name, and then we can execute it like so. So let's see if I can work this one out. If I go to the Helmholt and search for Postgres, Let's use is that the only four? That's not right. Let's try MongoDB. Give me a chart I've used before, please.

53:34 Alright. Let's just pick something around on that. It doesn't have to be a database. Let's go with Bitnami console. So that's a okay. So extension helm remote. I don't think I changed that because I'm obviously loading some sort of extension, given that name, and then I have this chart name. So for me, would that be no. I don't know. So I do not have a local chart. I think I'm gonna rate it with this extension. So I think if you go for more options, see the Helm remote read me just a bit below your mouse,

54:25 there's a link there. There we go. There. That's kinda that makes more sense. Yeah. This example was not great for me, but this one definitely helps. Alright. Oh, Oh, chart name will be we said console. The repository URL I copied from Helm Hub. I'm gonna give that a name of Bitnami. And I wonder my console And so the values here is a list. Is that multiple value fails or is it key value pairs? Value fails. Right. Okay. So Let's see. We'll have console values dot yaml. I'm gonna try not to see if this failed because I'm assuming it'll be gonna break

55:43 everything. I I think it will just, you know, give a parse error in the Oh, really? Okay. Let's see that. Blah blah blah blah blah. What happens if I do that? Alright. Okay. Cool. I was just curious. Yeah. No. We we want to make it, you know, safe for you to do things. Well, I'm very glad that it doesn't just kill the Tilt process, and I have the opportunity to just go back and fix it. So do it tail upping again. So that's good. We we have a we have a config file that is safe for feline typists.

56:27 So, you know, if your cat walks over your computer Yes. Yes. That's a developer experience I hadn't really thought of before, but yeah. My my favorite loves to type in stuff random stuff. So I guess I don't really need to override this value, the default one might be enough. Plus, I don't know where it is. So let's see. Get out let me check. Yeah. Okay. We'll make one change. Console. Values. Okay. Let's change to data center name. Okay. Rawkode. So that should pull in my values. I gave my release a name. I can take out my random error.

57:25 So my question here is, how does Tilt discover these extensions? Is there anything I need to do? Or does this know what it was from a registry or GitHub or or what? Yep. Registry on Git sorry. L u Yeah. We have a we have a tilt extensions repo. And then when you prepend the load instruction with EXT and all of that, then it just finds the extension in the extension repo. Okay. Cool. So I've saved that and tried that. I bet you I just don't have helm installed, which, of course, would be a bit of

58:09 a challenge. So I'm starting to get very much used to this Mac. I got this when I started my new role, and I've been a Linux user since I was, like, 16. So I I'm hoping this works. Are you are you able to make the change? To make the jump? It's been painful. I keep kinda wanting to go back to my Linux machine, but mostly for my window manager and all my shortcuts, which have now been disappeared. The good thing is that my terminal hasn't really changed. I'm using all my my Z Shell plugins. So it's going okay,

58:42 but I definitely I I've there's been some friction and tension. Yep. Is that the right helm? I bet you it's not. Have I still told someone around? No. It is. Okay. So we have helm. Oh, no. But I haven't told I haven't changed the fail. Tilt doesn't monitor my path for for Helm. So Yeah. You're correct. Alright. Cool. There we go. So it's adding the repository. What have I got over here? Sorry. Like I said, cricket is the ID. It's it's super fun when when Dan does that, like, in meetings and stuff. Because you you never know you never know

59:30 if you said something that makes no sense or if it's just his cat. And look to, like, within two parts in 10,000, loading your Tilt file took five seconds. That is true. Just at the bottom there, successfully loaded tilt file. Took 3.141 Oh, yeah. Four seconds. I mean, good news is that I do have a green my console now. I have a restart here, but I did just deploy a random chart without really tweaking the parameters. So I'm gonna let that one slide. Alright. So that could have been a production post code or it could have

1:00:17 been a development production could have been a post code to point their helm with development environments configured through this path here, but it wasn't. But it did do what it was supposed to do. So that's good. Awesome. Now one final thing, and then we'll we'll leave it as that. The customized thing so the the one question I still got kinda burning in my head right now. The YAML files I usually have in my repository are customized based so that I can do multiple environments. What is the workflow for that? I'm assuming there's docs. Yes. Am I still yeah. That's still the helm

1:01:04 one. I think for cost yeah. I think for customize, you go to the API and then you check the customize function there. So way at the bottom no. Not not that much bottom bottom of the menu. Tilt to API reference. There should be a customized function in there somewhere. Okay. So this is this is all of the extensions. If you control f, it's probably easier. There you go. I think you just pointed to the customized files. Right? Just and I'd have to install customize first. Okay. We don't need to go through that steps. I've gotta trust that it just works. Plus,

1:02:00 Looking at the available build-in functions

1:02:07 I don't have any customized files locally. So let's take a look at that extension list though. That was quite large. These are the built in functions. The extensions are are above that. So I see decode JSON and decode YAML. What are the applications or use cases for those kind of functions? I'm not really picturing that right away. So, like yeah. Yeah. Yeah. You might want to, like, have different options for, like, which servers am I running. Right? Like and so an example of that is maybe you want to, like, have preferences that are saved. And so the tilt file can, like, read

1:02:59 those from disk and then decode them, as JSON into, like, Python objects that you can, like, dig into. Or, some p some teams some companies that are bigger will actually have, like, each team you know, they maybe already have tooling per service. And so they have shell scripts that create JSON per service that, like, have info. And so this is really a way like, when we say mister Rogers, Tilt likes your project just the way it is, One of the ways that you, like, need to interact with it is, getting info from existing, you know, scripts that,

1:03:51 generate JSON. And so, like, it's not kind of useful at this point of trying Tilt where you're getting one thing set up. It's more how do you get it to interact with, like, bigger existing setups. Okay. I think I understand that. So there are two other things that kind of pop out here. The Docker Compose function, I'm assuming, similar to the helm, will allow me to load the Docker Compose and spend that those containers up in the background as well. I think Dan would like to go on a bit of a dive digression here and just tell you that you don't

1:04:33 have to use Kubernetes to use Tilt. You can also use Tilt with Docker Docker Compose. Or or or just with running, like, processes. Like, you might say, hey. My team, yeah, we deployed to Kubernetes, but most of the time, we're just running, you know, like, go install and then ghost, you know, like, and run that server, or we're just running NPM dev locally. You still have this issue of, like, searching between different log streams. And so the Docker Compose stuff and the local resource, like, hey. Even if you don't use Kubernetes for dev, you solve problems that Tilt solves.

1:05:15 Yeah. Thank you, l. It's it's like you've met me and know what my hobby horses are. I I didn't I didn't know you were into horses. Oh, that's actually a whole different story. But yeah. Alright. Okay. That's just it caught me off guard. I didn't realize it till didn't actually have that dependency on Kubernetes. So that's really cool as well. Alright. I'm gonna throw one more question at you and then we will we we will finish up, and I'll let you get back to your day. This includes syntax. Is there a use case for multiple Tilt

1:05:52 files, or am I misunderstanding what that would be used for? Yeah. When you get to, you know, a team that has, you know, maybe 15 different services, you know, and you want to turn them on or off or, you know, we have orgs that have hundreds of engineers that are using Tilt, you know, then you don't want to just have one file that lists everything. And so you want to break that up. And so that's you know, in in this example that you're you're seeing, it's kind of contrived. But, you know, how do you make a

1:06:34 tool that's use you know, where you can play around with it like we have been this hour, but also that can scale to hundreds of engineers. Right? And and dozens or hundreds of services. Right? Like, are different constraints and trade offs to make there. Okay. Yeah. So, I mean, that's a I guess, what I've got in my head for a use case there is, you know, each individual team is gonna be working on their independent service with their own Tilt fail. But if you ever wanted to orchestrate or see them all working together in a certain fashion,

1:07:08 then we could choose that include syntax to push them all to the cluster. Okay. Got it. Alright. Let me remove our screen share. So that's been exceptionally useful. I got a much better understanding for how Tilt works. I'm very impressed. We didn't actually have too many snags other than my own inability to do stuff and type. But it just seemed to work really well. It definitely was a good developer experience for working against a Kubernetes cluster. And now I know I don't even need the Kubernetes cluster. So I'm gonna have to start playing with this a whole

1:07:44 lot more. Are there any final thoughts from either of you before we wrap up for today? I was also surprised we didn't run into snags. Honestly, that was a pleasant surprise for me this this morning. I'm in The US for European viewers. This has been great. Thanks for having us. Yeah. I think, like, making sure that devs have a good time while they're working is basically what got me into this whole niche, basically. So, like, for me I'm really happy when when I see someone set something up and they're like, oh, this is super easy

1:08:22 to to set up and now it's super easy to use and now instead of worrying about a hundred different things, can just I can just do my focus on my code and work on my project and I don't have all those other headaches. Then, at that point, they kind of forget that they're using this tool for it. I think it's like in the movie industry they say that when you do good CG, no one notices it's there. I think Tilt has kind of that objective. When we do a really good job, the developer can just focus on their on their

1:08:56 project, on what they really wanna achieve, and we just get out of the way. I think that is the that is the main goal. A very good goal to have. Definitely. Alright. Well, I just wanna say thank you to you both for joining me and and guiding me through this today. It's been an absolute pleasure, and I really appreciate your time. So thank you very much. To people watching, I hope you've enjoyed learning about Tilt, and you can give it a try. And if you do, right into snags, I'm sure Dan and Ellen would be happy to answer questions

1:09:23 on Twitter. But I'm sure you would because it just works. Alright. Thanks so much. Thank you. I'll speak to you all soon. Have a nice day. Cheers.

Technologies featured

Meet the Cast

Weekly Cloud Native insights

Stay ahead in cloud native

Tutorials, deep dives, and curated events. No fluff.

Comments, transcript, and resources

More from Rawkode Live

View all 173 episodes

More about Tilt

View technology
Kubernetes

More about Kubernetes

View all 172 videos

More about Docker

View all 36 videos
Helm

More about Helm

View all 49 videos