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.

[ppriorfl]

Was sent here regarding possible fix to my issue - not sure if it is the same or not. I cannot access shares on my host LAN when running this project. My windows machine assigned in the 20.20.20.1 subnet as noted above - I can't see it from my network and I can't see network shares from the windows VM. Didn't see any mention on the main page about this and it seems a common function that would be desired. Is the sibling fix above relevant to my issue or am I hunting the wrong tree here. Thank you.

[HunterDG]

First try ip address

If that works, try \\hostname. (yes that's a period at the end) or \\hostname.lan - assuming your router hands out .lan DNS search domain

If that works and you want to access shares without the .lan (or whatever) suffix, then try

--domain-suffix=lan instead of above

[Liquidmasl]

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 :/

is this the only change you made? or additionally to the stuff you pasted in the original question? I am currently trying to access other services in the same compose stack and fail to resolve the service names

also, maybe this is a stupid question, but for me to replicate this it has to look the same? composeParentFolderName_default or do i have to fill something else in there?

[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 :/

is this the only change you made? or additionally to the stuff you pasted in the original question?

I am currently trying to access other services in the same compose stack and fail to resolve the service names

also, maybe this is a stupid question, but for me to replicate this it has to look the same? composeParentFolderName_default or do i have to fill something else in there?

Yes, believe it was only change.

No, must modify it to match your compose parent folder (not a variable)

[GeTOUO]

hello @HunterDG , May I ask, how do I determine the value of 'composePostFolderName_default'?

[HunterDG]

hello @HunterDG , May I ask, how do I determine the value of 'composePostFolderName_default'?

It's the name of the folder your docker-compose file is in (and append "_default")

When using docker-compose, docker creates a compose-stack specific bridge network based on the name of the parent folder.

[GeTOUO]

你好，请问，我该如何确定 'composePostFolderName_default' 的值呢？

它是您的 docker-compose 文件所在的文件夹的名称（并附加 “_default”）

使用 docker-compose 时，docker 会根据父文件夹的名称创建特定于 compose-stack 的桥接网络。

Thank you very much, I understand what you mean. I am planning to use this method to establish domain access between two Windows containers. I just tried it briefly and there were still some issues. Tomorrow, I plan to merge two Windows into one compose file and try again

[GeTOUO]

I have adjusted my script and am currently testing it

services:
  ad_server:
    image: dockurr/windows
    container_name: ad_server_2022
    environment:
      DNSMASQ_OPTS: " --domain-suffix=office_online_default"
      DHCP: "Y"
      VERSION: "2022"
      LANGUAGE: "Chinese"
    devices:
      - /dev/kvm
      - /dev/vhost-net
    device_cgroup_rules:
      - 'c *:* rwm'
    cap_add:
      - NET_ADMIN
    ports:
      # - 53:53/tcp
      # - 53:53/udp
      # - 389:389/tcp
      # - 636:636/tcp
      # - 3268:3268/tcp
      # - 3269:3269/tcp
      - 18006:8006
      - 13389:3389/tcp
      - 13389:3389/udp
    stop_grace_period: 2m
    volumes:
      - ./ad_data:/storage

  office_server:
    image: dockurr/windows
    container_name: office_server_2022
    environment:
      DNSMASQ_OPTS: " --domain-suffix=office_online_default"
      DHCP: "Y"
      VERSION: "2022"
      LANGUAGE: "Chinese"
    devices:
      - /dev/kvm
      - /dev/vhost-net
    device_cgroup_rules:
      - 'c *:* rwm'
    cap_add:
      - NET_ADMIN
    ports:
      - 28006:8006
      - 23389:3389/tcp
      - 23389:3389/udp
    stop_grace_period: 2m
    volumes:
      - ./office_data:/storage

[kroese]

@HunterDG @GeTOUO @SharkMachine

I just discovered that you can reach the other containers in the same network by using containername.networkname instead of just containername. This removes the need for --domain-suffix (and you don't need to know the compose folder anymore).

[simonmeggle]

I just discovered that you can reach the other containers in the same network by using containername.networkname instead of just containername. This removes the need for --domain-suffix (and you don't need to know the compose folder anymore).

Thanks @kroese this worked for me as well! 👍