Skip to content

Minimalist dapr init, ideally as the default #1572

@atrauzzi

Description

@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

Release Note

RELEASE NOTE: FIX Make supporting containers optional during init.

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions