Docker compose does not start container for second environment on host Windows Server 2022

Hi, I am having problem with starting container from second compose.yml and moreover only on docker host with OS Windows Server 2022. I posted this issue on forums.docker.com where there are additional informations on this issue in the comments. They finally referred me to post the problem here on this forum. So I will describe the situation.

I need two same web applications on diferent URL adresses with own databases. So I have created two compose.yml files (compose-env01.yml and compose-env02.yml) for running two environments (env01 and env02). Each environment include two containers (web and mssql DB).

After build compose-env01.yml and compose-env02.yml are the images for web same for env01 and env02. Also images for mssql are the same for env01 and env02:
See Figure 1 below
Differents betweens compose-env01.yml and compose-env02.yml are only in using ports, as you can see:

compose-env01.yml:

version: "3.8"
services:
  web:
    build: ./web-mw
    isolation: 'default'
    hostname: web
    deploy:
      resources:
        limits:
          memory: 8G
    ports:
      - "7001:443"
    environment:
      "#CONFSETTINGS_PORT_MW#": "7001"
      "#CONFSETTINGS_MSSQLSERVERPORT#": "14331"
    depends_on:
      - mssql
  mssql: 
    build: ./database
    isolation: 'default'
    hostname: mssql
    ports:
      - "14011:14331"
    expose:
      - "14331"
    volumes:
      - .\volumes\db:C:\sqlbak
    storage_opt:
      size: '25G'
    environment:
      SA_PASSWORD: "Your_password"
      ACCEPT_EULA: "Y"
      MSSQL_PID: "Developer"
      ChangeMSSQLServerPort: "TRUE"
      MSSQLServerPort: "14331"

compose-env02.yml:

version: "3.8"
services:
  web:
    build: ./web-mw
    isolation: 'default'
    hostname: web
    deploy:
      resources:
        limits:
          memory: 8G
    ports:
      - "7002:443"
    environment:
      "#CONFSETTINGS_PORT_MW#": "7002"
      "#CONFSETTINGS_MSSQLSERVERPORT#": "14332"
    depends_on:
      - mssql
  mssql: 
    build: ./database
    isolation: 'default'
    hostname: mssql
    ports:
      - "14012:14332"
    expose:
      - "14332"
    volumes:
      - .\volumes\db:C:\sqlbak
    storage_opt:
      size: '25G'
    environment:
      SA_PASSWORD: "Your_password"
      ACCEPT_EULA: "Y"
      MSSQL_PID: "Developer"
      ChangeMSSQLServerPort: "TRUE"
      MSSQLServerPort: "14332"

When I run containers from env01 using command “docker compose -p env01 -f compose-env01.yml up -d”, both containers start correctly. Then I want to run containers from env02 using “docker compose -p env02 -f compose-env02.yml up -d”. But now will start only container env02-mssql-1 and container env02-web-1 remains in the state Starting:
See Figure 2 below
And this is the problem! This only happens on docker host with OS Windows Server 2022. The same configuration on docker host with OS Windows Server 2019 is OK and all containers from env01 and env02 start correctly.

I was trying run docker compose up also with parameter “–verbose” and with “debug”: true in daemon.json, but it didn’t give me any further information. When starting containers from compose-env02.yml, the container env02-mssql-1 started correctly and the container env02-web-1 didn’t even start to run and no further informations was displayed. So after that I canceled the start of the containers from compose-env02.yml. The state of containers from both environments was now this:
See Figure 3 below

And now a very interesting information:
Now when I shut down the containers from env01, the container env02-web-1 started Immediately automatically after that, as you can see:
See Figure 4 below
Given that, I think it will be probably some network issue. Interestingly, however, the same configuration works on docker host Windows Server 2019.

Figures:

Using versions are:
Docker host with OS Windows Server 2022
Docker version 24.0.4, build 3713ee1
Docker Compose version v2.20.2

So could you please help me anybody with this problem? Or could it be a bug in docker?

1 Like

I too have this problem.
See also these github issues describing (probably) the same problem: