Add "docker-entrypoint-initdb.d" behavior which mimics PostgreSQL, including (optional) automated "root" user creation

[tianon]

Closes #52
Closes #53
Closes #89

This ensures that the initialization scripts will only run once, and only offers the ability to create a user with the role of "root" -- authentication in MongoDB is fairly complex, so explicitly leaving more complex user setup to the user (via /docker-entrypoint-initdb.d/*.js or *.sh) seems prudent (essentially, only solving the most basic pain point of needing some way to invoke that initial db.createUser after enabling --auth).

[tianon]

Not sure what to do about Windows here. 😞

[GrapeBaBa]

Nice to see

[yosifkit]

Same problem as mysql 😢

  -h [ --help ]                         show this usage information
  --version                             show version information

[tianon]

Oh boo, that's cute:

$ docker run -it --rm mongo:3.4 --version
db version v3.4.2
git version: 3f76e40c105fc223b3e5aac3e20dcd026b83b38b
OpenSSL version: OpenSSL 1.0.1t  3 May 2016
allocator: tcmalloc
modules: none
build environment:
    distmod: debian81
    distarch: x86_64
    target_arch: x86_64

/usr/local/bin/docker-entrypoint.sh: ignoring /docker-entrypoint-initdb.d/*

db version v3.4.2
git version: 3f76e40c105fc223b3e5aac3e20dcd026b83b38b
OpenSSL version: OpenSSL 1.0.1t  3 May 2016
allocator: tcmalloc
modules: none
build environment:
    distmod: debian81
    distarch: x86_64
    target_arch: x86_64

MongoDB init process complete; ready for start up.

db version v3.4.2
git version: 3f76e40c105fc223b3e5aac3e20dcd026b83b38b
OpenSSL version: OpenSSL 1.0.1t  3 May 2016
allocator: tcmalloc
modules: none
build environment:
    distmod: debian81
    distarch: x86_64
    target_arch: x86_64

[tianon]

This would be somewhat solved if we added MongoDB 3.2's check-and-retry-once logic to everything, since we'd then be at least verifying that the daemon actually did start up properly. Perhaps just adding the "check" portion of that would be sufficient?

Do you think we really need to go to the extreme of explicitly detecting --home and/or --version directly? (especially since there are other things that might cause the daemon to not start up correctly too)

[yosifkit]

Check and retry on all versions would be a good addition, but won't it still print multiple times or at least be silly and print error: mongod does not appear to have started up quickly enough ... when a user was just getting --help/--version?

[tianon]

Yeah, it'll print an extra error, but it'll only print once, and I think it still serves the purpose just fine -- users who don't want to run the daemon explicitly really ought to simply be bypassing our entrypoint entirely, IMO (but at least adding this would provide the expected information):

$ docker run -it --rm mongo:3.2 --version
db version v3.2.12
git version: ef3e1bc78e997f0d9f22f45aeb1d8e3b6ac14a14
OpenSSL version: OpenSSL 1.0.1t  3 May 2016
allocator: tcmalloc
modules: none
build environment:
    distmod: debian81
    distarch: x86_64
    target_arch: x86_64
error: mongod does not appear to have started up quickly enough -- perhaps it had an error?

[yosifkit]

explicitly? but that is 7 extra characters " mongod" 😉 ¯\_(ツ)_/¯

[tianon]

PR is updated to check whether mongod actually started in all versions now (and I updated 3.2's check to diff cleanly/consistently).

We're still providing the information they asked for, they just get some harmless extra error output (telling them that initdb failed due to the flags they requested we start it with). For interactive users, they'll usually be concerned about getting the flag name they need so they can either update their script or their ad-hoc invocation (which this provides), and if users are actually using --help or --version in a script, I really would doubly recommend they use --entrypoint or something to bypass our extra initdb behavior explicitly, but I don't see a real strong use case for putting those in scripts 😕.

IMO adding an explicit check for --version or --help is overkill (added lines to our script for small benefit), but I am willing to add them if you really insist and feel strongly that they provide useful value to our users (commensurate to the added maintenance burden of debugging/enhancing them if future versions of MongoDB change things, debugging our implementation, etc).

[tianon]

Here's the final output, for context:

$ docker run -it --rm mongo:3.4 --version
db version v3.4.2
git version: 3f76e40c105fc223b3e5aac3e20dcd026b83b38b
OpenSSL version: OpenSSL 1.0.1t  3 May 2016
allocator: tcmalloc
modules: none
build environment:
    distmod: debian81
    distarch: x86_64
    target_arch: x86_64

error: mongod does not appear to have started up -- perhaps it had an error?

$ docker run -it --rm mongo:3.2 --version
db version v3.2.12
git version: ef3e1bc78e997f0d9f22f45aeb1d8e3b6ac14a14
OpenSSL version: OpenSSL 1.0.1t  3 May 2016
allocator: tcmalloc
modules: none
build environment:
    distmod: debian81
    distarch: x86_64
    target_arch: x86_64

error: mongod does not appear to have started up -- perhaps it had an error?

$ docker run -it --rm mongo:3.0 --version
db version v3.0.14
git version: 08352afcca24bfc145240a0fac9d28b978ab77f3

error: mongod does not appear to have started up -- perhaps it had an error?

$ 

[reypm]

Is there any chance to automate DB creation as well? What's the status of this PR? I was about to open a issue regarding this but just found @tianon is already taking care of this

[tianon]

@reypm so, I don't think automating "db creation" really makes much sense, right? (since MongoDB is fundamentally designed for "create on first use")

Things like setting up indexes is something you'd have to script yourself, but this gives you the tools to do so (via *.sh or *.js files in this special directory).

[reypm]

@tianon ok waiting on this PR to be merged and then use my own scripts

[bchrobot]

Is https://github.com/docker-library/docs/blob/master/mongo/content.md the place to make a PR against to add documentation for these changes?

@yosifkit

[yosifkit]

@bchrobot, yes, see #189 for the issue tracking the docs. My comment there is soon to be out of date since @tianon is actively working on a PR to make config files work with the temporary mongo used to create users.

[tianon]

See #225 for the PR which finally adds --config support to this! 🎉 🎈 🎄

[jeff-bothe]

in my custom /docker-entrypoint-initdb.d/*.js or *.sh script, is there a way to access env variables defined in a .env file? Meaning, env variables other than MONGO_INITDB_ROOT_USERNAME and MONGO_INITDB_ROOT_PASSWORD.

thanks

[tianon]

In a shell script, yes, they should be directly usable -- in a javascript file, no (since those get loaded directly by the "mongo" interpreter which has no method for reading environment variables).