Specify project and service with container labels

[bfirsh]

Labels are likely going to land in Docker 1.6: moby/moby#9882

If we used these to specify what project and service a container is part of, a whole load of stuff becomes a lot simpler. We don't have to do gross things like project, service, n = container_name.split("_", 3).

Questions:

• Do we still want to give containers names? It's useful to be able to reference containers like that (docker exec project_web_1) and we want something useful to show up in docker ps
• Do we still want to give containers integer references of some kind? It's pretty handy to be able to have a human readable reference to a container

[thaJeztah]

👍 :)

Do we still want to give containers names?

Why not? I'd say, keep the convention to name containers that are managed by compose. However, there are various feature-requests to be able to override the name, e.g. by allowing a name: com.my-container.app in docker-compose.yml

Do we still want to give containers integer references of some kind

I think that's still needed if scaling is possible. ie, you can use a (custom)name for a container, but a second instance should still have a unique name (suffix). This should also be stored in a label, though, to allow filtering.

[dnephin]

I'd say, keep the convention to name containers that are managed by compose. However, there are various feature-requests to be able to override the name,

+1. The names are still nice to have, but being able to customize them is good too

[montells]

+1 Names are usefull to me.

[zkanda]

Please keep the names... 👍

[thaJeztah]

Happy to inform that support for labels (moby/moby#9882) was merged and will be included in the upcoming 1.6 release of Docker.

Also, I think there are currently a number of related issues in this area (#652, #869, #941 among others); perhaps the discussion should be focussed in this issue (but that's just a suggestion) :)

[bfirsh]

Ahhwwww yeah.