Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Tilt – Local Kubernetes development with no stress

github.com

Post reply on HN
Print view View original

11–20 of 76 posts

Re: Tilt – Local Kubernetes development with no stress

#11

Post by FrankPetrilli »

Hey, awesome!

I met the Windmill Eng team a few weeks ago at Kubecon in Seattle, awesome to see tilt here. It's definitely a young product, but it's a good start to exactly the experience I want.

By experience I mean that when I do local dev and edit code live while reloading or restarting the service, I see changes reflected immediately in 2-3 commands that take seconds.

In moving software towards Kubernetes, I come to rely on the service abstractions available therein. So it's sensical to develop in the same kind of environment. Tilt gives me the ability to get the save => build => package => push => reload loop into Kubernetes and without the manual hassle thereof.

I've used it in minikube, on-prem, and GKE. Running a dev box in a GCE instance and running tilt against GKE is a super nice environment.

(Fair notice: I'm a Googler who focuses on GKE, so bias and all, my opinions are not Google's, etc.)

Re: Tilt – Local Kubernetes development with no stress

#12

Post by figpope »

linkmotif wrote: post #3

My biggest problem with local k8s dev is building containers. I’m on macOS. Does this solution address that?

Is your issue with building containers and getting them into the minikube VM?

If so, you can use "eval $(minikube docker-env)" to make your shell's docker commands talk to the docker daemon in the VM.

Re: Tilt – Local Kubernetes development with no stress

#13

Post by karakanb »

I think the docs kind of misses what problem it solves and how it solves it. I do all the local stuff with docker-compose while using the same images for k8s deployments, how does this help me? Does this aim to replace docker-compose with k8s, or is this just for testing k8s resource changes in realtime, or is it testing your local k8s resource definitions against a remote cluster? Obviously this is useful for some people, I would like to understand what problems this project adresses and how it adresses them.

Also, doesn't not reusing the k8s definitions and re-defining them in a tiltfile cause yet-another-config-to-manage, which can quite easily digress from the production resource definitions, which is one of the problems using docker-compose for local development and k8s for deployment? I would really like to read the problem and proposed solutions in a detailed documentation page. I might have missed it if there is already one, please correct me if so.

Re: Tilt – Local Kubernetes development with no stress

#14

Post by linkmotif »

figpope wrote: post #12
linkmotif wrote: post #3

My biggest problem with local k8s dev is building containers. I’m on macOS. Does this solution address that?

Is your issue with building containers and getting them into the minikube VM? If so, you can use "eval $(minikube docker-env)" to make your shell's docker commands talk to the docker daemon in the VM.

Running a VM is a total drag. I only have 16GB RAM. Then even if I run a VM, the docker registry is not the same as my production docker registry (GCR). I guess I can account for this with a variable in my helm templates, but then it’s just more complexity.

Would you recommend minikube even with 16GB RAM? How much do you allot to the VM?

Re: Tilt – Local Kubernetes development with no stress

#15

Post by linkmotif »

rcarmo wrote: post #10
linkmotif wrote: post #3

My biggest problem with local k8s dev is building containers. I’m on macOS. Does this solution address that?

I have no problems building containers on macOS. Can you elaborate?

Building containers requires Linux, so I need to run a VM or build on another box/the cloud.

Re: Tilt – Local Kubernetes development with no stress

#16

Post by linkmotif »

yebyen wrote: post #7
linkmotif wrote: post #3

My biggest problem with local k8s dev is building containers. I’m on macOS. Does this solution address that?

Is the problem with building containers that you don't have a Dockerfile and you don't want to spend time making one? Draft does that pretty well with Draftpacks, in my experience if there is a Draftpack for what you're using then the Dockerfile that draft spits out will get you pretty close to a workable container image with basically no effort, or sometimes even all the way there. I'm trying to understand what you…

I’m all aboard Docker, but I don’t use Linux natively, so I’d need to run a VM inside macOS, or have another box to build containers. Even if I did, I use GCR in production, so I’d need to template my container images in helm to use GCR only in production versus whatever I use locally for development. And what would that even be? I haven’t explored minikube to know what it does for local dev container registry.

Anyway, thanks for the link. Missed that.

EDIT: Looks like tilt is using GCR in those examples. I’m not trying to traffic container images off of google cloud for local development. That requires (fast) internet just for local development, and outgoing traffic really adds up quickly in terms of cost.

PSS: never heard of Draft. Checking it out now. Not using azure though, maybe that’s not relevant.

Re: Tilt – Local Kubernetes development with no stress

#20

Post by yebyen »

linkmotif wrote: post #16
yebyen wrote: post #7

Earlier quoted context omitted.

Is the problem with building containers that you don't have a Dockerfile and you don't want to spend time making one? Draft does that pretty well with Draftpacks, in my experience if there is a Draftpack for what you're using then the Dockerfile that draft spits out will get you pretty close to a workable container image with basically no effort, or sometimes even all the way there. I'm trying to understand what you…

I’m all aboard Docker, but I don’t use Linux natively, so I’d need to run a VM inside macOS, or have another box to build containers. Even if I did, I use GCR in production, so I’d need to template my container images in helm to use GCR only in production versus whatever I use locally for development. And what would that even be? I haven’t explored minikube to know what it does for local dev container registry. Anywa…

Azure team open source products can almost all be used without Azure cloud.[1] I do use Azure but not for everything, you can definitely use Draft without Azure, it's Kube-native software so you can use it anywhere you have Kubernetes. (Like Tilt, from what I understand about it so far... Tilt and Draft look to be very similar tools, with different approaches.)

I helped someone on Twitter with this question last week. I have a (* single-node) Kube somewhere and I want to build images in it, and not have to pull them from a repository. The parlance in Kubernetes for this is, an imagePullPolicy of Never. (you actually do need a repository if you don't have a single-node Kubernetes, full-stop.)

Docker does actually run a VM with Linux in it, doesn't it? The modern version of Docker for MacOS also offers a Kubernetes checkbox, so if you're already using Docker, you needn't have another VM just for running Kubernetes.

This is certainly a problem that could use more clarity and for users, maybe a nice howto blog post for clarification, but it's absolutely possible to do this without a registry. I think Tilt mentioning "gcr.io" in the image tag is not necessarily a signal that you should actually push your image to the gcr.io registry. It's therefore possible to build and execute your containers while never pushing or pulling. If that's what you wanted to do, then that's exactly what you may do by setting your imagePullPolicy to Never.

(I have no idea how this works with Tilt, but I'd assume it's possible to use a similar approach since it's also on Kubernetes.)

The tweet in question: https://twitter.com/yebyen/status/1080534315157635072

[1]: the exception is things like aks-engine. You can only use aks-engine with Azure as I understand it, because Azure implements their own API for creating virtual machines, and nobody else implements that particular API. But I can't say how unique the Azure API actually is, or if it's also open source, could you build your own Azure in a rack, from all open-source components? That would be pretty cool, if you could...

Post reply on HN