Skip to content
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

Make it possible to customize 'ryuk' reaper config #50

Open
rvem opened this issue Apr 15, 2024 · 3 comments · May be fixed by #51
Open

Make it possible to customize 'ryuk' reaper config #50

rvem opened this issue Apr 15, 2024 · 3 comments · May be fixed by #51

Comments

@rvem
Copy link

rvem commented Apr 15, 2024

I stumbled upon moby/moby#42442 which periodically breaks tests that are based on testcontainers-hs.

One way to workaround this issue is to disable IPv6 altogether on the machine that runs tests, but IMO this doesn't sound like a nice solution since test suite results consistency will depend on local setup.
Instead, it'd be better to run the ryuk container with --publish 127.0.0.1::8080 instead of --publish 8080, however, this is not viable with the current interface provided by testcontainers-hs.

What I propose to do is to add a version of withContainers function that will allow running the TestContainer action either with custom Config or with custom Reaper container.

@rvem
Copy link
Author

rvem commented Apr 16, 2024

I've looked at the code a bit more, and looks like the right way to solve the problem is to resolve this TODO

@rvem
Copy link
Author

rvem commented Apr 16, 2024

So the actual problem is that localhost is resolved to [::1] by head <$> getAddrInfo ..., while the first entry in the container port binding is IPv4, thus an attempt to query [::1] on IPv4 port fails.
Ideally, we'd need to resolve the docker host before figuring out the mapped port

@rvem
Copy link
Author

rvem commented Apr 16, 2024

Hmm, judging by testcontainers-go and testcontainers-node, this is somewhat known problem and their solution is to either not use IPv6 or specify IPv4 addresses in port bind explicitly

rvem added a commit to serokell/testcontainers-hs that referenced this issue Apr 18, 2024
…ution

In some cases, 'localhost' might be resolved to IPv6 '::1', while
'containerPort' will grab IPv4 host IP port mapping by default,
when Docker maps different ports for host's IPv4 and IPv6 addresses,
this might cause timeout errors.

To solve this issue, the Docker host is resolved from 'localhost' at
container creation time, host IP protocol version is later used to
deduce the corresponding port in 'containerPort' function.

Additionally, helper 'containerAddress', as well as 'TraceOpenSocket'
and 'TraceHttpCall' now operate 'IP' addresses instead of
plain 'Text' domains. This should be safe since we only actually
consider domains within some Docker network or 'localhost' at the
moment.
rvem added a commit to serokell/testcontainers-hs that referenced this issue Apr 18, 2024
…ution

In some cases, 'localhost' might be resolved to IPv6 '::1', while
'containerPort' will grab IPv4 host IP port mapping by default,
when Docker maps different ports for host's IPv4 and IPv6 addresses,
this might cause timeout errors.

To solve this issue, the Docker host is resolved from 'localhost' at
container creation time, host IP protocol version is later used to
deduce the corresponding port in 'containerPort' function.

Additionally, helper 'containerAddress', as well as 'TraceOpenSocket'
and 'TraceHttpCall' now operate 'IP' addresses instead of
plain 'Text' domains. This should be safe since we only actually
consider domains within some Docker network or 'localhost' at the
moment.
rvem added a commit to serokell/testcontainers-hs that referenced this issue Apr 18, 2024
…ution

In some cases, 'localhost' might be resolved to IPv6 '::1', while
'containerPort' will grab IPv4 host IP port mapping by default,
when Docker maps different ports for host's IPv4 and IPv6 addresses,
this might cause timeout errors.

To solve this issue, the Docker host is resolved from 'localhost' at
container creation time, host IP protocol version is later used to
deduce the corresponding port in 'containerPort' function.

Additionally, helper 'containerAddress', as well as 'TraceOpenSocket'
and 'TraceHttpCall' now operate 'IP' addresses instead of
plain 'Text' domains. This should be safe since we only actually
consider domains within some Docker network or 'localhost' at the
moment.
rvem added a commit to serokell/testcontainers-hs that referenced this issue Apr 22, 2024
…ific host IP

The main motivation for this change is the fact that by default Docker
will map both ipv4 and ipv6 addresses and in some cases Docker will map
them to different host ports causing 'testcontainer-hs' testsuite to
fail while waiting for container to be available at specific port.

So this commit introduces an ability to explicitly host IP and port
via 'setExpose' using the same syntax as 'docker run --publish/expose'
option (see https://docs.docker.com/reference/cli/docker/container/run/#publish).

A few more cursed instances are added. Mostly for the sake of backward
compatibility with old 'setExpose' interface:)
rvem added a commit to serokell/testcontainers-hs that referenced this issue Apr 22, 2024
…ific host IP

The main motivation for this change is the fact that by default Docker
will map both ipv4 and ipv6 addresses and in some cases Docker will map
them to different host ports causing 'testcontainer-hs' testsuite to
fail while waiting for container to be available at specific port.

So this commit introduces an ability to explicitly host IP and port
via 'setExpose' using the same syntax as 'docker run --publish/expose'
option (see https://docs.docker.com/reference/cli/docker/container/run/#publish).

A few more cursed instances are added. Mostly for the sake of backward
compatibility with old 'setExpose' interface:)
rvem added a commit to serokell/testcontainers-hs that referenced this issue Apr 22, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant