The second method (shown in the stackoverflow thread) seems to be adding iptable rules, which I’m not sure how to really apply.
The third method (using ‘–network=host’ argument in docker command) works but is not ideal since it’s exposing host’s entire network environment to the container.
I’d appreciate if someone can provide some insights.
It’s usually easier to not work from doc examples, but from something you’re actually trying to accomplish. That’s why I asked for that kind of example rather than just something from the documentation.
What I found is that this is a feature of Docker Desktop, not a feature of Docker CE as installed without the desktop frontend (Docker CE and Docker Desktop are two separate pieces of software; Docker Desktop includes the Docker engine, but Docker CE does not include Docker Desktop).
I initially wanted to use the docker appliance ‘open-webui’, which is a web-ui with added features for the META made GPT ‘Ollama’. I installed ollama that runs as a systemd service at port 11434. The docker appliance open-webui however can’t find the running service.
There’s a setting in the open-webui that lets you tell it where ollama is running, and the address should be http://host.docker.internal:11434. However it still fails to find the running ollama service.
There are several other such docker appliances and they all seem to have this same issue.
I then went on to try docker’s documentation example and it even failed to find the running service on the host’s port too.
There’s actually a workaround that exposes host’s entire network, which uses the --network=host as a docker run argument. It’s just less secure.
To the container’s /etc/hosts file (that seems to be what Docker Desktop does). Replace x.x.x.x with the gateway address used by the docker container (you can find that with the route command inside the container)
Or you can connect to the host system itself using the host’s IP address. I’ve got a few containers that I do that with myself with a reverse proxy program I use.
I went to check /etc/hosts, the “x.x.x.x host.docker.internal” was already there. I believe it’s automatically generated when I issued docker run --add-host=host.docker.internal:host-gateway.
I’ve spent two days on this, so I’m giving up for other solutions.
Thank you nonetheless.
Glad to help out. Something to keep in mind is that regardless of whether you use the host-gateway address or an external address, anything on the host that’s listening on *.*.*.* is going to be visible on that interface - there’s nothing about that configuration that restricts the ports to just the services you want the container to have access to - that has to be configured on a per-service basis or you need to use the firewall zone (docker) to restrict access to specific ports.
@bonedriven took me about 20 minutes to have it up and running on a k3s install on openSUSE Tumbleweed, need to add my nvidia Tesla P4 to this test setup…
Not a regular user of containerization app so I know nothing about kubernetes except that it’s a docker alternative.
Anyway, I think I’m done with these ollama UI apps, which I think will be outdated very soon too.
There will be programs that you can just click ‘install’ and you are good to go. No more docker run this, systemd that.
I might have found the culprit but in the Podman container. I switched to podman and encountered almost the same issue (not finding the service running on the host’s port). Then I accidentally read the logs of podman which said it had problems trying to reach the proxy server (same as in my host’s proxy setting). So I forced the container to run without proxy and the problem was gone.
Somehow, it seems host’s system proxy setting will be brought to the container.
I was also playing with a new toy cockpit, which happened to have a button for showing both the logs and environment of the container.
It’s my new fav tool now.
