MongoDB Timeout when multiple MongoDB containers are instanciated ( in != virtual environnements )

General
1

Hi there,

Well, i’'m facing a mystery that make me crazy since more than 1 year…

I have a docker-compose with a MongoDb container, i’m instanciating in différent environnements.

As exemples i may have :

  • Multiple WSL instance, each with an instance on this same docker-compose.yml
  • or 1 WSL instance and an Oracle VMbox, still with this same docker-compose.yml

And most of the time, only the 1st MongoDB container instance work while the others instances in the other virtual environnements doesn’t respond on the exposed port in the docker-compose network.

Here the mongo definition ( this is obviously not a configuration problem as it’s working when there only 1 virtual environnement using it )

  mongodb:
    image: mongo:latest
    restart: unless-stopped
    environment:
      - MONGO_DATA_DIR=/data/mongodb
      - MONGO_INITDB_ROOT_USERNAME=admin
      - MONGO_INITDB_ROOT_PASSWORD=admin
    volumes:
      - ${DOCKER_DATA_DIR}/mongo-data:/data
    expose:
      - 27017
    networks:
      - prod_network

Weird things are :

  • How a docker daemon in a WSL instances can impact others docker daemon in other WSL instance or even weirder in a VMBox ???
  • If i add the “ports” directive to directly bind the 27017 port of theses container to the host machine, MongoDB work & respond ( on the host machine, not from the compose network )…

I’ve tried to connect to theses Mongo containers from others containers in the same network, using aliases and theirs IP; But nothing work…
I’ll inspected the instances, d-c says they have IP and the exposed port on these network…

I just have no more idea :confused:

Is there anybody with some clues on this ?

2

Your issue with multiple MongoDB containers across different virtual environments (like WSL instances and Oracle VMbox) not responding on the exposed port in the Docker Compose network, despite the configuration working when only one environment is used, is indeed perplexing.

4

Hello & thx for the response

It seems the problem is gone for the VMBox by using mongo 4.4

For the WSL, i’m gonna make some test basing you’re points.

Actually, i’ve changed the default port on the “prod” WSL image of my app, even if it’s not supposed to be in the same network, the Image now seems to work even if the dev/staging/other WSL instances were started…
But the mongo in the Dev instance no longer respond… -.-'… while its log seems OK & i’ve not changed anything…

I think, there some network overlapping, or i was thinking maybe that’s related to features like fast tpc connect
Another info, is that originally, the dev instance ( Ubuntu then Kali ) nevers fails on this point while Alpine based WSL images seemed to be systematically impacted…

I’ll check you’re options, and post here the news thx !

5

ok… the real problem is docker containers lost theirs connectivity when other wsl are started
That’s related to /etc/resolv.conf in the containers not correct in this case :

nameserver 127.0.0.11
options ndots: 0

It seems thats kind of a common problem, even if no related solutions had worked for now… i should end up with a fix ^^’

6

So, the real problem was : if i start a 2nd wsl with another instance of dockerd, my containers lose theirs connectivity with other containers and network
And i finaly found a way… but still dont know what’s the technical problem, even if i tried all the options i’ve found including messing with :

  • /etc/docker/daemon.json
  • wsl.conf
  • various subnet conf
  • ( a big etc )

Here the unique f*** solution that worked for me ( docker compose on alpine on WSL ):

  • Configure all the docker compose yml network configs by adding :
your_network:
    driver: overlay

  • Enable docker swarm mode
    docker swarm init

  • prune all previously created docker networks
    docker network prune

  • start you’re dc yml