cli
cli copied to clipboard
Minimalist `dapr init`, ideally as the default
Improvement
When dapr init is called, by default it creates Redis and Zipkin containers.
In theory this could be helpful, though I think it ends up being misleading to newcomers and mildly fault prone:
- If someone is already working with a local development setup that uses Redis, port
6379is almost guaranteed to already be in use - Zipkin prescribes a specific telemetry solution, I'd also argue most users never end up working with this container
- It sets a confusing precedent as part of a "minimalist Dapr experience". None of the Dapr components (scheduler, placement) require these containers. (😅 I actually snagged on this when I was first learning Dapr!)
You can see an example of the impact of this default in some documentation I'm working on:
3. Run `docker rm dapr_redis dapr_zipkin --force` -- this cleans up some default containers we'll be replacing
Fix
I think it's harmless to remove starting these two containers as part of the default init flow. If it's something we really want to offer, then make it opt-in.
See also
- https://github.com/dapr/cli/issues/175
- https://github.com/dapr/cli/pull/1523
Release Note
RELEASE NOTE: FIX Make supporting containers optional during init.