Im running a Java application inside a rocky-docker image, and the application listens on port 9095.
When I run it with the command
‘docker run --name AutoTest -p 9095:9095 image-name’
and go to localhost:9095 in a browser, the result is different depending on if I run the container on Windows or Ubuntu.
On Windows nothing happens and I get an error that no response was returned, on Ubuntu the application responds.
If I do a ‘netstat -an | grep LISTEN’ inside the container, then on Docker Windows the application listens on
‘tcp6 0 0 127.0.0.1:9095 :::* LISTEN’
but on Ubuntu it is
'tcp6 0 0 :::9095 :::* LISTEN ’
even though the images are identical and the command is the same.
I cannot change the application only the image.
How do I make this work on Windows as well?
Why is the behavior inside the container different when being run on docker Windows and Ubuntu?
The only difference is that Docker Desktop runs its Docker Engine in a Linux utility vm. published ports on Docker Desktop should be reachable on the host’s lan and localhost ip.
While I agree with @meyay, if you can reproduce it with an image that you can share, we can try to reproduce it too. The application should decide on which port and IP it listens on, so if in one case it listens on only a loopback IP and in another case it listens on all IP addresses, There must be some difference in how the containers are started, or the app detects something in the environment and automatically listens on another IP. It should not happen, but I can imagine small differences in the virtual machine as I remember that the exact implementation was a little different on each platform
Unfortunately I can’t seem to reproduce it outside of our application (which I cannot share).
But I have noticed that if I create the image on Ubuntu (using the same files, scripts and commands) and save it. Then it works correctly when loaded and run on Windows. The saved image is also about twice the size when created on Ubuntu vs Windows.
All a bit weird considering that all of the docker stuff /except the runtime) is the same.
“Saved image” as in exported with docker image save? The resulting files should have a similar size.
Let’s iron out some ambiguities of the fist post:
Did you install the docker-ce package on Ubuntu?
When you refer to Docker Windows, do you mean Docker Desktop on Windows 10/11, which can run Linux containers, or do you mean Docker on Windows Server, which can only run Windows containers..
Or do you refer to docker-ce installed inside a WSL2 distribution?
Are you only working with Linux containers? Note: Windows containers require a whole different Dockerfile, their size will be magnitudes bigger.
If it’s about the shown image size in docker image ls, then there might be an easy explaination:
if containerd is used to store the images, the shown file size will be the sum of the imported/pulled compressed image layers and the extracted layers.
If you share the output of docker info of both systems, we should be able to see it.
Pleaes clearify the gaps for us, so we can get a better idea of the situation.
Saving the image should be the same on each platform with or without containerd as an image store. The only difference I can imagine is when either the base image is different or the copied files are different. I would try to compare the two exported images. Look for files on the image filesystem and see if there is any difference in the number of files or the size of them.
I can imagine for example dynamically downloaded files to the host and corrupting them before copying into the image. I can’t tell you a good example, but when cloning files from a git repo on Windows, Linux line ending s can be changed which brakes the scripts. I vagely remember binaries that were smaller before I copied them somewhere else.
I know this was not the original issue, but finding out the difference in the image hopefully says something about the original issue as well.