Support init scripts for `MongoDBContainer` without manually customizing the `WaitStrategy`

[blaluc]

A container initialized as follows, fails to start:

MongoDBContainer c = new MongoDBContainer(MONGO_IMAGE)
		.withEnv("MONGO_INITDB_ROOT_USERNAME", "root")
		.withEnv("MONGO_INITDB_ROOT_PASSWORD", "password" )
		.withFileSystemBind("init/mongo-init.js",
			"/docker-entrypoint-initdb.d/mongo-init.js", BindMode.READ_ONLY)
		;
		c.start()

Not sure but probably because the docker-entrypoint.sh, in case of presence of init-db scripts, does a shutdown and a restart of the process after executing them:

if [ -n "$shouldPerformInitdb" ]; then
...
		echo
		for f in /docker-entrypoint-initdb.d/*; do
			case "$f" in
				*.sh) echo "$0: running $f"; . "$f" ;;
				*.js) echo "$0: running $f"; "${mongo[@]}" "$MONGO_INITDB_DATABASE" "$f"; echo ;;
				*)    echo "$0: ignoring $f" ;;
			esac
			echo
		done

		"${mongodHackedArgs[@]}" --shutdown
		rm -f "$pidfile"
...

[vcvitaly]

Is it something that should be raised with https://github.com/docker-library/mongo ?

[kiview]

This is indeed somewhat related to #3077, but more in the way, that MongoDBContainer uses a LogMessageWaitStrategy that has certain expectations about the logs.

You can solve this by configuring your own appropriate LogMessageWaitStrategy.

[blekione]

@blaluc Did you manage to start the container with an init script? I'm facing the same issue, tried to use wait for log message configuration but unsuccessful.

[kiview]

@blekione Which LogMessageWaitStrategy configuration did you use?

[blekione]

 Wait.forLogMessage("your_log_message", 1)

So I added to my init script print statement with message which I'm waiting for to be printed. Most likely I'm doing it wrong, as I can see this message in logs when checking logs directly in container with docker logs but not in my test logs.

I'm really testing the grounds here. Never used Testcontainers with MongoDB

[kiview]

Can you please share a reproducer?
https://github.com/testcontainers/testcontainers-java-repro

[blekione]

https://github.com/blekione/testcontainers_reprod

@kiview or should I create pull request?

[kiview]

This is sufficient, thanks.

I am not sure what you are trying to ultimately achieve, but changing the container code like this, will be enough to wait for the log statement:

MongoDBContainer mongoDb  = new MongoDBContainer("mongo:5.0")
		.withCopyFileToContainer(MountableFile.forHostPath("init/mongo-init.js"), 
			"/docker-entrypoint-initdb.d/mongo-init.js")
		.waitingFor(Wait.forLogMessage("Start_script_now\\s", 1))
		.withStartupTimeout(Duration.ofSeconds(10));

Note the \s flag for the matching of whitespace character (newline) at the end of the line.

However, this will fail now with the initialization of the replica set. Probably because you overwrote the actual initialization scrit like this? (not a MongoDB expert, sorry)

[blekione]

@kiview I want to add some records to the database at the initialisation. I tend to write first test as if my db service can read from the database before I can write (chicken and egg problem really). Using init script is the only way I know to do so. Not expert from MongoDB either, and I suspect much less knowledgable than you with Docker and Testcontainers.

[kiview]

Oh sorry, I understand the context now better (this is is 1,5 years old after all).

This here is the example using the appropriate log message if an init script is used:

MongoDBContainer mongoDb  = new MongoDBContainer("mongo:5.0")
	.withCopyFileToContainer(MountableFile.forHostPath("init/mongo-init.js"),
			"/docker-entrypoint-initdb.d/mongo-init.js")
	.waitingFor(Wait.forLogMessage("(?i).*waiting for connections.*", 2))
	.withStartupTimeout(Duration.ofSeconds(10));

Placing the init script into /docker-entrypoint-initdb.d will trigger a restart of MongoDB. So by changing the LogMessageWaitStrategy to expect the default log message 2 times will make this setup work. You can now fill mongo-init.js with your specific code to fill the database.

I also decided to re-open the issue and rephrase it, since I feel this is a lacking feature from our MongoDBContainer implementation.