Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

docker-entrypoint-initdb.d scripts running with wrong port? #284

Closed
J0s3f opened this issue Jun 28, 2018 · 8 comments
Closed

docker-entrypoint-initdb.d scripts running with wrong port? #284

J0s3f opened this issue Jun 28, 2018 · 8 comments
Labels
question Usability question, not directly related to an error with the image

Comments

@J0s3f
Copy link

J0s3f commented Jun 28, 2018

For automated tests, I need to create a replica set consisting of a single node to have working transactions.
Because the Port used is exposed on the build server, I use a non standard port
I changed the commandline to: --replSet rs0 --port 12345 and mounted a JavaScript file to init the rs.
The file contains:
rs.initiate({ _id: "rs0", version: 1, members: [ { _id: 0, host: "127.0.0.1:12345" } ] });

The JavaScript cannot be executed, because the server is not found at 127.0.0.1:12345.

I assume, the first start of mongo to execute the scripts ignores the port option?

@wglambert
Copy link

You need to give the -p 12345:12345 flag to docker.

$ docker run --rm -p 12345:12345 -d --name mongo mongo --replSet rs0 --port 12345
$ docker ps
CONTAINER ID        IMAGE               COMMAND                  CREATED             STATUS              PORTS                                 NAMES
532f7f4c8e0d        mongo               "docker-entrypoint.s…"   9 seconds ago       Up 8 seconds        0.0.0.0:12345->12345/tcp, 27017/tcp   mongo

@wglambert wglambert added the question Usability question, not directly related to an error with the image label Jun 28, 2018
@J0s3f
Copy link
Author

J0s3f commented Jul 2, 2018

No.

The startup scripts are executed inside the container anyway, so this changes nothing.

On the first start, when the scripts inside the folder /docker-entrypoint-initdb.d/ are executed the default port and IP are used, so it is not possible to init the replica set there.

@ft0907
Copy link

ft0907 commented Jul 5, 2018

I have similar needs and problems with you. I don't know how you solved them. Can you share them if they are solved?
The replica set configuration needs to be configured in the Mongo shell after Mongo is started, I execute after the mount script, but only after the dockerfile execution will execute the mongod boot command, and the Mongo shell command cannot be executed

@tianon
Copy link
Member

tianon commented Jul 9, 2018

Oh interesting -- we do indeed set a specific port at

_mongod_hack_ensure_arg_val --port 27017 "${mongodHackedArgs[@]}"
because we need to know where to connect in order to actually run the initdb scripts.

@J0s3f
Copy link
Author

J0s3f commented Jul 10, 2018

@ft0907 for our tests, they now run on port 27017 outside and inside the container. Currently, we can't run two integration tests needing MongoDB on the same Jenkins node in parallel. That's unfortunate, but the way it is for now.
I don't know why MongoDB doesn't just support sessions and multi-document transactions in standalone mode. This would solve all those problems for us.

For deployments we create the replica set manually.

@ft0907
Copy link

ft0907 commented Jul 13, 2018

@J0s3f I have been able to automatically configure permissions + replica sets by way of dockerfile+dockercompose, but I'm testing on a single host. It can run well. Please look at the detailed code I posted. If there are any problems, we can discuss them. detailed answer code is here #211

@tianon
Copy link
Member

tianon commented Jul 16, 2018

So, in order for us to work around this, we'd have to not only parse provided command-line flags for --port, but also would need to parse any provided configuration file to do the same, so I'm inclined to say this is just outside of what we support out-of-the-box with the included behavior (unless someone's got a simpler idea for implementing something meaningful here).

@tianon
Copy link
Member

tianon commented Aug 13, 2018

Closing, since it looks like there aren't any better/simpler ideas for what we could change here. 😞

@tianon tianon closed this as completed Aug 13, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Usability question, not directly related to an error with the image
Projects
None yet
Development

No branches or pull requests

4 participants