Obtain docker bridge/compose stack IP (not in router subnet)

[HunterDG]

Operating system

Docker Desktop WSL2 - networkingMode=bridged

Description

Default compose gives windows IP of 20.20.20.21, routed through docker stack 172.* IP

This does not jive with documentation:

“By default, the container uses bridge networking, which shares the IP address with the host.”

(or maybe it does, as the QEMU host does indeed get the bridge IP, but the windows guest does not)

DHCP: “Y” appears to throw “Docker Desktop does not support macvlan” error without actually trying.

How do I allow windows to receive IP from docker stack network?

alternatively, how can I just skip the macvlan nag and carry on?

I have no need to publish ports - using shared namespaces + tailscale

Docker compose

services:
  windows:
    image: dockurr/windows
    container_name: windows
    environment:
      VERSION: "2022"
      USERNAME: "Administrator"
      PASSWORD: "password"
      REMOVE: "N"
      DHCP: "Y"
    device_cgroup_rules:
      - 'c *:* rwm'
    devices:
      - /dev/kvm
      - /dev/vhost-net
    cap_add:
      - NET_ADMIN
    # ports:
    #   - 8006:8006
    #   - 3389:3389/tcp
    #   - 3389:3389/udp
    stop_grace_period: 2m
    # network_mode: "bridge"
    network_mode: service:windows-ts

    volumes:
      - windows:/storage

volumes:
  windows:

Docker log

❯ Starting Windows for Docker v3.11...
❯ For support visit https://github.com/dockur/windows
❯ CPU: 11th Gen Intel Core TM i7 11800H | RAM: 28/32 GB | DISK: 879 GB (ext4) | HOST: 5.15.146.1-microsoft-standard-WSL2...

❯ ERROR: You are using Docker Desktop for Windows which does not support macvlan, please revert to bridge networking!

Screenshots (optional)

No response

[kroese]

You can set:

environment:
  DEBUG: "Y"

and it will carry on after that error.

But I dont understand exactly why you would want that? Because Docker for Windows does not support macvlan so Im pretty sure it will not work, I did not put that check there without reason.

[HunterDG]

perhaps I was confused - I assumed I didn't have any need to create macvlan (I don't care about receiving/setting IP address in router's subnet)

regardless, It appears Windows guest cannot acquire an IP in the Docker bridge's network?

(this is test in Proxmox Docker LXC)

[HunterDG]

I suppose we just need QEMU bridge and/or passthrough/multiple interfaces on the QEMU host and I'll have to manually assign an IP in the docker subnet - yuck

unless you have any creative ideas?

edit - looks like we just need promiscuous QEMU guest macvtap attached to QEMU host bridge (without the macvlan)

[kroese]

The container already uses the Docker IP. Thats why Windows cannot use it, because two machines cannot have the same IP.

On Linux I solved this via macvtap to allow the Windows VM to have seperate IP from the container, but I dont know if its possible to do it without the macvlan (im not a networking expert).

You can see the relevant code here: https://github.com/qemus/qemu-docker/blob/master/src/network.sh and if you see anything that can be improved or changed, I am happy to receive pull-requests.

[HunterDG]

after much experimentation, I was able to resolve "sibling" containers/services (via unqualified/dotless hostname) with an environment variable:

services:
  windows:
    image: dockurr/windows
    environment:
      DNSMASQ_OPTS: " --domain-suffix=composeParentFolderName_default"

I was unable to find a way to dynamically set this based on docker compose working directory :/

[SharkMachine]

after much experimentation, I was able to resolve "sibling" containers/services (via unqualified/dotless hostname) with an environment variable:

services:
  windows:
    image: dockurr/windows
    environment:
      DNSMASQ_OPTS: " --domain-suffix=composeParentFolderName_default"

I was unable to find a way to dynamically set this based on docker compose working directory :/

Thank you for this, this solved the problem I was having. This is definitely something that should be built in if possible.

I was having a hard time finding a way for the windows service to connect to another service that runs the database.