testcontainers-go
testcontainers-go copied to clipboard
testcontainers
Allow Mounting of Different Path to Reaper Image for Docker Daemon
Describe the bug
As of now, when the Reaper container is started, it mounts /var/run/docker.sock so the container can communicate with the Docker daemon on the host. However, if you are running Docker on a system that is not linux, this may not the be case (Windows, for example).
To Reproduce We hardcode the directory here: https://github.com/testcontainers/testcontainers-go/blob/1809d106b350ee84098b2ede028933d8da30b6fa/reaper.go#L53
Expected behavior I believe we should add support for Docker for Windows by allowing the Reaper to be configured to run on Windows.
Additional context I rarely use Docker for Windows, so I am not familiar with how this is set up exactly on Windows, I think some investigation for the right solution should be done first.
This path is not the host's path but where the daemon is running. It is the same /var/run/docker.sock on Windows & Mac, since there is a Linux VM.
hi, not sure if this is the right place to ask, but I got this stack trace when trying to create a GenericContainer in GitHub Actions that runs on windows-latest
Received unexpected error: Error response from daemon: invalid mount config for type "bind": invalid mount path: '/var/run/docker.sock' creating reaper failed github.com/testcontainers/testcontainers-go.(*DockerProvider).CreateContainer C:/Users/runneradmin/go/pkg/mod/github.com/testcontainers/[email protected]/docker.go:536 github.com/testcontainers/testcontainers-go.GenericContainer C:/Users/runneradmin/go/pkg/mod/github.com/testcontainers/[email protected]/generic.go:43
would it be related to this or https://github.com/docker/for-win/issues/4642? thanks.
@gianarb @bsideup @ronaudinho I believe that Github Actions doesn't allow a user to put docker into "linux mode", so the behavior of certain functions (such as mounting the docker socket) on Github Actions when running a windows VM is not consistent with having a linux vm.
On this note, I think it would be useful to provide a native windows-compatible option for reaper, I believe this would solve the issue @ronaudinho raised
@ClaytonNorthey92 thank you for the explanation, I guess that's why I don't recall encountering this when running tests on my local machine. does this mean that as of now, the solution is either to have native windows-compatible reaper or for github to upgrade their windows server?
hey @ronaudinho if you want a temporary solution, you could skip the reaper container. You might have to do that in more than one place, but it is an option. The downside to that solution is nothing will clean up your running containers. However, if this is in CI on a VM, then I think that VM probably gets deleted after the CI run 🤔 something to double check.
for a better, permanent solution, I think you're right. We either need a native-windows-image reaper or github actions needs to allow "linux mode". I think the former solution, a native-windows-image reaper, is a better solution. Because we can't guarantee that whatever windows environment we are running on would have "linux mode" available.
that sounds like a workaround I can try for now, thanks for the suggestion :+1:
@ronaudinho you're welcome, let me know if you have any trouble with that workaround, I am curious if you uncover other issues
sorry I haven't got the chance to check, as I am assigned to another task at the moment. I'll be sure to let you know when I've tried it @ClaytonNorthey92
@ClaytonNorthey92 I am also facing the same issue in docker for Windows environment. Setting the skipReaper value to "true" solves the issue. I wanted to know the downside of setting the skipReaper to true. Which "container" or "resources" are we talking about here?
hey @ronaudinho if you want a temporary solution, you could skip the reaper container. You might have to do that in more than one place, but it is an option. The downside to that solution is nothing will clean up your running containers. However, if this is in CI on a VM, then I think that VM probably gets deleted after the CI run 🤔 something to double check.
for a better, permanent solution, I think you're right. We either need a native-windows-image reaper or github actions needs to allow "linux mode". I think the former solution, a native-windows-image reaper, is a better solution. Because we can't guarantee that whatever windows environment we are running on would have "linux mode" available.
hey @kunal21 , The reaper container ensures that any container running gets deleted after a time delay, here is a link to the docker image.
In the testcontainers project, we use label filters to ensure that only testcontainers-started containers are stopped, here is where we start the reaper container.
This ensures that you don't have to explicitly stop a container in your test suite, reaper will stop the container for you.
So, in your case, the downside to skipping the reaper would be that nothing will clean up your containers for you, you will have to do this yourself in your code. It is not difficult, however (obviously) mistakes happen and you could accidentally forget to clean up a container. In most CI solutions that I have used, the builds run in a VM or some environment that gets cleaned up or deleted by the CI provider, so reaper may not be needed. In cases where you have your own environment (ex. your own hardware/environment in the cloud, or a local machine) you will just have to be aware that you will need to explicitly stop containers after they're being run, since reaper won't exist to provide that safety net.
Does that makes sense?
@ClaytonNorthey92 I'm closing this issue because I think it's been resolved in https://github.com/testcontainers/testcontainers-go/pull/407, supporting the TESTCONTAINERS_DOCKER_SOCKET_OVERRIDE environment variable, and released with the latest v0.14.0 release.
Could you please double check if the latest release resolved your use case? If not, please reopen the issue so we can continue working on it.
Thanks for your your time opening the issue and supporting the community with your answers in these thread.
