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

61–70 of 76 posts

Re: Tilt – Local Kubernetes development with no stress

#61

Post by johnmarcus »

metzby wrote: post #31
karakanb wrote: post #13

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 p…

Hey, I'm CEO of Tilt. Thanks for the feedback. The problem this solves is that distsys devs don't get enough feedback. You say you use docker-compose. Compared to docker-compose, Tilt has two advantages: 1) It updates the services as you edit them 2) Its UI makes it easy to see where errors are occurring, without you having to play 20 questions on the command-line or worry about things scrolling off-screen. The Tiltf…

It looks like your basically recompiling/rebuilding the container and just updating what’s running (in what I assume is a k8s cluster on OS X). This all seems like a terrible idea. No way devs want to wait for a container rebuild to see updated code changes, that’s highly unproductive. They usually don’t run k8s locally either, because it’s an abstraction later they hardly want/need to concern themselves with while writing code. And as a say admin, truthfully I don’t really want them to try because it would double my own already heavy workload. This seems to solve a problem in a way that only works in the most ideal enterprise (slow moving) work environment. I currently solve the problem with carefully built containers which permit volume mounting and and code reload natively using typical dev flags for the run command. It requires more thought upfront than is ideal, but does typically solve the problem. Cheers.

Re: Tilt – Local Kubernetes development with no stress

#62

Post by karakanb »

metzby wrote: post #31
karakanb wrote: post #13

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 p…

Hey, I'm CEO of Tilt. Thanks for the feedback. The problem this solves is that distsys devs don't get enough feedback. You say you use docker-compose. Compared to docker-compose, Tilt has two advantages: 1) It updates the services as you edit them 2) Its UI makes it easy to see where errors are occurring, without you having to play 20 questions on the command-line or worry about things scrolling off-screen. The Tiltf…

AFAIK, the whole idea behind the cloud-native approaches and tools in the ecosystem, such as Docker, Kubernetes, Helm, Terraform, focus on reproducible builds that are platform-independent, at least that is my understanding of the ideal. I imagine having an application code, my Terraform definitions, k8s resources and helm charts, and basically I should be ready to deploy my application to any of the big cloud providers. This doesn't have to be the case for each and every application, but I believe we should all be moving towards a decoupled infrastructure where the application code itself is independent from where it is running in terms of infra.

So, considering the point above, using Tilt for updating production cluster state and resources with hot reloading seems like a no-no, as this may easily cause configuration drift, which would make the whole cluster state independent from the k8s resource definitions. We should be moving towards reproducible builds and infra, so this usecase seems to fall short in my opinion.

Replacing docker-compose seems like an exciting point, though the value addition is still not clear for me to abandon a tool I have been using for months for developing the application code, not the infrastructure stuff. I can see all the logs from all the containers on a single terminal, every developer in my team can run the whole application with a single shared docker-compose definition, and everyone in my team is familiar with it already. As far as simplicity goes, I don't see how Tilt simplifies my workflow since it requires a configuration script instead of docker-compose.yml file, and it is yet another tool to learn in that regard. Ideally, I would like to remove all the dependency from docker-compose as keeping it in sync with the k8s resource definitions requires effort, though Tilt also requires a similar configuration AFAICT from the docs. The best workflow for local k8s-based development seems like using minikube with the mounted directories or something similar, which means every change in the k8s resources made locally would also be present on the production setup, hence keeping production setup completely reproducible on every cluster, including local stuff like minikube.

Please don't take my words in a bad way, I am really looking forward to replace my docker-compose based setup with something based solely on k8s definitions, therefore I am playing devil's advocate for Tilt in order to clarify its benefits so that I can make an informed decision about employing it or not. Thanks for jumping in on HN to answer questions and accept feedback, I really appreciate that.

Re: Tilt – Local Kubernetes development with no stress

#63

Post by johnmarcus »

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…

Try working with Elixer and Phoenix and you will start to appreciate how builds can be a nightmare.

Re: Tilt – Local Kubernetes development with no stress

#64

Post by chupasaurus »

linkmotif wrote: post #24
NickBusey wrote: post #21

Earlier quoted context omitted.

I built a container a few minutes ago on macOS, not sure why you believe this to be the case.

Docker containers/lxc require Linux. They are a Linux technology.

As weird as it sounds, Microsoft had implemented the full namespaces stack in Server 2016 (unavailable in Win10 as the base for native containers is Server where kernel differs a bit), which Docker supports (and k8s in alpha/early beta).

Docker switched from LXC to containerd in 2016.

Re: Tilt – Local Kubernetes development with no stress

#65

Post by gingerlime »

