[Bug]: Docker address confusion

[ash2k]

Testcontainers version

9cc2598

Using the latest Testcontainers version?

Yes

Host OS

macOS

Host arch

arm64

Go version

1.22.4

Docker version

Client: Docker Engine - Community
 Version:           27.0.2
 API version:       1.44 (downgraded from 1.46)
 Go version:        go1.22.4
 Git commit:        912c1ddf8a
 Built:             Wed Jun 26 18:39:48 2024
 OS/Arch:           darwin/arm64
 Context:           rancher-desktop

Server:
 Engine:
  Version:          25.0.5
  API version:      1.44 (minimum version 1.24)
  Go version:       go1.21.10
  Git commit:       e63daec8672d77ac0b2b5c262ef525c7cf17fd20
  Built:            Sun May 12 07:25:43 2024
  OS/Arch:          linux/arm64
  Experimental:     false
 containerd:
  Version:          v1.7.10
  GitCommit:        4e1fe7492b9df85914c389d1f15a3ceedbb280ac
 runc:
  Version:          1.1.12
  GitCommit:        51d5e94601ceffbbd85688df1c928ecccbfa4685
 docker-init:
  Version:          0.19.0
  GitCommit:

Docker info

Client: Docker Engine - Community
 Version:    27.0.2
 Context:    rancher-desktop
 Debug Mode: false
 Plugins:
  buildx: Docker Buildx (Docker Inc.)
    Version:  v0.14.1
    Path:     /Users/mike/.docker/cli-plugins/docker-buildx
  compose: Docker Compose (Docker Inc.)
    Version:  v2.27.1
    Path:     /Users/mike/.docker/cli-plugins/docker-compose

Server:
 Containers: 6
  Running: 0
  Paused: 0
  Stopped: 6
 Images: 58
 Server Version: 25.0.5
 Storage Driver: overlay2
  Backing Filesystem: extfs
  Supports d_type: true
  Using metacopy: false
  Native Overlay Diff: true
  userxattr: false
 Logging Driver: json-file
 Cgroup Driver: cgroupfs
 Cgroup Version: 2
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local splunk syslog
 Swarm: inactive
 Runtimes: io.containerd.runc.v2 runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: 4e1fe7492b9df85914c389d1f15a3ceedbb280ac
 runc version: 51d5e94601ceffbbd85688df1c928ecccbfa4685
 init version: 
 Security Options:
  seccomp
   Profile: builtin
  cgroupns
 Kernel Version: 6.6.30-0-virt
 Operating System: Alpine Linux v3.19
 OSType: linux
 Architecture: aarch64
 CPUs: 9
 Total Memory: 15.6GiB
 Name: lima-rancher-desktop
 ID: d04c0365-7614-447f-960d-353ba1523b4f
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 Experimental: false
 Insecure Registries:
  127.0.0.0/8
 Live Restore Enabled: false

What happened?

I have DOCKER_HOST=unix:///Users/mike/.rd/docker.sock to use Rancher Desktop that I have running. I also have Test Containers Desktop installed but it's not running. But there is a config file that it created:

$ cat ~/.testcontainers.properties
testcontainers.reuse.enable = true
tc.host = tcp://127.0.0.1:61153
docker.host = tcp://127.0.0.1:61153

When I run the test it runs for some time, does a few test containers things but then fails with an error

saving images saving images Cannot connect to the Docker daemon at tcp://127.0.0.1:61153. Is the docker daemon running?

It fails on k3s.LoadImages(). Looking at the log output, Resolved Docker Host is from Test Containers Desktop and Resolved Docker Socket Path is from the default Docker context. They don't match each other at all.

The right thing to do is probably to use the selected Docker context?

$ docker context list
NAME                DESCRIPTION                               DOCKER ENDPOINT                      ERROR
default             Current DOCKER_HOST based configuration   unix:///var/run/docker.sock
rancher-desktop *   Rancher Desktop moby context              unix:///Users/mike/.rd/docker.sock

Relevant log output

2024/07/03 13:41:44 github.com/testcontainers/testcontainers-go - Connected to docker: 
  Server Version: 25.0.5
  API Version: 1.44
  Operating System: Alpine Linux v3.19
  Total Memory: 15970 MB
  Resolved Docker Host: tcp://127.0.0.1:61153
  Resolved Docker Socket Path: /var/run/docker.sock
  Test SessionID: 6e4dba3df3ad66d1e9850235cab48c0932ccf548532d0ca1aa0deafa462e7c1c
  Test ProcessID: c4deea13-769c-4a5a-9827-d7c4cf5007ee

Additional information

No response

[mdelapenya]

@ash2k I see, I think the error comes from the socket path resolution strategy, that should verify if each location, when found, responds to a ping/info call.

I'll work on this for the upcoming release, thanks for pointing it out.