Closed ILucasI closed 1 year ago
Thanks, Docker wouldn't start for me after the update, adding the hosts entry back in fixed it.
Thanks, a few hours wasted (who I have to invoice for this?) trying to find why my containers running without port mapping (or with port mapping configured from an application like lando) wasn't working: adding rules to the firewall, updating/upgrading everything,... trying a thousand combinations...
can anyone tell me how to try this fix. i've tried deleting all antivirus too from my computer and still nothing. tried reinstalling everything and still nothing. docker can eventually get running in WSL and pull images but docker desktop doesnt work at all. and when i close WSL docker just crashes. thanks!(been trying to fix this for days. really missing my macbook lol)
System.InvalidOperationException:
distro stopped unexpectedly
at Docker.Engines.LinuxkitDaemonStartup.
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Docker.Engines.Engines.
Thanks, Docker wouldn't start for me after the update, adding the hosts entry back in fixed it.
I had same problem yesterday. It also fixed after adding that entry to hosts file.
127.0.0.1 host.docker.internal
however, today i restarted the laptop, and problem is happening again. I validated that entry is still in the hosts file.
I confirmed i can ping host.docker.internal from both Windows cmd and wsl ubuntu terminal.
EDIT: I downgraded to version 4.17.1 and it works. The difference is these lines added to the hosts file by Docker Desktop
# Added by Docker Desktop
192.168.100.4 host.docker.internal
192.168.100.4 gateway.docker.internal
# To allow the same kube context to work on the host and the container:
127.0.0.1 kubernetes.docker.internal
# End of section
Hi,
Could you please clarify whether you need to resolve host.docker.internal
from a container only? Or you need to resolve it from the host itself too?
Hi, Could you please clarify whether you need to resolve
host.docker.internal
from a container only? Or you need to resolve it from the host itself too?
Hi, I need it on both sides. We have some microservices that are running in Docker and communicating with each other. If we start one of them through IDE for development the services must reach each other and therefore the services in docker must bei able to reach the one running in IDE and vice versa.
I don't know if it is related, but upgrading for 4.18 broke docker for me. Needed to revert (went back to 4.16 which I remembered it worked).
This was the error message:
=> ERROR [internal] load metadata for docker.io/continuumio/anaconda3:latest 0.0s
------
> [internal] load metadata for docker.io/continuumio/anaconda3:latest:
------
failed to solve with frontend dockerfile.v0: failed to create LLB definition: failed to do request: Head "https://registry-1.docker.io/v2/continuumio/anaconda3/manifests/latest": proxyconnect tcp: dial tcp 192.168.65.7:3128: connect: connection refused
[+] Running 0/1
⠿ test-cashback-spark Error 1.8s
Error response from daemon: Get "https://registry-1.docker.io/v2/": proxyconnect tcp: dial tcp 192.168.65.7:3128: connect: connection refused
Another issue for me: docker run doesn't expose any port if no port mapping is set.
I mean, if you execute this example: docker run --name some-mysql -e MYSQL_ROOT_PASSWORD=my-secret-pw -d mysql
The container is up, but the default port for mysql (3306) is not mapped, so I can't access to that mysql (although the port seems to be busy if the container is up, because I can't map any other service to that port)
If I execute docker run -p 3306:3306 --name some-mysql -e MYSQL_ROOT_PASSWORD=my-secret-pw -d mysql, it works
I need it on both sides. We have some microservices that are running in Docker and communicating with each other. If we start one of them through IDE for development the services must reach each other and therefore the services in docker must bei able to reach the one running in IDE and vice versa.
@ILucasI I don't understand something.
You run an IDE on the host. You run micro services in containers.
Micro services will resolve host.docker.internal
to the host IP and connect into the IDE.
But if the IDE resolves host.docker.internal
it also just gets the host IP, not that of anything in a container.
What do you mean by "vice versa"? What, on your host, needs to resolve host.docker.internal
and why?
I need it on both sides. We have some microservices that are running in Docker and communicating with each other. If we start one of them through IDE for development the services must reach each other and therefore the services in docker must bei able to reach the one running in IDE and vice versa.
@ILucasI I don't understand something.
You run an IDE on the host. You run micro services in containers. Micro services will resolve
host.docker.internal
to the host IP and connect into the IDE. But if the IDE resolveshost.docker.internal
it also just gets the host IP, not that of anything in a container.What do you mean by "vice versa"? What, on your host, needs to resolve
host.docker.internal
and why?
The service running in my IDE needs to resolve host.docker.internal
too. In order to connect to the services running in docker and to preserve the origin.
We have a keycloak server running inside docker which is responsible for authentification. if we want to communicate with a backend service we need a token first. We can get this from KC via localhost
or host.docker.internal
(or every other name that resolves to 127.0.0.1
. KC will write the origin from which it was called into the token and the services will check that issuer
claim too. And that check is the reason why we need host.docker.internal
. If this name dosen't resolve to 127.0.0.1
from both sides this check will fail because issuer in the JWT and the hostname of the issuer don't match.
Thanks all for your explanations. We are looking into it and will try to get those names back into the hosts file in next version.
Closing this issue because a fix has been released in Docker Desktop 4.19.0. See the release notes for more details.
Closing this issue because a fix has been released in Docker Desktop 4.19.0. See the release notes for more details.
It doesn't seem to be fixed properly, in that these entries were 127.0.0.1 and now they all point to the adapter's external address.
Docker Desktop 4.19.0 (106363), the hosts
file is updated only on the part of docker containers.
(the same behavior was 4.14)
Closed issues are locked after 30 days of inactivity. This helps our team focus on active issues.
If you have found a problem that seems similar to this, please open a new issue.
/lifecycle locked
Actual behavior
After the update to 4.18.0 the entry for
127.0.0.1 host.docker.internal
was removed from my hosts file.Expected behavior
The update should not remove this entry.
Information
Steps to reproduce the behavior