Hi Eyal, I am still a beginner regarding MongoDB. But deployment was surprisingly easy.
We are still in development/testing and for our test workstations we are using this (I don’t know if it’s best practice, but it’s working perfectly fine):
We are shipping the tgz/zip versions of the MongoDB software with a small setup script, that generates a minimal configuration file with absolute paths for system-log, storage and pid-file.
logAppend: false # we want to keep the logs short
fork: true # fork and run in background
Additionally some kind of init-file is created, that provides the database path to our software. When our software launches we start the mongodb daemon binary with the -f option so that it uses our custom configuration and not searches for a global one.
/PORTABLE_MONGODB_FOLDER/bin/mongod -f /PORTABLE_MONGODB_FOLDER/mongod.conf
And killing it with the process ID provided in the pid file.
kill $(cat /PORTABLE_MONGODB_FOLDER/mongod.pid)
This is working like a charm on linux and windows workstations (with small adjustments for windows). It is very lean and totally unubstrusive. We don’t need any installation. We can also access the db at a custom port and prevent interference with another mongodb that the customer might have already installed. All mongodb-related files are in one directory.
I don’t know, if it would even be possible to use relative paths in the configuration. Then we wouldn’t even need the setup script.
I haven’t figured out all the licensing issues. Seems like it wouldn’t be any problem at all if our software was completely open source. Unfortunately, we’re depending on at least one closed source static library. We couldn’t find out, if it would be OK to ship the mongodb binaries together with this closed source library. Therefore we plan to make the install script download the mongodb binaries instead of shipping them once we deliver to customers.