compose run --name: distinction between service name and container name wrt project name

[Vanuan]

Use case

Run parallel docker compose run commands with an ability for dependent services to discover the "runned" service by its name.

E.g. when I do this:

docker compose run -p instance_1 --name my_service_interactive &
docker compose run -p instance_2 --name my_service_interactive &

I expect 2 sets of all containers (2 networks) to be created, each having a discoverable service name "my_service_interactive".

But instead I get the name "my_service_interactive" is already in use.

Problem

It looks like the --name directive sets both the container name and (internally linked) service name.

What I would want is an option to generate a unique container name, but provide a predefined service name.

It's not clear what is a use case of the --name option: to prevent docker from creating 2 run instances or to provide a predefined discoverable service name. Or both?

[Vanuan]

Related to #1708, #1516, #1630

[Vanuan]

To rephrase, what I'm trying to do is to use run --name in an isolated environment.

The --name option doesn't seem to respect the isolated environment option.

[Vanuan]

Looking up here:

compose/compose/cli/main.py

Lines 1140 to 1156 in c8daf17

	def run_one_off_container(container_options, project, service, options):
	if not options['--no-deps']:
	deps = service.get_dependency_names()
	if deps:
	project.up(
	service_names=deps,
	start_deps=True,
	strategy=ConvergenceStrategy.never,
	rescale=False
	)
	project.initialize()
	container = service.create_container(
	quiet=True,
	one_off=True,
	**container_options)

It looks like the service being run isn't affected by project-name at all. Only its dependencies are affected.

I.e. compose run --project-name isn't truly isolated. I.e. the service being run can't be referenced by "upped" services. The --name option is a sort of a hack which enables service discovery but breaks isolation.

Actually, for my use case (CI environment) I don't need interaction. I only need an ability to wait for a container to go down. So while run sounds to be intended for CI use case it actually isn't such useful because of this --project-name deficiency.

[shin-]

This works as intended. --name sets the name of the container, just as advertised.

[Vanuan]

@shin- It looks like you have ignored most of my messages. --name doesn't simply set the name of the container, it does more than that. When you set name you can resolve that name. I.e. it's equal to the service name. Container name isn't equal to the service name.

It's not the question issue. It's a feature request.

[shin-]

You shouldn't use container names in this fashion. The recommended approach to this would be to use network aliases.

[Vanuan]

Found similar issue: #4052

[Vanuan]

Tried your suggestion. Didn't work:

version: '2'
networks:
    internal:
services:
    slave:
        command: "ash -c 'sleep 1; ping master1'"
        image: busybox
        networks:
            internal:
               aliases:
                 - slave1
    master:
        command: "ping slave1"
        depends_on:
            - slave
        image: busybox
        networks:
            internal:
               aliases:
                 - master1

$ docker-compose run --rm  master 
ping: bad address 'slave1'

[shin-]

In your example,there's no guarantee slave will be responsive by the time you're trying to ping it, either because it hasn't joined the network yet or because it's already stopped. Here's a better (not perfect) example that works:

version: '2'
networks:
    internal:
services:
    slave:
        command: "sleep 999"
        image: busybox
        networks:
            internal:
               aliases:
                 - slave1
    master:
        command: sh -c "sleep 1; ping slave1"
        depends_on:
            - slave
        image: busybox
        networks:
            internal:
               aliases:
                 - master1

$ docker-compose down
Removing repro5147_slave_1      ... done
Removing network repro5147_internal
(compose)joffrey@yuna:~/work/tests/compose/repro5147$ docker-compose run master
Creating network "repro5147_internal" with the default driver
Creating repro5147_slave_1 ... 
Creating repro5147_slave_1 ... done
PING slave1 (172.27.0.2): 56 data bytes
64 bytes from 172.27.0.2: seq=0 ttl=64 time=0.092 ms
64 bytes from 172.27.0.2: seq=1 ttl=64 time=0.078 ms
64 bytes from 172.27.0.2: seq=2 ttl=64 time=0.126 ms
64 bytes from 172.27.0.2: seq=3 ttl=64 time=0.074 ms
[...]
^C
--- slave1 ping statistics ---
16 packets transmitted, 16 packets received, 0% packet loss
round-trip min/avg/max = 0.064/0.093/0.189 ms

[Vanuan]

Looks to be working. Thanks!
I suppose "--name" needs a suggestion to use aliases.
Still strange why specifying name would result in being able to resolve a domain name if its sole purpose is to specify a container name. A side effect?

[Vanuan]

E.g.:

version: '2'
networks:
    internal:
services:
    slave:
        command: sh -c "sleep 1; ping master_name"
        image: busybox
        networks:
            internal:
               aliases:
                 - slave1
    master:
        command: sh -c "sleep 1; ping slave1"
        depends_on:
            - slave
        image: busybox
        networks:
            internal:
               aliases:
                 - master1

docker-compose run --name master_name master
docker logs project_slave_1
PING master_name (172.29.0.3): 56 data bytes
64 bytes from 172.29.0.3: seq=0 ttl=64 time=0.217 ms

[shin-]

It's behavior carried over from before custom networks were a thing in Docker. I'm sure there's cases where it's still useful, but in your case it's obviously a problem since you can't have 2 containers with the same name.

[Vanuan]

Ah, a legacy feature.
I suppose my issue is resolved. Even though I ended up using this workaround:

  $COMPOSE up --build -d $SERVICE
  $COMPOSE logs -f $SERVICE &
  sleep 5
  while [[ `$COMPOSE ps -q $SERVICE` = *[$' \t\n']* ]]; do
    sleep 1;
  done