Networking Bug in Beta 34 of Docker for Windows

Docker Desktop for Windows
1

I just upgraded from beta 32 to beta 34 of Docker for Windows. I am using Windows containers.

Something that was working in beta 32 is no longer working in beta 34. I am using docker-compose to create and run a SQL Server container. I want a static address for SQL Server, so I defined this static address in the networks section of the service.

Below is the docker-compose.yml file.

version: '2.1'
services:
  sqlserver:
    image: microsoft/mssql-server-windows-express
    container_name: sqlserver
    ports:
      ["1433:1433"]
    volumes:
      - c:\Databases:c:\Databases
    environment:
      sa_password: P@ssW0rd
      accept_eula: Y
      attach_dbs: "[{'dbName':'trunk','dbFiles':['c:\\\\Databases\\\\trunk.mdf','c:\\\\Databases\\\\trunk_Log.ldf']}]"
    networks:
      default:
        ipv4_address: 192.168.128.10
        aliases:
          - qsql
networks:
  default:
    external:
      name: nat

When I execute “docker-compose run”, I get the following error:

ERROR: for sqlserver {“message”:“User specified IP address is supported only when connecting to networks with user configured subnets”}

Changing the network section to include a subnet produces an “unspecified error” when performing a docker-compose run. The changed yml file now has this:

networks:
  default:
    driver: nat
    ipam:
      config:
        - subnet: 172.25.0.0/16

Could you please help? Everything was working fine until beta 34.

Thanks
-marc

2

Hello … any chance that someone at Microsoft or Docker has looked at this issue?

3

Can’t you just use an IP that’s in the default nat subnet? I just tried, and it worked fine:

version: '2.1'
services:
  sqlserver:
    image: microsoft/mssql-server-windows-express
    container_name: sqlserver
    ports:
      ["1433:1433"]
    environment:
      sa_password: P@ssW0rd
      accept_eula: Y
    networks:
      default:
        ipv4_address: 172.20.130.1
        aliases:
          - qsql
networks:
  default:
    external:
      name: nat

If that doesn’t work for you, you should look into creating a different network. See this article: https://docs.microsoft.com/en-us/virtualization/windowscontainers/manage-containers/container-networking#network-creation

4

Thanks, Michael. The following seems to work for me:

sqlserver:
image: microsoft/mssql-server-windows-express
container_name: sqlserver
ports:
[“1433:1433”]
volumes:
- c:\Databases:c:\Databases
environment:
sa_password: P@ssW0rd
accept_eula: Y
attach_dbs: "[{‘dbName’:‘trunk’,‘dbFiles’:[‘c:\\Databases\\trunk.mdf’,‘c:\\Databases\\trunk_Log.ldf’]}]"
networks:
QNatNetwork:
ipv4_address: 192.168.128.10
aliases:
- qsql

networks:
QNatNetwork:
driver: nat
ipam:
config:
- subnet: 192.168.128.0/24
gateway: 192.168.128.1

QNatNetwork:
external:
name: docker_QNatNetwork

Also, how accurate is the on-line documentation for the Windows version of Docker? I cannot seem to find a network named “bridge” or “l2bridge” on my installation, even though the online docs say that it should be there.

5

You should open an issue here to get clarification: GitHub - MicrosoftDocs/Virtualization-Documentation: Place to store our documentation, code samples, etc for public consumption.

Ping @JMesser81

6

@magmasystems

(Assuming you’re talking about this docs page)

So the docs that you’re referencing talk about the “bridge” network, which on Windows corresponds to the default NAT network. By default, docker should create a ‘nat’ network that you should see when you run ‘docker network ls.’ With that said, the “bridge:none” option that the docs are referring to is the option that you can use (by editing your Docker config daemon.json file) to stop the default NAT network from being created.

The L2Bridge network is something different again. It’s a network mode that is only available if you’re using Windows Server, and it isn’t created by default.

Does that answer your question? If not, can you clarify with more details on whether or not you’re using Windows Client or Windows Server and what problem you’re trying to solve?

7

Thanks, it does answer my question. I think that the documents should be as current as possible, and also outline any differences between what is supported on Windows Server 2016 and Windows 10 (which I am currently using). It might also help to provide any notes about potential transitions between the two platform (ie: "This is the way it is done on Windows 10, we know it’s different for now, but it will be transitioning to the way things are done on Windows server 2016).

From personal experience, I know that documentation is usually the last thing to get updated when you are working with a moving target, so I appreciate the direct responses that we all get on this forum.

8

I’m glad that helped, and thanks for the feedback. Suggestions on how we can improve our docs are always welcome–I’ll keep yours on my radar :slight_smile: