[Bug]: failed to connect to reaper: dial tcp 127.0.0.1:33267: connect: connection refused: Connecting to Ryuk on localhost:33267 failed #2618
Labels
bug
An issue with the library
Comments
|
@maxmzkr Can you include your compose file? |
|
yup, here's a quick example services:
job2:
image: ubuntu
command: echo "completed"
depends_on:
job1:
condition: service_completed_successfully
job1:
image: ubuntu
command: sleep 20
depends_on:
- server
server:
image: ubuntu
command: echo started && sleep infinitypackage main
import (
"context"
"testing"
"github.com/stretchr/testify/require"
tc "github.com/testcontainers/testcontainers-go/modules/compose"
)
func Test(t *testing.T) {
ctx := context.Background()
compose, err := tc.NewDockerCompose("docker-compose.yaml")
require.NoError(t, err)
t.Cleanup(func() {
require.NoError(t, compose.Down(context.Background(), tc.RemoveOrphans(true), tc.RemoveImagesLocal))
})
ctx, cancel := context.WithCancel(ctx)
t.Cleanup(cancel)
require.NoError(t, compose.Up(ctx, tc.RunServices("server", "job1", "job2"), tc.Wait(false)))
} |
|
I think issue is related to #2563 (comment) I'd check if increasing the timeouts for ryuk with compose fix it: as we are delegating to compose the pull of the images it could be the case ryuk needs more time, depending on the number and type of services in your compose file. |
|
In fact, this issue seems a duplication of #2563 I'm closing this in favor of the other one 🙏 Please reopen it if you consider is different, thank you! |
|
I think it's possible it's related. I see a ipv6 address in that one and I worry it has something to do with weird ipv6 handling. Some mac users on our project have needed to manually specify a ipv4 address for ryuk. I'll treat them the same until we have a better reason to believe otherwise |
This was referenced Jul 2, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Testcontainers version
0.31.0
Using the latest Testcontainers version?
Yes
Host OS
Linux
Host arch
x86
Go version
1.21.4
Docker version
docker version Client: Docker Engine - Community Version: 26.1.3 API version: 1.45 Go version: go1.21.10 Git commit: b72abbb Built: Thu May 16 08:35:10 2024 OS/Arch: linux/amd64 Context: default Server: Docker Engine - Community Engine: Version: 26.1.3 API version: 1.45 (minimum version 1.24) Go version: go1.21.10 Git commit: 8e96db1 Built: Thu May 16 08:33:26 2024 OS/Arch: linux/amd64 Experimental: false containerd: Version: 1.6.32 GitCommit: 8b3b7ca2e5ce38e8f31a34f35b2b68ceb8470d89 runc: Version: 1.1.12 GitCommit: v1.1.12-0-g51d5e94 docker-init: Version: 0.19.0 GitCommit: de40ad0Docker info
What happened?
We are using the docker compose module with this snippet
init1 depends on db being started, and init2 depends on init1 completing successfully.
During this time, we are finding that the ryuk container is spun up, and then is terminated before Up has completed.
Some notes, when we have a failure, we see this in the logs
but when we have a success, we don't see this in the logs. The connection appears to come from the ryuk waitstrategy. I don't know for sure, but it seems like it's possible for the waitstrategy to connect and disconnect quick enough that ryuk doesn't see the connection, and that is when our tests work.
Ideally ryuk would not shut down while Up is being run. I know we can set reconnect timeout higher, but it would be nice to have this work out of the box without having to change a setting.
Relevant log output
The text was updated successfully, but these errors were encountered: