-
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Cannot connect to ryuk when using docker wormhole on centos #1740
Comments
Also note that connecting from one container to another through the mapped ports on the gateway ip works on Docker for Windows. I only encounter the connection refused error in the CI environment, which is running:
|
Hi @philsttr! We indeed need to think about accessing the containers by their IPs in environments like yours. Meanwhile, one way of solving this should be to use "--network=host" (unless your tests assign fixed ports already) Some users have also reported a success after adjusting the firewall rules: |
Thanks for the quick response @bsideup ! (I swear I'm not stalking you) Unfortunately, I don't think using I also looked into adjusting firewall rules. I had found #1277 before filing this issue, but I was unable to get that to work. Docker is manually adding individual nat rules when it spins up containers (see the second comment in my iptables output) that are preventing the connections from happening. So, it's not as simple as a one-time change. I feel like this environment is a standard docker "wormhole" pattern, and was surprised when testcontainers didn't work in it, since the docs explicitly state that this is a supported configuration. It's just docker on linux. We're not really doing anything fancy. I would imagine that docker would be adding these same iptables rules in every environment.. |
We even run our CI with this setup (see Travis' config) I think you have two "unusual" parameters of your setup:
I am on vacation, will come back on Monday and ping other RHEL/CentOS users. You can try searching for redhat-specific issues meanwhile, it was reported a couple of weeks ago |
As a small addition, I've run and supported multiple different Gitlab-CI environments using the docker-wormhole pattern and this issue never occurred to me. So in general docker wormhole pattern is well supported by Testcontainers, but of course certain configurations are still troublesome. |
Thanks for the updates guys. I've done some additional research here. I was able to try
I also tried some experiments on some newly created VMs locally. I tried both a centos 7.6 VM and a ubuntu 19.04 VM. On each VM, I just installed docker using yum/apt-get, and ran the netcat/telnet test I mentioned above. On ubuntu 19.04, So, this definitely seems specific to centos. And it affects the most generic centos VM that I could create (e.g. install OS->install docker->test->fail). |
I was able to get |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you believe this is a mistake, please reply to this comment to keep it open. If there isn't one already, a PR to fix or at least reproduce the problem in a test case will always help us get back on track to tackle this. |
This issue has been automatically closed due to inactivity. We apologise if this is still an active problem for you, and would ask you to re-open the issue if this is the case. |
This is still an issue. Maybe this could be re-opened? In fact, this is not only an issue with Ryuk. When Ryuk ist disabled, the connection to the other containers (like mariadb or kafka) will fail as well. |
@ChristianCiach what you described is an issue with your environment (and probably firewall) and not Testcontainers. It would fail with plan |
Well, yes and no. You already mentioned above that it would be better to connect to the specific container IPs instead of connecting to the
|
@ChristianCiach that did not age well :D When ports are exposed by Docker, it works no matter how container is configured (eg no bridge network, or host network), while connecting to container IPs might not always work. We recommend fixing the firewall config instead, or using |
Thanks for your fast feedback. Unfortunately I am not in charge of our iptables configuration, but I agree with you that this is the main issue here. |
I'm using testcontainers-java while building on jenkins with a docker agent. i.e. the docker "wormhole" pattern.
I'm getting the dreaded "Can not connect to Ryuk" error. (gist with full log)
Here's what I have found while debugging:
First, testcontainers determines the dockerHostIp by looking for the default route in a new temporary container. This returns
192.168.0.1
in this environment.Next, testcontainers starts the ryuk container, retrieves the mapped port, and tries to connect to it through the gateway ip
In this environment, the connection is refused as seen in the error message above.
In this enviroment, docker does not allow connecting from one container to another container through ports on the gateway ip.
Docker only allows using these ports from outside of a docker container (e.g. connections from the docker host vm)
On the other hand, docker does allow connecting from one container to another using the ip address of the desired container, with it's exposed port. (e.g. 192.168.0.2:8080)
I have found that the following iptables rules (managed by docker) explicitly prevent using ports on the gateway ip from within a docker container to communicate to another container:
Note again that these are managed by docker. I have done nothing to them.
I confirmed this docker behavior outside of testcontainers by starting up a simple netcat listener container...
and trying to connect to it from another container, through the gateway ip (which fails)
and then trying to connect to it from another container via the container's specific ip/port
So, it seems to me that when using the "docker wormhole" pattern, testcontainers should connect to ryuk using the ryuk container's ip address and exposed port, rather than the gateway ip and mapped port.
Another observation (separate issue) is that all of this assumes that both the source docker container and the ryuk docker container are both running on the default bridge network. Using a user-defined bridge network is not supported.
The text was updated successfully, but these errors were encountered: