deploy replicas gives duplicate container name errors

[dustyroberts]

It would be great if support for replicas was added.

deploy:
  replicas: 10

See https://stackoverflow.com/questions/73691746/docker-replicas-while-debugging-with-visual-studio-not-working-as-expected

[dbreshears]

Thanks @dustyroberts, we have added this to the backlog to investigate but likely won't get to it right away

[dbreshears]

@dustyroberts. While we don't have an F5 debug solution for this yet, you should be able to debug multiple replicas by using the Container Tools Window in Visual Studio and attaching to each of the containers individually after you compose up. Visual Studio 2022 17.4 Preview 3 release now also has Docker Compose commands off of the Compose project context menu to make it easier to "Compose Up" the services.

[dustyroberts]

@dbreshears Yes, and one workaround is to have two entries for the application in the compose file and specifying different container names for each.

Having it in the backlog is great, cause it would be nice to scale the same way docker does.

Thanks

[h3ct0rjs]

Hey Guys, I'm currently doing a few tests and labs with haproxy, and in order to run my test I need to create multiple replicas with specific names per container, What I have in code is something like :

services : 
  web:
      image: jmalloc/echo-server:latest
      deploy:
        replicas: 3
      networks:
        - haproxy-net

Now, I would expect that I will be able to use the parameter container_name, and each replica has a container_name but enumerated to avoid this issue, do you know if is there any workaround? .

services : 
  web:
      image: jmalloc/echo-server:latest
      container_name: web
      deploy:
        replicas: 3
      networks:
        - haproxy-net

In my case, this is needed to use this for my backend section of haproxy and point this to the different replicas

Regards, H

[NCarlsonMSFT]

@h3ct0rjs That behavior isn't from the VS tools: https://docs.docker.com/compose/compose-file/compose-file-v3/#container_name

[h3ct0rjs]

Well @NCarlsonMSFT I’m currently using VSTools but maybe you’re right this feature is more related to docker-compose itself. I will contact support .

[Ewerton]

@h3ct0rjs That behavior isn't from the VS tools: https://docs.docker.com/compose/compose-file/compose-file-v3/#container_name

@NCarlsonMSFT Is right but if we remove the container_name from the docker compose file and try to run the application from Visual Studio we still get the error The "mytest" service is using the custom container name "DockerReplicasTest". Docker requires each container to have a unique name. Remove the custom name to scale the service. If the error persists, try restarting Docker Desktop.

Looking at the command Visual Studio emits to up the containers I saw the following: docker-compose -f "D:\DockerReplicasTest\DockerReplicasTest\docker-compose.yml" -f "D:\DockerReplicasTest\DockerReplicasTest\docker-compose.override.yml" -f "D:\DockerReplicasTest\DockerReplicasTest\obj\Docker\docker-compose.vs.debug.g.yml" -p dockercompose11314233243198381235 --ansi never up -d --build --remove-orphans --scale mytest=2 mytest

The docker-compose.vs.debug.g.yml catch my attention so I opened it to take a look and I found container_name: "DockerReplicasTest" which I'm pretty sure is the causing the issue. To be able to scale service we cannot provide a custom name for the container

So, I believe this is a Visual Studio docker tools support bug and not a docker bug.

[h3ct0rjs]

Hey @Ewerton , You're right, I think that you can close this issue, this behavior is not happening anymore because I'm not currently using this feature, and I'm not pretty sure if this happens to others.

Best Regards, H

[eSPiYa]

The docker-compose.vs.debug.g.yml catch my attention so I opened it to take a look and I found container_name: "DockerReplicasTest" which I'm pretty sure is the causing the issue. To be able to scale service we cannot provide a custom name for the container

I can confirm that this file is has a container_name:.

[NCarlsonMSFT]

@eSPiYa, and @Ewerton are correct the main issue remains that the VS tools doesn't support using replicas and part of that is the use and reliance on container_name. To help with prioritization could anyone chime in on the scenario where replicas are needed for local debugging?

[Ewerton]

@h3ct0rjs That behavior isn't from the VS tools: https://docs.docker.com/compose/compose-file/compose-file-v3/#container_name

@NCarlsonMSFT Is right but if we remove the container_name from the docker compose file and try to run the application from Visual Studio we still get the error The "mytest" service is using the custom container name "DockerReplicasTest". Docker requires each container to have a unique name. Remove the custom name to scale the service. If the error persists, try restarting Docker Desktop.

Looking at the command Visual Studio emits to up the containers I saw the following: docker-compose -f "D:\DockerReplicasTest\DockerReplicasTest\docker-compose.yml" -f "D:\DockerReplicasTest\DockerReplicasTest\docker-compose.override.yml" -f "D:\DockerReplicasTest\DockerReplicasTest\obj\Docker\docker-compose.vs.debug.g.yml" -p dockercompose11314233243198381235 --ansi never up -d --build --remove-orphans --scale mytest=2 mytest

The docker-compose.vs.debug.g.yml catch my attention so I opened it to take a look and I found container_name: "DockerReplicasTest" which I'm pretty sure is the causing the issue. To be able to scale service we cannot provide a custom name for the container

So, I believe this is a Visual Studio docker tools support bug and not a docker bug.

Just adding more info to it: Seems like when we configure which project should be launched in the debugging process, setting "composeLaunchServiceName" in the launchSettings.json file Visual Studio generates the docker-compose.vs.debug.g.yml defining that project in the _containername yaml tag and this causes the issue.

[Ewerton]

@eSPiYa, and @Ewerton are correct the main issue remains that the VS tools doesn't support using replicas and part of that is the use and reliance on container_name. To help with prioritization could anyone chime in on the scenario where replicas are needed for local debugging?

Can't think in nothing specific right now. I always develop applications debugging then with more than one instance. This forces me to test, think, and prepare for scalability. Right now, this bug isn't a real problem. Anyone can duplicate the service in the yaml for testing purposes.

[Polemus]

@eSPiYa, and @Ewerton are correct the main issue remains that the VS tools doesn't support using replicas and part of that is the use and reliance on container_name. To help with prioritization could anyone chime in on the scenario where replicas are needed for local debugging?

Can't think in nothing specific right now. I always develop applications debugging then with more than one instance. This forces me to test, think, and prepare for scalability. Right now, this bug isn't a real problem. Anyone can duplicate the service in the yaml for testing purposes.

This is not a bug, its merely a feature that is not implemented.

As mentioned, they will add it to the backlog.

Thanks @dustyroberts, we have added this to the backlog to investigate but likely won't get to it right away

There are workarounds, like creating multiple entries in the yaml file, but the ideal way would be to make use of the scaling options that is supplied by docker.

[Polemus]

ed for local debugging?

In a scenario where distributed caching is used, and one wants to debug and test multiple instances, as well as more real-life performance testing, manually scaling using separate services with different names is not ideal.

[eSPiYa]

To help with prioritization could anyone chime in on the scenario where replicas are needed for local debugging?

Right now, I'm trying to find out how to implement scalable distributed computing. But there's a workaround, so I think this is not a big deal.