Testcontainers works locally but fails on build server (DinD)

846 Views Asked by At

Our recent move to a jenkins in a docker-image has not been so smooth.

We have a (over?)complicated setup where one docker container starts a new one and, previously, shared data with the new container by sharing host-folders.

In essence we have Jenkins running in docker and building java projects. One of these projects will fire up several Testcontainers, transfer a jar from a project to a container which will in turn start a new container and share this jar through a volume. The setup works on a local machine where jenkins is not involved (thus no "outer" docker layer).

Our build server "setup"

On our build server everything seems to go fine, the jar file is found on the "jobexecutor" but cannot be run using standard java -jar ourFile.jar failing with a "unable to access jarfile".

The docker socket is shared all the way through and the mountablefile is verified to exist on the "jobcontroller" image with the right size, and 777 permission. It is also found on the jobexecutor.

Debugging is painstakingly slow/hard as this only occurs on the build server and not locally.

Ideas? Or is this simply too complicated for a DinD scenario?

1

There are 1 best solutions below

2
On

If you are sharing the Docker socket, you are not running the traditional DinD setup, but the Docker-Wormhole pattern, meaning the containers will be sibling containers and mounting files becomes much more complicated since it now happens relative to the host and not with regards to other containers.

If you would share your Java code that uses Testcontainers and executes the tests I can edit this answer to be more detailed, but in general, you should be able to have a much more portable setup by using withCopyFileToContainer() (maybe together with copyFileFromContainer(), depending on the use case) method from Testcontainers, instead of folder mounting. This method will transfer the file or folder using the docker cp mechanism and is very portable and straight-forward to use, not matter the Docker environment.