q3k wrote: post #30
flurdy wrote: post #2

Uuuuh not using YAML. Controversial. (in the docker/k8s ecosphere, where YAML seems ubiquitous) I don't love YAML though I am not sure Starlark looks any more readable. YACL => Yet another config language...?

YAML, especially how it's used in k8s, is terrible. Writing it by hand is mind-numbingly toilful and extremely error prone, and templating YAML with Go (like Helm does) is a travesty. The most sensible approach I've seen is to use jsonnet+kubecfg. This lets me use a somewhat sane, composable, turing complete language that spits out a tree of k8s objects. I can use as much or little repeated definitions (or abstractio…

I'd love to see a writeup about your process or workflow.

I keep seeing helm, and the overall idea of a "package manager" sounds nice, but having looked at some charts, and tried to understand the value proposition, I get a very uneasy feeling somehow. Perhaps it's lack of familiarity? but your comment seems to suggest something is inherently wrong, so I'd love to understand more...

Re: Tilt – Local Kubernetes development with no stress

#66

Post by [deleted] »

metzby wrote: post #35
kkapelon wrote: post #18

How does this compare with garden.io, skaffold, draft, microk8S etc???

Hey, Tilt CEO here, so I'm certainly biased, but also semi-informed. We think you deserve three properties: 1) it's easy to start your whole app 2) it's fast to update your app as you edit 3) common problems can't be missed. docker-compose gives you 1. (some people hack in mount points and file watching to get 2, but it's hacky) skaffold and garden.io give you 1 and some of 2. (Tilt has fast_build, which can update p…

[deleted]

Re: Tilt – Local Kubernetes development with no stress

#68

Post by eysi »

metzby wrote: post #35
kkapelon wrote: post #18

How does this compare with garden.io, skaffold, draft, microk8S etc???

Hey, Tilt CEO here, so I'm certainly biased, but also semi-informed. We think you deserve three properties: 1) it's easy to start your whole app 2) it's fast to update your app as you edit 3) common problems can't be missed. docker-compose gives you 1. (some people hack in mount points and file watching to get 2, but it's hacky) skaffold and garden.io give you 1 and some of 2. (Tilt has fast_build, which can update p…

Hi all, Garden CTO here. First of all, great job on Tilt! A lot of interesting stuff happening in terms of DevEx in the multi-service realm.

I just wanted to chime in on the points above. Regarding 2), Garden does indeed support updating pods without re-building and re-deploying via our hot-reload feature (https://docs.garden.io/using-garden/hot-reload) which essentially copies source files into the running container on file save (works best for dynamic languages).

Regarding 3), Garden has a terminal UI that shows the status of individual services and updates as changes are made to the codebase. It will for example print error messages for failed container builds and failed deployments. If configured so, Garden can also run tests on code changes and will print the error output if tests fail. Our next release will also contain the first version of a dashboard which displays service statuses and dependency graphs and updates in real time. However, our terminal UI is not interactive like Tilt’s—which looks really nice!

Re: Tilt – Local Kubernetes development with no stress

#69

Post by yebyen »

johnmarcus wrote: post #63
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…

Try working with Elixer and Phoenix and you will start to appreciate how builds can be a nightmare.

Not trying to be obstinate, but I'm a Rails dev and probably won't do that

There is a Draftpack for elixir: https://github.com/technosophos/draft-elixir/tree/master/pac...

And here's an Alpine-based dockerfile: https://github.com/bitwalker/alpine-elixir-phoenix

What kind of problems would I expect to run into?

Re: Tilt – Local Kubernetes development with no stress

#70

Post by metzby »

karakanb wrote: post #62
metzby wrote: post #31

Earlier quoted context omitted.

Hey, I'm CEO of Tilt. Thanks for the feedback. The problem this solves is that distsys devs don't get enough feedback. You say you use docker-compose. Compared to docker-compose, Tilt has two advantages: 1) It updates the services as you edit them 2) Its UI makes it easy to see where errors are occurring, without you having to play 20 questions on the command-line or worry about things scrolling off-screen. The Tiltf…

AFAIK, the whole idea behind the cloud-native approaches and tools in the ecosystem, such as Docker, Kubernetes, Helm, Terraform, focus on reproducible builds that are platform-independent, at least that is my understanding of the ideal. I imagine having an application code, my Terraform definitions, k8s resources and helm charts, and basically I should be ready to deploy my application to any of the big cloud provid…

Yes, please don't use Tilt to update your production cluster!

Tilt is just for precommit development.

If you email me (dan @ windmill dot engineering), we can talk more, but we are more reproducible and less config than mounting directories into minikube.

Post reply on HN