testcontainers-go icon indicating copy to clipboard operation
testcontainers-go copied to clipboard

[Bug]: Docker Pull fails on some machines

Open stubents opened this issue 1 year ago • 6 comments

Testcontainers version

v0.26.0

Using the latest Testcontainers version?

Yes

Host OS

MacOS

Host arch

ARM

Go version

go1.21.4 darwin/arm64

Docker version

Client:
 Cloud integration: v1.0.35+desktop.5
 Version:           24.0.6
 API version:       1.43
 Go version:        go1.20.7
 Git commit:        ed223bc
 Built:             Mon Sep  4 12:28:49 2023
 OS/Arch:           darwin/arm64
 Context:           desktop-linux

Server: Docker Desktop 4.25.2 (129061)
 Engine:
  Version:          24.0.6
  API version:      1.43 (minimum version 1.12)
  Go version:       go1.20.7
  Git commit:       1a79695
  Built:            Mon Sep  4 12:31:36 2023
  OS/Arch:          linux/arm64
  Experimental:     false
 containerd:
  Version:          1.6.22
  GitCommit:        8165feabfdfe38c65b599c4993d227328c231fca
 runc:
  Version:          1.1.8
  GitCommit:        v1.1.8-0-g82f18fe
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0

Docker info

Client:
 Version:    24.0.6
 Context:    desktop-linux
 Debug Mode: false
Server:
 Containers: 0
  Running: 0
  Paused: 0
  Stopped: 0
 Images: 17
 Server Version: 24.0.6
 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

What happened?

Hi, it seems like I'm unable to pull new images with testcontainers-go on my local machine. I know that the same config works on other operating systems / docker versions / 🤷‍♂️.

I had a look into it and dockercfs says in its comment for GetRegistryCredentials(...): "If the returned username string is empty, the password is an identity token." With the following commit I made it work again: https://github.com/stubents/testcontainers-go/commit/0b6a416d3636e32f3707f740f529f3d3e9014965

However, I'm not too familiar with container registry authentication mechanisms so I can't really say if this is the right thing to do or might break other stuff...

Nevertheless, hope this helps :)

Relevant log output

No response

Additional information

No response

stubents avatar Dec 07 '23 15:12 stubents

Could you elaborate a PR including tests to automatically demonstrate the behaviour? I've seen your patch and I think it could be fine, but I'd like to have a test demonstrating it, as we have a lot of them in the docker_auth_test.go file.

mdelapenya avatar Dec 08 '23 10:12 mdelapenya

Thanks for your quick response! I'm not completely sure how you imagine the test:

We could spin up a registry that's configured to accept an identity token and test if it accepts a token that is set in the AuthConfig. This wouldn't really have much to do with the code change I made, though.

To really see the code executed we'd need to invoke dockercfg.GetRegistryCredentials(k) but this would run directly exec.Command(...) which is hard to intercept and I don't see any other tests doing this.

Could you please point me into the right direction here?

stubents avatar Dec 08 '23 12:12 stubents

FWIW, I may be seeing a similar version of this on Fedora with Podman.

Server Version: 4.9.0 API Version: 1.41 Operating System: fedora Resolved Docker Host: unix:///run/user/1000/podman/podman.sock Resolved Docker Socket Path: /run/user/1000/podman/podman.sock

It is attempting to pull the following image: ghcr.io/cuppett/mariadb:11.0

The container is a public container,. This fails in the same way when both when there is a valid credential in my ~./docker/config.json and when there is no credential in there.

Log attached.

testcontainers-go-issue-1987.txt

cuppett avatar Feb 01 '24 18:02 cuppett

Given we have a docker registry module (https://golang.testcontainers.org/modules/registry/) I encourage you to use it in a repro project to verify this behaviour 🙏

mdelapenya avatar Apr 24 '24 10:04 mdelapenya