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 Tiltfile doesn't redefine your k8s definitions; it reuses your existing k8s definitions. The Tiltfile just tells Tilt how to get them. (Many teams don't just use yaml files, but generate them, so Tilt has to be able to do that, too.)
There is a landing page at https://tilt.build which has more of the "why Tilt". Also, we're adding native support for docker-compose next week. I'd love to understand your case more, because at a high level you sound like exactly the kind of dev we want to help.
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.
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.
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.
> There is a landing page at https://tilt.build which has more of the "why Tilt".
As a tangential by-the-way, I notice you're based in NYC. Of interest, Googlers working on Knative Build (hi Jason!) and Pivots working on Cloud Native Buildpacks (including me) are based in NYC also.
Hi! Thanks for checking in on HN. I'm very interested in k8s productivity but had some trouble understanding what Tilt is actually doing--is it a replacement for minikube, hosted kubernetes, etc.?
Is there an architecture diagram that shows what runs where?
There isn't an architecture diagram, and there should be. Thanks.
Tilt replaces `docker build && kubectl apply` or `docker-compose`. It watches your files, updates automatically, and gives you a UI that shows you error so you don't have to spelunk with kubectl.
It uses minikube or docker-for-desktop or a cloud k8s cluster (AKS, EKS, GKE, whatever).
"Tilt replaces `docker build && kubectl apply` or `docker-compose`. It watches your files, updates automatically, and gives you a UI that shows you error so you don't have to spelunk with kubectl." => that is very clear, consider merging https://github.com/windmilleng/tilt/pull/930 to add it to your readme
Does it allow you to replace the `docker build` step? Currently we use Nix's buildLayeredImage[0] to build our images and some custom machinery to generate our Kubernetes definitions from this, but I really like Tilt's status TUI.
It's a lot like skaffold. Main improvements (for now):
) a better UI that keeps errors on-screen. Check out our demo video: https://www.youtube.com/watch?v=MGeUUmdtdKA) fast_build allows you to do iterative container builds
If you use skaffold for local dev, a Tiltfile will take 10 minutes to write. Email me at dan at windmill dot engineering and we can pair to get you going. You're the user who would benefit from Tilt immediately.
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 Tiltfile doesn't redefine your k8s definitions; it reuses your existing k8s definitions. The Tiltfile just tells Tilt how to get them. (Many teams don't just use yaml files, but generate them, so Tilt has to be able to do that, too.)
There is a landing page at https://tilt.build which has more of the "why Tilt". Also, we're adding native support for docker-compose next week. I'd love to understand your case more, because at a high level you sound like exactly the kind of dev we want to help.