4 ms·

I recently learned that moving the compose file around and running commands on it with it in different directories puts things into a bad state. This is because

I recently learned that moving the compose file around and running commands on it with it in different directories puts things into a bad state. This is because it apparently tags images and containers with context on where the compose file was run from. However, you can negate this by always passing in a custom project name with -p.

dugmartin 4y ago
I think it is just the parent directory name plus the service name (at least that is what I've seen at work where we have many docker-compose files with common "app"/"db" service names).
switchbak 4y ago
There's something about that decision that violates my mental model. Feels similar to a referential transparency issue: the state of the system should be the same regardless of the name of the directory something lives in.
- turtlebits 4y ago
  While that may be true, you should never destroy things that are out of your scope.
- Gordonjcp 4y ago
  You can specify a project name, but giving things rigidly-defined names breaks the whole idea of it. Why would you want two different instances of the same project to have the same name?
  - lazide 4y ago
    Who said it’s a different instance?! Renaming a directory structure doesn’t have side effects like this in pretty much any other infra stuff. It’s like nc or curl deciding what Server to connect to based on the current directory name. Whacky.
    - Gordonjcp 4y ago
      That is specifically how it's designed. If you want to create a bunch of identical but differently-named projects, put them in separate directories. Why on earth would you want to have lots of different directories that all point to the same instance? That's simply idiotic.
    - mirekrusin 4y ago
      It's a great convention over configuration decision (that you can overwrite with -p) that trivially gives solution to multi-tenancy problem, similarly you'll run into problems when renaming $HOME to something else; for curl it's more like being surprised that it uses different source ip address and gives different result when called from host in China than in Europe.
    - switchbak 4y ago
      Precisely my point. It's surprising behavior that breaks the mental model of more than a few people I've mentioned it to.
- pbalau 4y ago
  Which is true if you pass -p. The current directory is merely the default.
- lazide 4y ago
  Docker has tons of smells/irritations like this. Overall, it is worth it, but damn is it weird sometimes.
remram 4y ago
It would probably break any bind-mounted volume too, like volumes: - ./data:/use/lib/data I don't know why anyone would expect this to work.
kossae 4y ago
To mitigate this, I usually always require a .env file for docker-compose containing directories with at minimum a `COMPOSE_PROJECT_NAME` envvar to prevent these naming issues. As long as the env file travels with the directory there are no issues.
zmmmmm 4y ago
That's a feature not a bug and it's one of the things I like :-) It means that if I run multiple instances of a compose setup, they are completely isolated from each other because they live in separate namespaces. It's a very handy feature (for example, if I'm working on 3 branches of the code, just check them out in 3 different directories etc). Of course it has the consequence that if you move it around it's going to break things, but that's actually the idea. They should break! Because to compose they are meant to be segregated, and if they interacted it would actually be a bug.

dugmartin 4y ago

I think it is just the parent directory name plus the service name (at least that is what I've seen at work where we have many docker-compose files with common "app"/"db" service names).

switchbak 4y ago

There's something about that decision that violates my mental model. Feels similar to a referential transparency issue: the state of the system should be the same regardless of the name of the directory something lives in.

turtlebits 4y ago
While that may be true, you should never destroy things that are out of your scope.
Gordonjcp 4y ago
You can specify a project name, but giving things rigidly-defined names breaks the whole idea of it. Why would you want two different instances of the same project to have the same name?
- lazide 4y ago
  Who said it’s a different instance?! Renaming a directory structure doesn’t have side effects like this in pretty much any other infra stuff. It’s like nc or curl deciding what Server to connect to based on the current directory name. Whacky.
  - Gordonjcp 4y ago
    That is specifically how it's designed. If you want to create a bunch of identical but differently-named projects, put them in separate directories. Why on earth would you want to have lots of different directories that all point to the same instance? That's simply idiotic.
  - mirekrusin 4y ago
    It's a great convention over configuration decision (that you can overwrite with -p) that trivially gives solution to multi-tenancy problem, similarly you'll run into problems when renaming $HOME to something else; for curl it's more like being surprised that it uses different source ip address and gives different result when called from host in China than in Europe.
  - switchbak 4y ago
    Precisely my point. It's surprising behavior that breaks the mental model of more than a few people I've mentioned it to.
pbalau 4y ago
Which is true if you pass -p. The current directory is merely the default.
lazide 4y ago
Docker has tons of smells/irritations like this. Overall, it is worth it, but damn is it weird sometimes.

remram 4y ago

It would probably break any bind-mounted volume too, like volumes: - ./data:/use/lib/data I don't know why anyone would expect this to work.

kossae 4y ago

To mitigate this, I usually always require a .env file for docker-compose containing directories with at minimum a `COMPOSE_PROJECT_NAME` envvar to prevent these naming issues. As long as the env file travels with the directory there are no issues.

zmmmmm 4y ago

That's a feature not a bug and it's one of the things I like :-) It means that if I run multiple instances of a compose setup, they are completely isolated from each other because they live in separate namespaces. It's a very handy feature (for example, if I'm working on 3 branches of the code, just check them out in 3 different directories etc). Of course it has the consequence that if you move it around it's going to break things, but that's actually the idea. They should break! Because to compose they are meant to be segregated, and if they interacted it would actually be a bug.