access host network

General
1

I am using a nginx proxy for access into other containers accessed via the container name. This works fine.

One of the containers that nginx forwards to is in the host network. I used to be able to access that one via 172.17.0.1. This no longer works. E.g.

ping 172.17.0.1

fails. On devices running an older OS, this works.

How can I proxy to a container in the host network?

docker-compose.yml:

services:

    # proxy
    nginx:
        build: ./core/nginx
        restart: unless-stopped
        privileged: true
        labels:
            io.balena.features.supervisor-api: 1
        ports:
            - 80:80
            - 443:443

    # container in host network - no access from proxy
    micropython:
        build: ./core/micropython
        restart: unless-stopped
        privileged: true
        network_mode: host
        labels:
            io.balena.features.dbus: 1
            io.balena.features.supervisor-api: 1
        environment:
            - DBUS_SYSTEM_BUS_ADDRESS=unix:path=/host/run/dbus/system_bus_socket
        expose:
            - 8888

    # container not in host network, access via name (code-server)
    code-server:
        build: ./core/code-server
        restart: unless-stopped
        privileged: true
        expose:
            - 8443

How can I access service micropython from service nginx?

2

Hi ttmetro,
You might want to check Balena Services Masterclass - Balena Documentation for setting up multi service networking. Also you might want to try proxy pass to set up forwarding for nginx (NGINX Reverse Proxy | NGINX Plus).

3

Hi Ja-Ilija,

As far as I understand, service micropython must use network_mode: host to access bluetooth. All other services including nginx run in the default Docker bridge.

The problem is that nginx can no longer proxy traffic to micropython.

proxy_pass              http://172.17.0.1:8888;

used to, but now no longer works.

Is there a workaround, or perhaps network_mode: host is (no longer) required for bluetooth?

Thanks,
Bernhard

8

Hi there,

From what you have described, it seems like in the past, you were able to access the micropython service port 8888 from inside a bridge networking service by accessing the docker engine host at 172.17.0.1. The 172.x.x.x addresses are given to the services on the docker bridge network, with the host being at .0.1, and as micropython was in host networking, that means that it’s also accessible at the same ip - which is why I think this worked in the first place.

To try and get it to work again, I think its worth checking that 172.17.x.x is still the range of address being used for the bridge networked services on your device. I’ve just checked one of mine, and 172.19.0.xis being used – meaning to access the host from a service on the bridge network I would have to talk to 172.19.0.1. To find out, run balena ps on the hostOS of your device, to get the container ID of the nginx service, and then do balena inspect <CONTAINER_ID> | grep IP to find the IP address given to that container - it should be 172.x.x.x – From that you should be able to infer what ip addresses are being used for the bridge network, and then what the hosts ip will be - it might not be 172.17.0.1!

However it doesn’t feel like the right solutions overall, mixing the bridge and host networking like that, especially if that ip address isn’t the same every time. I’ll check to see if/why host mode networking is required for bluetooth, as having micropython be in bridge networking mode as well if possible is the much neater solution imo and avoids all of these networking problems.

11

Hi Rcooke,

You are right on - the address of the host network apparently changed to 172.19.0.1.

I agree that running “MicroPython” in the bridge net would make more safe. Have you found out how to access Bluetooth in that case?

Separately, it would also make sense if there was a “standard” and reliable way to access the host network from services, rather then using IP addresses which can change.

12

you may want to try the device url. in this way you kind of insure that it won’t change. If you don’t want to make the device visible you may use the api to get the api and dynamically set it up Interacting with the balena Supervisor - Balena Documentation.

13

This forum thread may be helpful too: Default bridge IP for Intel NUC is missing - #5 by Maggie

14

Hi, following up on this, did the solution suggested in the forum post provided by my colleague above worked for your use case? This was to extract the ip address with:

ip route | awk '/br-/ { print $7 }' | head -n 1
17

This works - with a slight modification:

ip route | awk '{print $3}' | head -n 1

Output from ip route - perhaps this differs from system to system?

default via 172.19.0.1 dev eth0 
10.114.104.0/25 dev eth1 scope link  src 10.114.104.3 
172.19.0.0/16 dev eth0 scope link  src 172.19.0.8