Dapr has incorrect component configurations when network flag is specified on init

[mukundansundar]

Expected Behavior

dapr quickstarts work as expected

Actual Behavior

Dapr has incorrect component configurations when network flag is specified on init

It has configurations either as
localhost:6739 (all versions prior to 1.0.0-rc2) or dapr_redis:6739 (proposed fix for #418 issue after 1.0.0-rc2).

When --network argument is specified on init, no ports are exposed https://github.com/dapr/cli/blob/v0.8.0/pkg/standalone/standalone.go#L215

Since no ports are exposed, dapr sidecar for dapr applications cannot connect to the right containers be it redis, zipkin or placement.
This is a scenario where a custom network is specified, no ports are exposed locally.

Without custom docker network specified:

CONTAINER ID        IMAGE               COMMAND                  CREATED             STATUS                    PORTS                              NAMES
a93725b076f8        daprio/dapr         "./placement"            42 minutes ago      Up 42 minutes             0.0.0.0:50005->50005/tcp           dapr_placement
96dbb8b93f5e        openzipkin/zipkin   "start-zipkin"           42 minutes ago      Up 42 minutes (healthy)   9410/tcp, 0.0.0.0:9411->9411/tcp   dapr_zipkin
e3a40ccbd225        redis               "docker-entrypoint.s…"   42 minutes ago      Up 42 minutes             0.0.0.0:6379->6379/tcp             dapr_redis

Note: 0.0.0.0:50005->50005/tcp for placement and similar ones for others.
With docker network:

CONTAINER ID        IMAGE               COMMAND                  CREATED             STATUS                    PORTS               NAMES
592dcf2bc8dd        daprio/dapr         "./placement"            21 seconds ago      Up 20 seconds                                 dapr_placement_mynet
305274bd5a5e        redis               "docker-entrypoint.s…"   32 seconds ago      Up 31 seconds             6379/tcp            dapr_redis_mynet
0682ffd22c12        openzipkin/zipkin   "start-zipkin"           32 seconds ago      Up 31 seconds (healthy)   9410-9411/tcp       dapr_zipkin_mynet

Note: no port forwarding.

Steps to Reproduce the Problem

create a custom docker network
run dapr init --network mynet
check the configuration files.

This issue does not affect dev-containers since the app itself is running inside a container in the same docker network and DNS resolution is provided by docker in that scenario.

https://github.com/microsoft/vscode-dev-containers/blob/master/containers/dapr-dotnetcore-3.1/.devcontainer/docker-compose.yml

Release Note

RELEASE NOTE:

[tcnghia]

Is the --network mynet option intended for the case that daprd sidecar runs inside the network mynet?

[mukundansundar]

Is the --network mynet option intended for the case that daprd sidecar runs inside the network mynet?

@yaron2 is the network option only intended for the scenario that @tcnghia mentioned?

[tcnghia]

@mukundansundar Regardless of the answer to #545 (comment), I think you are correct that we will need to also update components/configurations to refer to dapr_zipkin_mynet, dapr_placement_mynet, etc.

[mukundansundar]

@tcnghia even if the components/configurations refer to the right hosts, still it will not work on an app outside of the same dockerNetwork ... Unless we know if an when to port forward and what name to use for the hosts (localhost if port forward is enabled), container network alias if not.

I think we might need a flag that enables port forward even if a docker network is specified.
If we go with that option, should it port forward to a random port or the same ports as it does now? Or should it be a user configured parameter for each container?

[artursouza]

I took a look at this with Mukundan. I think this issue should be de-prioritized for the following reasons:

1. We are not sure if port forwarding is the right thing to do. When a user inits dapr within a docker network, it might be intentional about not having the ports exposed. On top of that, the components configuration would work either within the network or outside, the same config cannot work for both (localhost vs dapr_redis DNS resolution, for example).
2. We don't have a user's scenario being blocked by this.

@mukundansundar and I agreed to move this outside v1.

I would also go further and recommend this to be a P2 until there are users blocked by this or we envision a real world scenario where this issue becomes a must.

[dapr-bot]

This issue has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed in the next 7 days unless it is tagged (pinned, good first issue, help wanted or triaged/resolved) or other activity occurs. Thank you for your contributions.