Robomongo: No support for Docker Compose network aliases

[lborg019]

I am running a MongoDB Cluster with Docker Compose.
I was really excited for the replicaSet connection feature, but unfortunately it fails with Docker Networks.

I get:

Cannot connect to replica set "mongodb-cluster"[0.0.0.0:9094]. 
Set's primary is unreachable.

Reason:
No member of the set is reachable.

Upon further investigation, I mongo'd into one of my virtual shards, ran a slaveReplication diag:

rs.printSlaveReplicationInfo()

and got:

source: rs1_srv2:27021
        syncedTo: Thu Mar 02 2017 17:14:08 GMT-0500 (EST)
        0 secs (0 hrs) behind the primary 
source: rs1_srv3:27022
        syncedTo: Thu Mar 02 2017 17:14:08 GMT-0500 (EST)
        0 secs (0 hrs) behind the primary 

I am almost certain that it will not work because rs1_srv2 is an alias that Docker Compose will replace for the IP (0.0.0.0 in this case).

If that is really the issue, a plugin that accepts the compose.yml file, and translates the aliases for Robomongo should enable the feature to work with MongoDB + Docker.

[simsekgokhan]

Hi @lborg019 , thanks for reporting the problem. We have started the investigation.

[lborg019]

Here's a sample of my $ docker ps when my cluster is running (I omitted a few columns):

$ docker ps
CONTAINER ID        IMAGE               PORTS                     NAMES
83eb9dd99d56        mongo:3.0.6         0.0.0.0:9090->27017/tcp   dockermongodbcluster_router_1
1749227e562b        mongo:3.0.6         0.0.0.0:9091->27017/tcp   dockermongodbcluster_cfg1_1
dc1742fab165        mongo:3.0.6         0.0.0.0:9092->27017/tcp   dockermongodbcluster_cfg2_1
8323a46c358b        mongo:3.0.6         0.0.0.0:9098->27017/tcp   dockermongodbcluster_rs2_srv2_1
bf7aad28d85c        mongo:3.0.6         0.0.0.0:9097->27017/tcp   dockermongodbcluster_rs2_srv1_1
54fc3fba9af9        mongo:3.0.6         0.0.0.0:9096->27017/tcp   dockermongodbcluster_rs1_srv3_1
392a64821e93        mongo:3.0.6         0.0.0.0:9095->27017/tcp   dockermongodbcluster_rs1_srv2_1
4ec1dce94576        mongo:3.0.6         0.0.0.0:9099->27017/tcp   dockermongodbcluster_rs2_srv3_1
8e894ade4ba7        mongo:3.0.6         0.0.0.0:9093->27017/tcp   dockermongodbcluster_cfg3_1
9148eec35484        mongo:3.0.6         0.0.0.0:9094->27017/tcp   dockermongodbcluster_rs1_srv1_1

running the following docker commands:

$ docker inspect --format='{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' dockermongodbcluster_rs1_srv1_1
172.18.0.2

$ docker inspect --format='{{range $p, $conf := .NetworkSettings.Ports}} {{$p}} -> {{(index $conf 0).HostPort}} {{end}}' dockermongodbcluster_rs1_srv1_1 
 27017/tcp -> 9094 

yields the Docker network IP and port in which the container rs1_srv1 is running (172.18.0.2) and the port 27017, mapped to local network's port 9094
(we can also use Container ID instead of Names as arguments for these commands)

This way we can find the container's IP and port on the Docker network and its respective mapping on the local network's IP and port. If Robomongo could run these commands, find correct IPs and ports, and replace them for the aliases aforementioned, it might be able to work with Docker networks.

It would be nice if Robomongo offered a Docker network cluster option which enabled such features.

Going to check out the Repo, maybe try a pull request 👍

[pauln]

We've encountered the same issue, and tried to investigate what's actually happening. It appears that RoboMongo is:

1. Connecting to the first host defined in the RoboMongo connection
2. Calling db.serverStatus()
3. Pulling the list of hosts (repl.hosts) out of the resulting data
4. Attempting to connect to the hosts using the addresses obtained from repl.hosts

That doesn't work if you've configured Mongo to use Docker network IPs. Given that we're listing all the members within the RoboMongo connection, it would make sense for RoboMongo to stick to the list we're giving it rather than overriding it with the list of members retrieved from the first one listed in the RoboMongo connection.

I hope that makes some kind of sense - if not, feel free to ask for clarification!

[pauln]

Following on from my earlier comment, perhaps the way to address this from a UI perspective is to have an option to switch between an explicit server list (i.e. the list we can currently add/edit when connecting to a replica set; this would not then try to connect to hosts from repl.hosts) or an implicit (remote) server list (which only asks for a single host to connect to, then extracts repl.hosts from db.serverStatus()). That way, if you're using a Mongo admin user, you can use implicit mode and give it a single host - but if you're not using an admin user, or your Mongo setup uses IP addresses / host names which aren't accessible to RoboMongo, you can define an explicit list of hosts.