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.

[aanm]

@bfirsh I want to start working around this, can I start PR stuff?

[dnephin]

I'm going to take a first pass at this to use labels instead of the naming convention to identify containers.

[aanm]

@dnephin
Take a look at #1269

[dnephin]

@aanm right, #1269 is not quite the same thing. This ticket is about using labels internally in compose to specify the project/service/etc that a container belongs to. #1269 is about supporting user-specified labels through the compose config.

I've made sure that my changes are compatible with that branch, I don't think there is any overlap.

[thaJeztah]

@dnephin when implementing, I think it would be good to namespace the labels used by compose internally, to prevent them from conflicting with user-defined labels, e.g. com.docker.compose.project=myproject, com.docker.compose.service=web, com.docker.compose.instance=1. Might have to decide on the namespace used, to be consistent with other projects, like swarm and/or machine if they decide to use namespaces as well.

[dnephin]

@thaJeztah master...dnephin:use_labels_instead_of_names

I agree :)

[thaJeztah]

@dnephin 👍 great!

[aanm]

@thaJeztah
What is the purpose of com.docker.compose.instance?

[thaJeztah]

@aanm if a service was "scaled", e.g scale web to 3, to distinguish each instance of the web container (1..3)

[ahmetb]

@thaJeztah in a correctly designed distributed system, no part needs to know its number. :)

[thaJeztah]

@ahmetalpbalkan true, and for the container itself, this will be true as well if labels are used instead of environment-variables.

I can imagine, however, that the instance-number can be useful when enumerating or addressing the containers of a service and/or scaling down? (i.e. "Stop and purge all containers having instance > new scale")