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

[mariotomek]

Discussed in https://github.com/docker/compose/discussions/10894

^{Originally posted by mariotomek August 11, 2023} Hi, I am having problem with starting container from second compose.yml and moreover only on docker host with OS Windows Server 2022. 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: 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:

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.

Using versions are: Docker version 24.0.4, build 3713ee1 Docker Compose version v2.20.2

So could you pleas help me anybody with this problem?

[milas]

While env02-web-1 is in "Starting", can you inspect it from another terminal (docker inspect env02-web-1)?

[mariotomek]

Hi @milas, no when the env02-web-1 is in "Starting" state, it is not possible to inspect it because it has not started yet. I tried it many times. I created a topic also on forums.docker.com. There is already more information on this issue. But it looks like it will probably be some kind of bug in docker.

[westy]

Sounds related to #8978 from last year!

[emagiz]

We are also (reproducable) experiencing this issue. As described by the @mariotomek , this occurs when two stacks with port mappings are deployed on the same windows server 2022.

If any workaround of fix is known, we would like to know aswell. AFAIK no fix exists.

[mariotomek]

We are also (reproducable) experiencing this issue. As described by the @mariotomek , this occurs when two stacks with port mappings are deployed on the same windows server 2022.

If any workaround of fix is known, we would like to know aswell. AFAIK no fix exists.

Hi @emagiz, I posted this issue also on forums.docker.com, and here is workaround that work for me: forums.docker.com. Hopefully it will help you!