Compose: Mixup of compose containers with same service name

[mikehaertl]

I have 2 projects, both live in a directory named app/ and both define a service named web in their docker-compose.yml file:

.
├── a
│   └── app
│       ├── docker-compose.yml
│       └── Dockerfile
└── b
    └── app
        ├── docker-compose.yml
        └── Dockerfile

a/app/docker-compose.yml

version: '2'
services:
    web:
        build: ./
        image: a_image
        container_name: a_container

b/app/docker-compose.yml

version: '2'
services:
    web:
        build: ./
        image: b_image
        container_name: b_container

Now when I start the web service in project a, then go to project b, docker-compose mistakenly operates on the containers for project a:

$ cd a/app
$ docker-compose up -d
Starting a_container
$ docker-compose ps
   Name            Command           State             Ports         
--------------------------------------------------------------------
a_container   apache2-foreground   Restarting   0.0.0.0:9002->80/tcp 

$ cd ../../b/app
$ docker-compose ps
   Name            Command           State             Ports         
--------------------------------------------------------------------
a_container   apache2-foreground   Restarting   0.0.0.0:9002->80/tcp

It works correctly if I change the service name from web to e.g. web_b - but I don't want that. The same setup worked fine with docker-compose 1.7.0. It seems like in only happens after upgrading to 1.8.0. I also see this on multiple machines now.

My docker version is 1.12.1.

[mikehaertl]

Another related thing: When I startup services, it shows a warning which makes no sense. Obviously it mistakenly thinks, that all services that where startet from a directory named app/ belong to the same proejct, which is not the case:

WARNING: Found orphan containers (projx_dev, projy_dev) for this project. If you removed or renamed this service in your compose file, you can run this command with the --remove-orphans flag to clean it up.

Both containers are _not_ orphaned but belong to other projects.

[shin-]

The only way Compose can tell if services are part of the same project is by detecting whether they share the same project name. In your case, the default name applies, which is the name of the folder your compose file is found in, which happens to be app in both cases. I would strongly advise using a custom project name using the COMPOSE_PROJECT_NAME environment variable or the -p option.

[mikehaertl]

Ok, that's what I've done now and it works. I remember now, that I probably had set this before on the projects where it worked.

As discussed in #745 I'd prefer an option to set the project name directly from docker-compose.yml and not having to create another file, though. As you see, it's very easy to forget about that .env file. Instead all relevant configuration should live in one file.

[glensc]

i'm having the same problem and after investigating source code i found that it's called "project" what current directory name is used as default, and also found that there's no config key to setup "project" from .yml file, i'm not in favour of automatically saving it to external file as #745 suggest, but rather directly specify it in docker-compose.yml

mu structure is like:

• qemu/
• qemu/alpha/
• qemu/alpha/chroot/
• qemu/alpha/chroot/Dockerfile
• qemu/alpha/qemu/
• qemu/alpha/qemu/docker-compose.yml
• qemu/alpha/qemu/Dockerfile
  ..
• qemu/ppc/
• qemu/ppc/chroot/
• qemu/ppc/chroot/Dockerfile
• qemu/ppc/qemu/
• qemu/ppc/qemu/docker-compose.yml
• qemu/ppc/qemu/Dockerfile

so i ended up qemu_qemu_1 name for both alpha-qemu and ppc-qemu and didn't even realyze after few days that starting other qemu instance just overwrote the previous architecture :)

while this could be solved by using container_name in each of the service, that would prevent me from using docker-compose scale=4

and i suppose i can't use COMPOSE_PROJECT_NAME in docker-compose.yml, as it's "too late" to read it from there, right? and having COMPOSE_PROJECT_NAME set in shell, totally breaks the flexibility of it, because if i chdir to alpha dir to ppc dir, i must replace it or i'm back to the original problem i am having.

[shin-]

@glensc You can store a different COMPOSE_PROJECT_NAME value in the .env file at the root of each project, or use the -p option.

[glensc]

just .env file, without having to reference it from docker-compose.yml? thanks will try!

[shin-]

Yes - docs here if you need them.

[glensc]

uh, is there reason why - is stripped from project name?

root@silenoz alpha/qemu# cat .env 
COMPOSE_PROJECT_NAME=ac-alpha
root@silenoz alpha/qemu# docker-compose up -d
Creating acalpha_chroot_1
Creating acalpha_rootfs_1

and _ as well, which it itself uses!!!!

root@silenoz alpha/qemu# cat .env 
COMPOSE_PROJECT_NAME=ac_alpha
root@silenoz alpha/qemu# docker-compose up -d
Creating acalpha_rootfs_1
Creating acalpha_chroot_1

[glensc]

the used normalizator: compose/cli/command.py:117-118

i was able to track it down to plum/cli/command.py

so, no actual justification why it is trimmed, but relaxing it can be serious backward compatibility issue. i think the project name can be anything that docker container name can be. even the directory separator would be ok, i.e if specified via commandline or env file, just by default it can't have it

however if #745 gets implemented, then its not that big risk? or just can be done in next big version that llows backward compat break?

[finspin]

I have a similar use case. I'm running multiple instances of the same docker-compose.yml on the same host. All folders where docker-compose.yml is located have the same name so Compose starts the containers with the same name. To solve that problem I'm passing a random value with the -p option but it would be nice if this was natively supported by Compose.

[shin-]

@finspin Is something preventing you from being able to create a .env file at the root of each project?

[finspin]

@shin- In my setup I don't have separate projects. I just have one docker-compose.yml which I'm reusing to launch multiple instances. I pull in the docker-compose.yml from version control to a CI server and launch multiple instances.

[thomasmery]

Hi there,

just to share the same experience here,

just spent too much time (imho) on trying to understand why different compose configurations would step on each other

it's great one can prevent that with COMPOSE_PROJECT_NAME in the .env file but ...

I would say, as it's been said, that it would make more sense to be able to set the compose project name ... in the compose file (or is there a very specific and good reason to not allow this?)

we can already change container's names with container_name in the compose file and I was kind of expecting this to be enough to avoid collisions

from what I understand COMPOSE_PROJECT_NAME has to be set as well (but in a different place - which is why I find it not so convenient)

also I'd say that this info did not seem quite easy to find - the only place I could find it was here : https://docs.docker.com/compose/reference/envvars/#/composeprojectname

and it mainly state that this setting will change the container's names, not that it will prevent configs overlaps, I'm using the container_name option in the compose file for that but it seems like it's not enough to avoid collisions

hope to get more feedback on this issue
thanks

[mikehaertl]

@shin It just happened again: I deployed the same project twice on a server and accidentaly deleted the container for the live site. Issue #745 seems to get forcefully ignored by the docker team. It's so annyoing.

Is there anything we can do to finally fix this? Please, please, please add this one little stupid option to the docker-compose.yml to make the project name configurable there. I can't see, why on earth we have to deal with 2 files instead of having anything related to docker containers in one simple docker-compose.yml.

[shin-]

Let's continue the discussion in #745

[truthadjustr]

after i found out that the current folder name containing my docker-compose.yml file is part of Docker's way of identifying things, I just re-created the same folder name containing my docker-compose.yml, and I can now do docker-compose up.

[chovy]

I'm having this issue sitll 2 years later. I have two instances of the same project and docker-compose.yml looks at a .env file for names. BUt somehow docker mixes the two up.