Compose: docker-compose run ignores the container_name directive

[aciobanu]

See #1753 reported by @dunk and @aanand 's PR https://github.com/docker/compose/pull/1755 for more details.

In the #1753 issue reported, @dunk executed:

docker-compose up
docker-compose run myservice

PR #1930 adds a --name param to docker-compose allowing for one off executions with a custom name

Since a container with a fixed name is already running, the behavior of docker-compose run should be no different than that of docker-compose scale, which is basically the same thing as running docker run --name $some_name_that_already_exists.

Now, when running docker-compose up, the container_name directive is respected; when running docker-compose run myservice, the container_name directive is ignored and the default auto-generated container name is used.

$ docker-compose --version
docker-compose version: 1.4.0

[dnephin]

Since a container with a fixed name is already running, the behavior of docker-compose run should be no different than that of docker-compose scale

This is not the expected behaviour. Are there docs that suggest this? If there are we need to fix them.

What you're describing is expected with #1755. docker-compose run --name can be used to give it a different custom name, but names are still unique, and docker-compose will not attempt to munge a custom name.

Maybe we need to make this more clear in the docs for container_name ?

[aciobanu]

Let's take the following example of docker-compose.yml:

service:
  image: repo/service:latest
  environment:
    - SOMETHING=true
  links:
    - dependency

dependency:
  image: repo/dependency:latest

If I run docker-compose run service, I would get both dependency and service containers, and on the service container I would get an env var SOMETHING=true. If I would add more things there, like volumes, command etc. I would see those on the containers as well. In other words, docker-compose run takes into consideration _all_ the directives from the yml file (as far as I know anyway). Having _only_ container_name ignored seems inconsistent and un-obvious.

The documentation for _container_name_ emphasizes that there are some limitations when using it, like scaling not working; I would suggest adding to the documentation the fact that docker-compose run is also affected and for docker-compose run there's this workaround of using the --name param.

[dnephin]

Having only container_name ignored seems inconsistent and un-obvious.

http://docs.docker.com/compose/reference/run/

ports is another case where they differ, and we call it out in the docs. We should improve the docs in both of those places.

[aciobanu]

Totally agree regarding the documentation; the behavior of docker-compose run is not obvious regarding container_name.

As a side note, maybe having _all_ directives from the yml file being executed and implement a --no-directive param, like --no-ports, --no-container-name or the already existing --no-deps, allowing the users to disable them would be a more consistent and predictable behavior, although that would mean that run won't provide sensible defaults so the users will have to do more work to just run a container.

BTW, running without --service-ports applies only for the container that's run, not also for its dependencies but that's probably for another discussion.

[starkovv]

+1

[aventurella]

+1

ah.. looks like this will be in 1.5
https://github.com/docker/compose/pull/1930

[hadim]

Same issue here.

docker-compose run --name ... works well.

[bastienvinh]

I have the same issue.

Docker-compose up is working well, but docker-compose run doesn't

[stkiss]

+1

[geissdoerfer]

+1

[smalot]

+1
no news ?

[DavidBruant]

I came across this issue with docker-compose version 1.6.2, build 4d72027

[caiofbpa]

What if the conflict is on a dependency?

I have a mysql server:

mysql:
  image: mysql
  container_name: shared_mysql

I run it with

docker-compose up -d mysql

When I run a test container that links to mysql I get this:

ERROR: Conflict. The name "/shared_mysql" is already in use by container <container_id>. You have to remove (or rename) that container to be able to reuse that name.

I wanted the run command to link to the existing shared_mysql container, not start a new one. Compose works the way I expected when there's no container_name specified. I reckon the only command that should fail when container_name is set would be scale, not run.

Is this a separate issue? I might be misinterpreting the purpose of container_name.

[galan]

Using docker-compose version 1.7.1, build 0a9ab35 on linux x64 and still having the problem.
Using docker-compose run myservice does not obey the container_name directive, thu docker-compose up does. This is an important use-case for us, any progress on this?

[galan]

It seems that hostname has the same problem when using run. So none of my services can find the depending services, since the hostname discovery is broken.

[aanand]

@galan What's your use case? Why do you need to use run and not up?

[galan]

@aanand Starting all services might not be the desired goal if you only need two out of fifty services on a local development machine.

[aciobanu]

@galan you can run docker-compose up service1 service2; it will start service1 and service2 plus their dependencies. You can pass --no-deps if you don't want the dependencies started; docker-compose help up for a few more options.

This does solve most of the actual use cases for run, but I still think that run's behavior is inconsistent and counter-intuitive.

[galan]

@aciobanu Thanks, that seems to be helpful for my case. One drawback is that I can not assign a unique name to the container being started (like --name in run)

[aanand]

@galan That's exactly what the container_name option is for - does it not work when you use up?

[galan]

@aanand You're totally right, I forgot where I started :smiley:

[queeno]

I've just bumped into this issue. Is there any fix for it yet?

[igorescobar]

Same here.

[NdubisiOnuora]

@dnephin, @aanand: any updates on this issue?

[TheNavigat]

Bumped into this as well

[PavloBasiuk]

Also facing this :(
Any workarounds?

[PavloBasiuk]

Solution that worked for me: https://stackoverflow.com/questions/29924843/how-do-i-set-hostname-in-docker-compose

Solution:

docker-compose run --name alias1 some-service

Then you can ping alias1 from other containers.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale[bot]]

This issue has been automatically closed because it had not recent activity during the stale period.