Tild.dev is a tool, developed by Windmill Engineering with the goal of helping local continuous development and deployment of microservice applications. Similar to other tools such as Draft, Skaffold, and Garden, Tilt targets to “inner-loop” of development workflow by helping developers to deploy their applications to local kubernetes such as minikube, docker-for-desktop or microk8s.
We have already covered Draft, Skaffold and Garden in our previous blog post, so as soon as we learned about Tilt we wanted to see how it compares against them for local Kubernetes development. By the way, if you are still looking for a local cluster solution we have dedicated blog posts for Desktop Docker, Microk8s and Minikube for Windows, Mac, and Linux.
As you would expect, Tilt supports automatic deployments of your microservice-based application during development because it monitors application files and then automatically builds, pushes, and deploys any changes to bring your environment up-to-date in real-time. Furthermore, Tilt also provides a command line and a WEB UI, to monitor the deployment of the application and shows logs and other helpful information about current deployments. One of the main goals of Tilt is to help you move away from opening multiple terminals in order to understand what your microservices are doing.
Tilt supports more than just Dockerfiles. It can reuse your Kubernetes manifests in your Tiltfile (and options to support Helm packaging and Kustomize are available), and it makes easier and faster the development and deployment of multiple microservices with complex dependencies between the various Docker images. Through the provided UI, the developer can easily monitor the progress of each service, since it provides both build and container logs.
The available features of Tilt are:
- Monitors local changes in your source code and automatically triggers build/push deployments to Kubernetes clusters.
- Can track build dependencies between applications using Bazel .
- Supports applications consisting of multiple components/microservices.
- Provides a console UI to monitor the deploy process and see the logs of the build and deployment process of your application (a Web UI is also under development).
- Also supports Helm charts for deployment to Kubernetes clusters. A tutorial on how to use this can be found here.
- Improved build and deployment time by providing build caches and allowing to execute build commands directly to your cluster.
- Tilt supports also Docker-compose to orchestrate deployed services when a Kubernetes cluster is not needed.
The two main advantages of Tilt is:
- The console UI that is provided and can be used to monitor the build and deploy process of your application, very easily and effectively without the need for additional steps. It includes information about the name of each pod deployed in the cluster using Tilt, the deployment status, deployment history, and pod logs (both build logs and running container logs). This is very helpful for developing a number of interrelated microservices for your application.
- The build and deploy time is reduced significantly due to its internal mechanism for fast build and deployment and can be easily used to perform incremental builds, Unfortunately, this comes with some limitations in the configuration, especially in the Dockerfile, and developers need to make changes in their existing Dockerfiles of their applications.
Tilt.dev development tutorial
In this tutorial, Tilt.dev installation will be completed using the standalone executable, for Linux. The installation steps are:
- Download the latest version of Tilt.dev
- Upack it and place it to your $PATH
- Verify the executable and version.
Example Installation:
curl -L https://github.com/windmilleng/tilt/releases/download/v0.9.7/tilt.0.9.7.linux.x86_64.tar.gz | tar -xzv tilt sudo mv tilt /usr/local/bin/tilt tilt version
Application Configuration
For this tutorial, a spring-boot application will be used, which can be found at https://github.com/pliakas/roukou-dev-on-kubernetes. It provides one endpoint that returns a simple greeting message in JSON format.
As a first step, a Dockerfile is needed to containerize the application. A simple Dockerfile can be:
FROM maven:3-jdk-11 as BUILD COPY . /usr/src/app RUN mvn --batch-mode -f /usr/src/app/pom.xml clean package FROM openjdk:11-jre-slim ENV PORT 42050 EXPOSE 42050 COPY --from=BUILD /usr/src/app/target /opt/target WORKDIR /opt/target CMD ["/bin/bash", "-c", "find -type f -name '*.jar' | xargs java -jar"]
Furthermore, a Kubernetes manifest file named k8s-app.yml needs to be created. For this application, a proposal of this file can be:
apiVersion: apps/v1
kind: Deployment
metadata:
name: tilt-demo
labels:
app: tilt-demo
spec:
selector:
matchLabels:
app: tilt-demo
template:
metadata:
labels:
app: tilt-demo
spec:
containers:
- name: tilt-demo
image: roukou/tilt-demo:latest
ports:
- containerPort: 42050
Alternatively, instead of using a Kubernetes manifest file, you can also use Helm charts. A tutorial on how to use Helm chart can be found here.
Finally, a Tiltfile file is needed similar to this:
docker_build('roukou/tilt-demo', '.')
k8s_yaml('k8s-app.yaml')
k8s_resource('tilt-demo', port_forwards=42050)
Application Deployment
Now we are ready to build and deploy the applications. Using the command:
tilt up
Inside the project directory, it will start the deployment process. A console UI and a web UI will start automatically to provide you information about the build and deployment process and a small indicator (green/red) if the process is successful or not.
As mentioned above, a web-ui for details view of the log is provided for each build/deploy step and you can easily found possibly bugs and monitor also the log history. There are no additional steps needed to get logs from your application. Tilt deployed the application in the namespace as specified in the Kubernetes manifest. To verify your application was properly deployed by switching to that namespace and running kubectl get pods.
$ kubectl get pods NAME READY STATUS RESTARTS AGE tilt-demo-6cc66cd585-xcn7j 1/1 Running 0 5m50s
While tilt up is running, the build, push, and deploy application will occur every time a change is made to your code. When a change is happening to the application in real-time as Tilt runs through the pipeline to redeploy your updated application.
Finally, to remove the application you have to exit from the console UI and execute the command:
tilt down
Conclusion
If you have already used Draft or Skaffold then you would find yourself write at home with Tilt.
The most interesting feature of Tilt is of course the live dashboard that allows you to look at all your microservices at once. Tilt also has selected a Python like DSL for its format, meaning that you have access to a full programming language in your configuration files (i.e. with loops and functions).
Tilt also allows you to skip completely the local workstation and use a cluster for even faster builds (also bypassing the Docker registry and sending code directly to a POD). In that sense you might also be interested to look at Garden.io as we described in our previous article.
The main difference between Garden and Tilt is that while Tilt will watch for changes on a bunch of different services, Garden takes a project-level approach to it. It builds a dependency graph of the whole stack and it knows how your services relate to one another (not just on build time but also on deploy/test phase).
Tilt is also Kubernetes specific. It works well for containers and Helm if your application is based on them. Garden on the other hand, has a pluggable architecture which makes it very easy to add extras as they are needed. For example, there is a container plug-in when you need a Dockerfile but you don’t need a Kubernetes manifest. It creates reasonable defaults and you just don’t have to worry about Kubernetes. Then there is the Kubernetes plug-in, analogous to what Tilt does, a Terraform plug-in, an exec plug-in which you can use for arbitrary tasks, an OpenFaaS plug-in, and so on. Because of the dependency graph, all of these things happen at the right time, in the right order.
Another important feature of Garden is in-cluster building. Garden also supports live update like Tilt, but with in-cluster building you don’t even need Docker on your local workstation. You can get live updates of your app if it makes sense, like when you are using Python or Node, but if you’re using a compiled language like Go and Java and you don’t want the heavy lifting to happen on your local workstation, you can off-load docker builds to a remote cluster. This way if you are working on things that require a lot of power, or you want to keep using your old laptop, you don’t have to worry about building locally.
Which local Kubernetes solution do you use? Let us know in the comments below.