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
6379 is 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
Release Note
RELEASE NOTE: FIX Make supporting containers optional during init.