Hacker News Reader

Comment by CincinnatiMan | Hacker News Reader

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.

View on HN

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).

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.

While that may be true, you should never destroy things that are out of your scope.

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?

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.

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.

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.

Precisely my point. It's surprising behavior that breaks the mental model of more than a few people I've mentioned it to.

Which is true if you pass -p. The current directory is merely the default.

Docker has tons of smells/irritations like this. Overall, it is worth it, but damn is it weird sometimes.

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.

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.

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.

Reply on news.ycombinator.com