3

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?

Tue Christensen
  • 193
  • 9

1 Answers1

1

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.

Kevin Wittek
  • 1,369
  • 9
  • 26
  • Thanks Kevin - you are right regarding the Docker-Wormhole pattern and it is causing us other issues as well. It should be said the code definitely runs better (i.e. fails at a later stage) due to the copying of the file with withCopyFileToContainer instead of the obsessive mounting of folders (defaulted to "/tmp" even which causes even more issue). I think I will look into a more proper way of sharing the data, maybe named volumes explicitly or, for this specific case, using a mock server to serve the file instead. Edit: Prematurely submitted the answer. – Tue Christensen May 08 '22 at 12:18