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 :
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
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…
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.