Accessing localhost in toolbox from podman container running on host

Context:

I have a web app where:

  • backend and frontend are run as normal processes in a toolbox container, running on localhost:3001 and localhost:3002 respectively
  • supporting services are run with docker compose on the host, running on localhost:3000

These supporting services include an authentication proxy, which is supposed to relay messages between frontend and backend. The proxy expects backend to be available at http://host.docker.internal:3002.

Problem:

My backend can access a database container in localhost:3000 and my frontend can access the auth proxy on localhost:3000 just fine. However, then the proxy cannot access my backend. Relevant log:

api-gateway_1  | [HPM] Error occurred while proxying request localhost:3000/api/user to http://host.docker.internal:3002/ [ECONNREFUSED] (https://nodejs.org/api/errors.html#errors_common_system_errors)

If I run podman --remote exec <gateway pod ID> cat /etc/hosts in the toolbox, I get the following:

127.0.0.1 localhost
::1 localhost
192.168.178.33  host.containers.internal host.docker.internal
10.89.0.41  f7437d887e36 api-gateway_1

So my current hypothesis is that from within the gateway, host.docker.internal would point to localhost on my host, not in my toolbox, where it should point. Don’t know if this is correct though.

Any ideas how to move forward or to diagnose further? I would like to keep running my backend as a normal process inside toolbox, as I need hot reload.

Happy to provide extra context and thankful for any ideas!

Removed silverblue

Added atomic-desktops

Some more information:

Docker Compose creates another network by default, and places the containers in the compose file there.

⬢[evakkuri@toolbox app]$ podman --remote network ls
NETWORK ID    NAME          DRIVER
2f259bab93aa  podman        bridge
5525f464ea68  app_default  bridge

For testing I added a container with curl in the compose file:

...  
  curltest:
    image: 
    stdin_open: true # docker run -i
    tty: true        # docker run -t
...

Then I added a simple net server from Podman quickstart, this command was run on host, not in toolbox:

$ podman run -dt -p 8080:80/tcp docker.io/library/httpd

With this command, running curl from curltest container gets no response from this container. However, if add --network=app_default , then I get a successful response if I run podman --remote exec app_curltest_1 curl http://host.docker.internal:8080.

From both host and toolbox, running curl http://localhost:8080 connect successfully.

Summary: Containers within app_default network seem to only see containers within that same network. However, both host and toolbox see services in that network as well.

What I would need is for containers within app_network to see services running elsewhere.

Your toolbox runs with the network namespace set to be the one from the host, so it has access to everything. You Docker compose’d containers are on their own network so they don’t have access to the localhost of the host. According to How to use host network for docker compose? - Stack Overflow, it is possible to set your Docker compose config for those containers to use the host namespace and thus they should be able to talk to your processes in your toolbox.

@siosm Thanks for the reply! And indeed if I set network_mode: host for the auth proxy, everything works.

I’m just wondering why I did not need that setting when I ran the same thing in vanilla Fedora 40 Workstation. Is this due to differences between normal and atomic versions?

It should have been the same on Workstation if you used the same setup.