Docker Community Forums

Share and learn in the Docker community.

Cant start more than one docker-compose containers

Hello,
Im trying to use docker to containerize an asp.net web application and its database. When I run docker-compose for the first time (using the command ‘docker-compose -p app1 up -d’), everything works fine.
When I try to execute another docker-compose (docker-compose -p app2 up -d) at the same time, in order to create a second instance of my web app and its database, the containers wont start. The problem seems to be related to the system resources and more specifically windows 10 virtualisation resource limitations. I tried switching between wsl2 and hyper-v backend. In wsl2 only one docker-compose will run and the second will always fail (no error, the containers just wont start). Using hyper-v backend more than one docker-compose may start, but not always.
I am using Docker Desktop 4.0.0 Windows Containers, on Windows 10 Pro 19041.1165 (16gb ram - i7). Each db container consumes about 0.7-0.8 GB of RAM while each web app container consumes 0.8-1 GB or RAM.
The docker-compose i use looks like this :

version: "3.8"
services:
    web:
        build: .
        ports:
            - "1003:80"
        depends_on:
            - db
        volumes:
            - "C:\\web-app1:C:\\web-app"
            - "C:\\backups1:C:\\backups:rw"
    db:
        image: "octopusdeploy/mssql-server-windows-express"
        environment:
            SA_PASSWORD: "Password_01"
            ACCEPT_EULA: "Y"
        ports:
            - "1004:1433"
        volumes: 
            - "C:\\testDBs1:C:\\dockerdbdata:rw" 
            - "C:\\backups1:C:\\backups:rw"

The Dockerfile used in order to setup the web app container looks like this :

FROM mcr.microsoft.com/dotnet/framework/aspnet:4.8-windowsservercore-ltsc2016
SHELL ["powershell"] 
RUN Remove-Website -Name 'Default Web Site'; \ 
New-Website -Name 'web-app' -PhysicalPath 'C:\web-app' -Port 80 -Force 
EXPOSE 80 
RUN Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters' \ 
-Name ServerPriorityTimeLimit -Value 0 -Type DWord 

Without an actual error message we’re quite in the dark here. What does Docker tell you?

Are you also trying to use the same ports for that? That won’t work. Compose is not doing some magic load balancing for you.

There is no error.
docker compose prints
creating container db …
and nothing else happens.
Sometimes, db container starts but not the web container.

In each docker-compose instance i change the ports and volumes to be unique.

thank you for your reply

In each docker-compose instance i change the ports and volumes to be unique.

Do you have multiple compose files, or do you manipulate compose file after first up command or do you try to manipulate second container networking after you have both up?

Do you see container running after second up command if you open another terminal and inspect container?

I manipulate the docker-compose.yml after each run. I change ports and volumes.
The container doesnt start at all, i cant see it in docker ps.
Is there any windows resource limitation that blocks additional containers from running ?

By default, a container has no resource constraints and can use as much of a given resource as the host’s kernel scheduler allows.

Below is linuxhint tutorial how you can adjust memory limits and reservation, maybe try that… Also you could try to duplicate “web” and “db” container in compose file so you have to run it only one time, so you don’t get typos or anything.

I already tried to use those limitations (only mem limit and not reservation as it is not supported by windows containers), but still the second docker-compose container set wont start.
I cant declare all the containers in the same docker-compose, as I need each instance of my web-application to be totally isolated.
Thank you for your replies

Ok… Try to dig in some docker log files maybe there is something that pops up. As avbentem said it is hard to know without any messages.

If you run compose up then stop first containers then run the second modified compose file does it work then?

.

Yes it works if I stop the first container set.
where can I find helpful logs ? panic.log is empty

You could try to compose up both apps with ‘–verbose’ flag and set log level to ‘–log-level DEBUG’. Hopefully there comes something relevant…

i will try that
thank you very much

after using the --verbose command i noticed that while the first container runs all the commands fast, the second docker container stops to this command :
compose.cli.verbose_proxy.proxy_callable: docker inspect_container ( id of the db container )
or it keeps showing
compose.parallel.feed_queue: Pending: set()
And just keeps hanging there.
Docker inspect works normally to existing containers.
Any suggestions ?

Since both can run seperately i have no other idea but some networking issue. The following is from docker networking documentation.

All containers without a --network specified, are attached to the default bridge network. This can be a risk, as unrelated stacks/services/containers are then able to communicate.

What happens if you change the other compose file service names…

services:
    web1: # <---------------------------- Like so
        build: .
        ports:
            - "1003:80"
        depends_on:
            - db
        volumes:
            - "C:\\web-app1:C:\\web-app"
            - "C:\\backups1:C:\\backups:rw"
    db1: # <---------------------------- Like so
        image: "octopusdeploy/mssql-server-windows-express"
        environment:
            SA_PASSWORD: "Password_01"
            ACCEPT_EULA: "Y"
        ports:
            - "1004:1433"
        volumes: 
            - "C:\\testDBs1:C:\\dockerdbdata:rw" 
            - "C:\\backups1:C:\\backups:rw"

Other even better option (in my opinion) would be to create user defined networks to ensure containers work in isolation and do not mix with each other.

version: "3.8"
services:
    web:
        build: .
        ports:
            - "1003:80"
        depends_on:
            - db
        volumes:
            - "C:\\web-app1:C:\\web-app"
            - "C:\\backups1:C:\\backups:rw"
        networks:
            - webapp1 # <--------- change this name in another compose file something else like webapp2
    db:
        image: "octopusdeploy/mssql-server-windows-express"
        environment:
            SA_PASSWORD: "Password_01"
            ACCEPT_EULA: "Y"
        ports:
            - "1004:1433"
        volumes: 
            - "C:\\testDBs1:C:\\dockerdbdata:rw" 
            - "C:\\backups1:C:\\backups:rw"
        networks:
            - webapp1 # <--------- change this name in another compose file something else like webapp2
networks:
  webapp1: # <--------- change this name in another compose file something else like webapp2

EDIT:
Syntax migth not be correct on those snippets:grinning:

Your syntax was correct, but still nothing (i tried both options at the same time). I even tried to run this to another computer but the result was the same. The only thing that helped my case was switching from wsl2 backend to hyper-v, but even then I only managed to run two docker-compose container sets at the same time once.
The docker-compose seems to hang on the docker inspect command of the newly created container or to the Pending: set() as mentioned above
Anyways,
thank you @linre90 very much for your help so far

I just skimmed thru the posts and I have a hunch what might cause your problems:

You can not run multiple seperate instances from the same compose file beeing in the same folder without specifiying the --project-name option. By default the project name is the folder name where the docker-compose.yml is located. Without the project name, you simply change the configuration of the existing containers and force docker-compose to redeploy the containers with an updated configuration, instead of creating an independend additional set of containers.

Never mind, just saw in you first post that you did use -p, which is a short handle for --project-name

This is only true for containers created with docker run. By default a compose deployment will create a default “user defined” bridge network.

As long as the option --project-name is used, the host ports of the mappings and the host side of the volume mounts are changed between deployments, there shouldn’t be a problem that prevents the compose stacks to work seperatly.

Good to know!

Hopefully there comes some answer from someone at some point. There is few threads about behavior like this on the internet…

I hope that too. There is almost nothing related on the internet
Thank you @meyay and @linre90 for your assistance.