> Modern apps are made of too many services. They're everywhere and in constant communication.
So we made tooling to make it easier for you to make more of them!
Do we really struggle bringing up services as containers and applying kube configs?
For my development of services that run in kube, I don't dev with kube, you shouldn't have to. I also use docker-compose for most dev env services.
Perhaps i'm not developing the right kind of software. Whoever finds this type of tool useful, when would you use it?
otherwise I think it's meant for systems where system that you need for testing is to big to work on your local machine.
By default, Tilt is actually intended for local development using kind, minikube or other similar tooling. It supports developing against a multi-node cluster but it requires extra configuration and slows down iteration time.
- Service discovery
- Volume mounts
- Ingress and Certificates
- Metrics scraping and configuration
- Dashboards
It’s really quite powerful and replaces the need to mock things out with docker compose. If you’re deploying to Kubernetes, Tilt gives you the option to avoid “development-only” setups like docker compose.
I think if you told our team to go back to Docker Compose they'd revolt on the spot haha
Tilt is a monitor process that builds and starts your services, with a hot-reload loop that rebuilds and restarts your services when the underlying code changes. The hot reload loop even works for statically compiled languages.
# vim: ts=2 sw=2 et
Obvs the real magic is the live syncing patches into remote containers though
I like a fast svelte dev environment with something like docker-compose which might require some mocked out dependencies to keep things fast and then using Kubernetes for other environments once I have local tests passing.
In my case, I find that I prefer having higher fidelity and simpler service code by using Tilt to avoid mocks. It's also nice for frontend development because, using a Kubernetes ingress, you can avoid the need for things like frontend proxies, CORS and other development-only setup.
Want to create a Kubernetes secret? It's as simple as:
load('ext://secret', 'secret_yaml_generic')
k8s_yaml(secret_yaml_generic(...))
load('ext://vault_client', 'vault_read_secret', 'vault_set_env_vars')
vault_set_env_vars('https://localhost:8200','mytoken')
my_foo = vault_read_secret('path/myfoo', 'value')
my_bar = vault_read_secret('path/mybar', 'foobar')Clace uses Starlark for defining apps, instead of something like YAML. https://github.com/claceio/clace/blob/main/examples/utils.st... is a config file which defines around seven apps (apps are downloaded and deployed directly from git).
Clace uses Starlark for defining app level routing rules also. This avoids the need to use a nginx like DSL for routing.
I see that you also have docker-compose files -- are those for different tasks or for developer preference?
I'm also curious to understand why you have different build scripts for CI (`buildx`) vs local (regular docker build)? In our team, we use the same build processes for both.
Single cluster deployments are very easy.
My problem is that these services we manage in production are deployed across multiple regions (or k8s clusters).
Debugging _distributed_ applications is the issue.
There is also .PHONY, but that would make the rule to always be triggered. Maybe I'm misremembering, it's been a long time :)
Can you do it? Sure, but somewhere someone is going to be suffering.
There seem to be a lot of tools in this space. I wish they wouldn't call themselves tools for "dev environments" when they are really more like tools for "deploying an app to your local machine", which is rather different.
cirego•6h ago
I love how Tilt enables creating a local development environment that lets my services run the same in production , test and development. Greatly simplifies my service code and improved my quality.
In particular, I’d love to see Tilt be better around handling things like CRDs (there’s no way to mark a k8s_yaml as depending on a CRD being available, a frequent source of broken tilt up invocations).
Having said that, the first thing I do, when working on any new project, is to get “tilt up” working.
Things I’ve used for testing include: eBPF-based collectors for security and observability, data pipelines, helm chart development, and Kubernetes controllers. It’s very flexible and powerful for a wide range of development.
AYBABTME•3m ago
Happy to see new releases of Tilt even if the pace has slowed down. It's a very useful tool.