Support custom container names

[aanand]

Requested in #652 and #1347.

It would be nice to allow users to customise container names, perhaps with a name field:

web:
  image: myimage
  name: webapp

$ docker-compose up -d
$ docker-compose ps
CONTAINER ID        COMMAND             CREATED              STATUS              NAMES
747cb66d30f5        "python app.py"     About a minute ago   Up About a minute   webapp

However, it might not play nicely with docker-compose scale, since names are supposed to be unique.

Some options, keeping in mind that sequential suffixes are probably going away (#1516):

1. Don't allow services with a custom name to be scaled.
2. Automatically append a suffix to the name of each container:

webapp_1a2b3c, webapp_4d5e6f, webapp_7a8b9c

Easy enough, but the feature becomes somewhat less useful at that point.
3. Automatically append a suffix to the name of all but the first container:

webapp, webapp_1a2b3c, webapp_4d5e6f

It works, but it's more complicated. What does the logic for creating/scaling look like now?

[aanm]

@aanand
4. Attaching ## depending the amount of numbers the user would want to see.

web:
  image: myimage
  name: webapp-###

webapp-### would result in "webapp-001", "webapp-002", "webapp-003" and so on.

[aanand]

@aanm keep in mind sequential numbers are problematic (#1516).

If the basic use case is "I want a container with a predictable name", I'm currently leaning toward option 1. I'm not sure what the use case would be for having a predictable name and multiple containers for a service.

[aanm]

I just read #1516 now sorry.
Isn't easier with labels to know the number of containers that are running for a particular service?
Well let's see something. If we're going to scale something we don't really care where they end up. I just want to have, for example, 10 containers running for that foo service, period. If I want to resize to 5, compose will delete 5 of them, doesn't matter which ones since they are suppose to be all equal, right? Therefore I think the 2 option will be the better one but what do you mean by Easy enough, but the feature becomes somewhat less useful at that point.?

[funkyfuture]

@aanm how would that differ from 2. beside the syntactical difference?

atm, a name-property is added upon creation of a service-dict anyway. my guess is that it gets discarded when containers are created.

yep, 1. seems best. why would one not identify scaled services via the labels and implement a parsing of names?!

[aanand]

Therefore I think the 2 option will be the better one but what do you mean by Easy enough, but the feature becomes somewhat less useful at that point.?

Simply that the container name is no longer predictable. The basic use case is this:

I have an external service that needs to interact with one of the containers spun up by Compose. In order to discover the container, I want to give it a specific name that can be accessed from outside my app:

$ docker-compose up -d
$ docker run --link mycustomcontainername:db ...

If the container will always have an unpredictable suffix (mycustomcontainername_1a2b3c), then I can't write a script that relies on it.

[aanm]

@aanand I disagree on using compose and then docker.
You could run compose run --link mycustomcontainername:db let's say mycustomcontainername is the one scaled, you would link every mycustomcontainername to db and you would use services' names instead of containers names, why are compose creating an abstraction (of containers' names to services' names) if we can't use them in our favor? :-)

[iafilatov]

I think it boils down to choosing either name predictability, or scaling. When interacting with scalable containers, how would one even choose, which out of N to interact (e.g. link) with? Those, who want their containers to scale, should allow certain containers to do it by not specifying a custom name. So I'm for option 1 here.

[blop]

How about letting the user choose it's own naming/scaling rules/formula?

[Oliboy50]

This is more the image built name than the container name that I'd really want to customize.

[younes200]

This feature will be usefull also when container's build depends on another, example :

base/Dockerfile

FROM ubuntu:last
...

nodejs/Dockerfile

FROM mydocker/base
...

docker-composer.yml

base:
  name: mydocker/base
  build: ./base
  links :
    - nodejs

nodejs:
   name: mydocker/nodejs
   build: ./nodejs

So the name will be helful to keep link between generated containers.

[mariolameiras]

Are you setting milestone 1.3.0 for this feature ?

[aanand]

@mariolameiras No, 1.3.0 is in code freeze.

[Slind14]

👍 how do you call containers from compose atm if the id is changing all the time?

[davbeck]

👍🏾

[lostsnow]

+1

[luiscarrasco]

+1

[cuva]

+1

[thaJeztah]

If the container will always have an unpredictable suffix (mycustomcontainername_1a2b3c), then I can't write a script that relies on it.

I agree (partly) with @aanm here; docker compose should be able to exist here, either by being able to start, and link, a container or by providing the actual container name. Thinking something like this;

docker run $(docker-compose getname <myservice>):db

When interacting with scalable containers, how would one even choose, which out of N to interact (e.g. link) with?

This is a good / valid point. I think the new networking features (currently experimental); moby/moby#14083 and the related discussions should be taken into account here as well moby/moby#13441 moby/moby#13977 moby/moby#14143

IIUC, plans are to move away from explicitly / hard linking to containers and more towards creating a "network" (i.e. a group of containers / end points that can communicate) and use "discovery" to find a service to connect to.

[aanand]

If you want to get the ids of all containers for a service:

$ docker-compose ps -q db
3fdb97b5f570e6615e9556f897ced90d9ee85c657826001aa9de2888748e0b27
b3dcbf4c9be4822bb675a433e5919d122c321981f0a489c5e157764ff574e262
9e3f80ad7ffd55c8386045411a071242cf6cca5acd018c9e118ca849b6c05993

If there are multiple, and you just want to get one:

$ docker-compose ps -q db | head -1
3fdb97b5f570e6615e9556f897ced90d9ee85c657826001aa9de2888748e0b27

So if you want to link to a Compose container in a docker run, for example:

$ docker-compose up -d db
$ docker run --link $(docker-compose ps -q db | head -1):db ...

[LisBerndt]

@aanm keep in mind sequential numbers are problematic (#1516).

If the basic use case is "I want a container with a predictable name", I'm currently leaning toward option 1. I'm not sure what the use case would be for having a predictable name and multiple containers for a service.

Hello!
Our use case is couple each container to specific external devices (e.g. eval-boards). To automatically configurate which container is coupled to which device it would be very helpful to customize the hostname of the scaled containers dynamically.