TCP protocol - unexpected results on WSL for Docker Desktop

[jsg24]

Hi there,

TCP/IP protocol is failing for the commands below. I note that I can create images successfully from WSL via my Dockerfile as per: https://stackoverflow.com/questions/66466339/docker-for-windows-and-wsl1-to-work-together

(def dr-images (cj/client {:engine :docker, :category :images, :version "v1.41", :conn {:uri "tcp://localhost:2375"}}))

(cj/ops c/dr-images)
=>
'(:ImageList
 :ImageLoad
 :ImagePrune
 :ImagePush
 :ImageHistory
 :ImageDelete
 :ImageCreate
 :ImageGet
 :ImageTag
 :ImageSearch
 :ImageInspect
 :ImageGetAll)

(cj/invoke c/dr-images {:op :ImageList})
=> nil

(cj/invoke c/dr-images {:op     :ImageCreate
                          :params {:fromImage "busybox:musl"}})
=> nil

Appreciate any advice and thanks in advance!

[lispyclouds]

Hey!

This indeed looks quite weird! Since not having an access to a Windows machine to test this well for me, I need your help to debug this further. What happens when you do a curl http://localhost:2375/v1.41/images/json? Or maybe just trying to open that url in the browser?

Let's make sure all the network is fine and then we can get into the clojure bits!

[lispyclouds]

Also could you try with http://localhost:2375 not tcp://... as the URL when making the client to see if it makes it better?

[jsg24]

Hi!

Thanks for the suggestion! I wouldn't have expected http to be open given the Docker Desktop setting:

I get the following result:

curl http://localhost:2375/v1.41/images/json
=>
[{"Containers":-1,"Created":1668516321,"Id":"sha256:e689acad5a65d9ba425913b0fa3d20129963004aaa3588b771edf3b32898b998","Labels":null,"ParentId":"","RepoDigests":null,"RepoTags":["samsondaemon:latest"],"SharedSize":-1,"Size":1579298034,"VirtualSize":1579298034}]

And from my own tooling, wrapping yours, I get the following logs:

:ContainerCreate samsondaemonrepl
{:Id "6542bb111859821c13f55ae2e309c47d56411fa6ac11d4be1fd7daa3eea616da",
 :Warnings []}
:ContainerCreate nginx
{:message "No such image: nginx:latest"}
:ContainerCreate localstack-main
{:message "No such image: localstack/localstack:latest"}
:NetworkCreate
{:Id "7179fff7a14f2797b9573c1f98607b7ee65c12848c581a9e94dcdffdc1f9d9da",
 :Warning ""}

Interesting that it can create containers based on my Dockerfile but not the Dockerhub images that work on OSX.

[jsg24]

Sorry I realised I forgot to Docker pull. It's been a while. 😅

[jsg24]

For my purposes, I have enough to move forward and consider this issue resolved.

Thanks again your help!

[lispyclouds]

Awesome! Yeah its essentially HTTP happening over UNIX sockets when talking to the daemon. Using tcp:// confuses the underlying client machinery this lib has and that is possibly manifesting as that very helpful nil 😕

If you have a suggestion to improve the docs here, more than happy to accept pull requests or I can try to incorporate this into the docs here!

Thanks for debugging and feel free to close the issue too!

[jsg24]

Hi @lispyclouds , I came across yet another quirk.

Found out that my image building didn't work unless I set

export DOCKER_HOST=tcp://localhost:2375

and creating the containers didn't work unless I reset it to:

export DOCKER_HOST=http://localhost:2375

Not sure if this requires the issue to be re-opened or just worked-around.

[lispyclouds]

Interesting! When you say image building and container creation, do you mean using contajners or via the docker CLI or something? Contajners should not be using that env var and the only way to connect to the docker daemon is via client creation in code. Or do you mean these need to be there regardless?

[jsg24]

Hey @lispyclouds ,

Sorry, you're right! I took a further look at the babashka script my colleague wrote and the image creation is using the docker cli shell script.

This all makes sense now.

Thanks for helping with this!

[lispyclouds]

awesome! thanks for the info!

[lispyclouds]

@jsg24 if you'd like an example of building the image in bb too, here's one.

It's a fair amount of moving parts, but this is essentially what the docker CLI does as well as the tarring of the dir isn't part of the docker api, needs to happen client side.