Minimalist `dapr init`, ideally as the default

[atrauzzi]

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

• Initialize Dapr without docker #175
• Feat/granular service disable flags #1523

Release Note

RELEASE NOTE: FIX Make supporting containers optional during init.

[alicejgibbons]

Think we could go ahead and add a --no-redis --no-zipkin option here that also would remove the redis/zipkin container on startup as well as the default component files (.dapr/components)