Expected Behavior

dapr init should start the Redis host in a specific Docker network even when given a non-default host name.

Actual Behavior

dapr init skips starting the Redis host if a non-default host name is specified (i.e. not localhost).

Steps to Reproduce the Problem

1. Set environment variable DAPR_NETWORK to dapr-dev-container
2. Set environment variable DAPR_REDIS_HOST to dapr_redis
3. Set environment variable DAPR_PLACEMENT_HOST to dapr_placement
4. Run dapr init

Dapr will install (i.e. create the containers for) the placement host and the zipkin host, but skips the Redis host (warning that, due to the name being explicitly specified, it is expected to already be running).

The problem is that, when installed to a specific Docker network, the default Redis host name (i.e. localhost) cannot be used as there is no mapping of ports back to a single machine running the Dapr application(s); the container running the Dapr applications is a just another peer of the Dapr runtime containers and, so, must use its real network name to connect to the Redis host.

It looks like this change was added as part of #373 and breaks the "Dapr in VS Code Developer Container" templates (which spin up Dapr within a custom Docker network).

Is there a scenario where specifying a Redis host name itself implies that host is already running? Would it make sense to have a switch to tell dapr init definitively to either start (or not start, whichever is most likely) the Redis host? Also, it would be helpful if the DAPR_REDIS_HOST, if set, also found its way into the network alias rather than always using dapr_redis.