docker-entrypoint.sh not using correct port for first startup

[Mrc527]

Hello,

I'm trying to setup a mongo container in AWS ECS on Fargate.

As you may know, Fargate forces all the containers of the same "task" to map ports on localhost. Long story short, if you run a complex environment with plenty of containers, all of them must serve on different TCP/UDP ports.

So, now, let's imagine I want to have two mongo containers in the same task. I need to have those containers running in two different ports.

Easy, just add the --port 1234 and --port 1235 to the "command" section of the docker-compose file.

But unfortunately that's not enough.

When you start the container via docker-entrypoint.sh, the scripts temporarily starts the container on the default port for adding users and stuff.

In such a moment, the second container will find the port busy and fail.

As a workaround I currently do:
entrypoint: ["bash","-c","sed -i 's/27017/50040/' /usr/local/bin/docker-entrypoint.sh && /usr/local/bin/docker-entrypoint.sh --port 50040" ]

Clearly that's not a nice fix.

I propose, the docker-entrypoint.sh should randomly select the temporarily port, to minimise the probability of a conflict.
Even better would be to first check if the selected port is available, otherwise try with a different one.

Thanks!

[wglambert]

Similar to #437

[yosifkit]

I propose, the docker-entrypoint.sh should randomly select the temporarily port, to minimise the probability of a conflict.
Even better would be to first check if the selected port is available, otherwise try with a different one.

Selecting a random port will just make the failure non-deterministic since it'd still be able to pick a used port; checking for a port would be subject to a race condition, since the shell script isn't opening the port, mongod does.

Fortunately, it looks like we can switch to only use the unix socket during the temporary init, but this will break users that are using mongo and not "${mongo[@]}" in their shell scripts.

[tianon]

There's a potential solution to this over in #443. 👀

[rhaoio]

Is there a clean solution to this problem? I have a scenario using network_mode: host which causes a similar problem as 27017 may be used already.

[tianon]

The easiest solution in that case would be to skip our entrypoint entirely and perform your own initialization (if needed).