compose: Docker Compose can't scale containers with hard-coded name
I’m not entirely sure if this should be considered a bug or a design enhancement, but here’s the scenario:
- You create a
docker-compose.ymlfile in an otherwise empty directory - The contents of the file are below
- You run
docker-compose up -dto launch in the background - You run
docker-compose scale redis=10 - You receive an error message about the container name being already taken
version: '2'
services:
redis:
image: redis:latest
container_name: redis
Now granted, I understand that a hard-coded container name was specified in the docker-compose.yml file, but shouldn’t it still append a unique container number to the end of the container_name property? I guess I’m thinking of container_name being more like container_base_name rather than a singleton value.
Any thoughts?
Cheers, Trevor Sullivan Microsoft MVP: Cloud & Data Center Management https://trevorsullivan.net https://twitter.com/pcgeek86
About this issue
- Original URL
- State: closed
- Created 8 years ago
- Reactions: 8
- Comments: 18
I am new to docker-compose – so I could be on the wrong path … but I was searching for a solution - and I found this issue/3722.
I am running a process (long-running) for many customers … it is hard to distinguish which docker is for which customer.
I see the naming used as a helper. Example: (assuming my docker-compose.yml has the below in it) container_name:“${NAME}”
docker-compose run -e NAME=3M rails
Which would give 3M_1 as a container name
if I do docker-compose -e NAME=3M scale=2
I would get:
3M_1 3M_2
This would make it easier to identify which containers are for which customers (as an example).
Without something like this… you would just see:
rails_1 rails_2 rails_3 etc…
Which – requires some other strategy to find what container is for what company.
BTW – open to other suggestions.
Thx, -John
Adding
container_namewas probably a mistake - it’s antithetical to scaling.I can’t imagine a good reason to want to customise the name prefix of a specific service, while the names of its multiple containers remain out of your control. What does it achieve?
Sorry guys, I can’t agree that this feature is not needed.
There is another issue connected with the container_name. I’m using docker to deploy Spark Standalone on my dev machine and it seems like by some reason Spark doesn’t allow underscores in the executor names. The underscore appears due to the docker naming strategy (so it names the nodes as spark_slave_1 even if the service name was “spark-slave”). Using container_name would be a good workaround but it breaks the ability to scale the service.
So what I would really need for this very case is to control somehow the way how Docker names the containers (i.e. whether the underscores are used, where to put the indices etc).
I would suggest to use project name for this purpose.
Dne st 27. 7. 2016 19:31 uživatel John Sundberg notifications@github.com napsal:
Why don’t we have patterns as a values for container_name and hostname properties? My purpose is to see shorter name in
docker-compose psand to seedocker@human_readable:/...., when I get in to that withexec. For example, I found, that we can run likedocker run -h foo.fee.bar. Then inside, when I callhostnameI seefoo. Withhostname -d->foo.fee, with-fflag ->foo.fee.bar. There are options how to let users use names they like. It is not determined by scaling impossibility, but naming inflexibility instead!