
Tilt – Local Kubernetes development with no stress - ducaale
https://github.com/windmilleng/tilt
======
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.

~~~
metzby
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 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](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.

~~~
jacques_chester
> _There is a landing page at[https://tilt.build](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.

~~~
puzzle
Dan himself used to work at Google NYC...

------
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.)

~~~
metzby
Thanks Frank! It was great to chat at Kubecon. (I'm Dan, the Windmill CEO,
goofy big-haired guy)

------
flurdy
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...?

~~~
q3k
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
abstractions) as I like. Then kubecfg performs all the kubectl invocations to
actually make the cluster state match my calculated definitions.

~~~
sergiusignacius
I don't see how Starlark is better... Does it validate what you write somehow
- in a way that couldn't be done by validating a YAML?

~~~
q3k
I don't understand, I'm not talking about Starlark..?

~~~
sergiusignacius
Meant to reply to the comment, sorry :)

------
leandot
It actually uses your existing Dockerfile and existing k8s yaml definitions
contrary to what some people are saying in the comments,the Tiltfile seems to
be just a handful of glue logic. The logs ui is pretty nice too, I've
definitely looked for an easier way to check logs from multiple running pods.

------
tirumaraiselvan
Seems like this is the main product of a full-time startup. In that case, I am
curious how are you thinking about the future and business model considering
it is 1) open source and 2) many competitors.

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

~~~
metzby
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 pods in-place, without rebuilding the whole image, which I don't
believe either skaffold or garden.io do)

Our big value-add is the UI. Which may sound weird for a Terminal UI, but if
you look at the demo video on [https://tilt.build](https://tilt.build) , I
think you'll get a sense for how Tilt is working to keep _the_ problem that's
blocking you in your face, so you don't waste time playing 20 questions with
kubectl.

~~~
eysi
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](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!

------
rcarmo
I love the name, especially considering that the GitHub username is
'windmilleng'.

(if you don't get it, look up Dom Quixote)

------
phentz
How does it compare with Telepresence + skaffold ?

I like the console UI idea.

I dislike the server components (the same way I dislike draft and tiller).

------
jaytaylor
In the readme there's a link to kubernetes slack. Anyone know how can I get an
invite to join the workspace?

~~~
metzby
[http://slack.k8s.io/](http://slack.k8s.io/)

------
maxdo
is there anything working with helm in the similar way ?

~~~
kkapelon
there is also garden.io

~~~
dexcs
Tell me you don't work for them...

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

~~~
yebyen
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 mean that building containers is a problem.
Is it the procedural act of actually building and rebuilding the container
that is the problem? (Draft handles that too...)

Edit: According to the Tilt tutorial, yes, tilt will build your containers.
Eg:
[https://docs.tilt.build/first_config.html](https://docs.tilt.build/first_config.html)

~~~
linkmotif
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.

~~~
theptip
Sounds like you should try skaffold, it has a workflow for local builds, with
fast hotloading to auto-rebuild your image. It also redeploys automatically
too. If you're using Minikube it'll share the docker daemon so that you don't
have to push anything anywhere.

I find Docker for Mac to be completely fine, and Minikube can be a resource
hog, but still workable if you make your resource allocations configurable
(i.e. don't request 1G for each pod in your local env, even if you need to do
so in prod). There is an xhyve driver for Minikube that should reduce the
footprint by not requiring you to run virtualbox.

