I have a bootloader that starts two docker-compose projects, with a command lines:
docker-compose.sh -p a -f project1.yml up -d
docker-compose.sh -p a -f project2.yml up -d
I am using projects so the bootloader can fallback to a different project if an upgrade fails.
The up command works as expected, brining up all the containers and networks in project1.yml and project2.yml, with the containers' names prefixed with "a_".
However, when I try following command:
docker-compose.sh -p a -f project1.yml down
it brings down all containers and networks in both projects (i.e. all containers prefixed with "a_").
There is no cross-over between project1.yml and project2.yml, each creates unique containers from different images.
I cannot find any documentation regarding the use of a compose file and project in conjunction with the "down" command. Is my usage of the project and compose file correct?
CodePudding user response:
Compose generally believes that, for whichever docker-compose -p
project it's working on, the docker-compose -f
Compose file names every container in the project. Compose doesn't track which file a container comes from, only which project it's associated with, and it can't operate on part of the files in a Compose project the way you show.
The first thing this means is that this sequence actually stops some containers:
# start the containers in project1.yml
docker-compose -p a -f project1.yml up -d
# stop those containers and replace them with different
# containers from project2.yml
docker-compose -p a -f project2.yml up -d
In your last command, the second batch of containers isn't in the current Compose file, which is why Compose cleans them up:
docker-compose -p a -f project2.yml up -d
# delete the containers from project1.yml, plus
# all of the "unknown" containers from project2.yml
docker-compose -p a -f project1.yml down
You can provide multiple docker-compose -f
options, and docker-compose up
will remove containers that it doesn't know about (the "normal" use case for this is deleting containers from a single docker-compose.yml
file). You can combine these for your use case:
# start all the containers in both Compose files
docker-compose -p a -f project1.yml -f project2.yml up -d
# start all the containers in project2.yml
# and stop any container that's not there
# (implicitly, stop the containers from project1.yml)
docker-compose -p a -f project2.yml up -d
Another approach is to treat these as two separate Compose projects, so then docker-compose
operations will act on only one of them. The downside is that this makes it trickier to share details like networks.
docker-compose -p a1 -f project1.yml up -d
docker-compose -p a2 -f project2.yml up -d
docker-compose -p a1 -f project1.yml down
As a general rule, for consistent behavior, you want to pass the same -p
and -f
options to every docker-compose
command, lest Compose unexpectedly deletes containers from under you.