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 container_name 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.

[Snazzie]

Would be awesome to have this working.

[fiveisprime]

Hey folks,

This is something we're working on getting implemented and I could use your help! If you could spare 15 minutes to walk me through your workflow and how you're planning to use replicas it would really help us prioritize our implementation and make sure we're helping you the right way. You can schedule a Teams call with me here: https://aka.ms/MeetWithMatt

[eSPiYa]

@fiveisprime
English isn't my main language and my spoken english is a lot worse than my written, so I won't be able to join the call. I'm not sure if this will be helpful, but I'll give it a shot anyway.

Even though we're deploying out applications on Kubernetes, we're doing local development using Docker because we're having a hard time debugging on Kubernetes, specially those Worker Services. We have to test out the behavior of our applications from how it handles distributed computing to when it encounter errors. We also perform some stress-testing locally to see some possible issues, for example we found out that there's an issue on Nginx as reverse proxy to SignalR with backplane, having 5 instances of the SignalR application somehow the connection got refused. Through this, we can spot issues early before we spend more time on implementing something that may not work or issues that we can't resolve immediately.

As of now, we debug with single instance of each application and hoping it will work. Then we'll create a docker-compose override for the replicas and execute it directly to docker, with cross-fingers that it will work as what we're expecting. Being able to debug with replicas and know which instance is having an issue will surely be helpful.

[Danotsonof]

Hey folks,

This is something we're working on getting implemented and I could use your help! If you could spare 15 minutes to walk me through your workflow and how you're planning to use replicas it would really help us prioritize our implementation and make sure we're helping you the right way. You can schedule a Teams call with me here: https://aka.ms/MeetWithMatt

I'm unable to book a meeting.

What @eSPiYa mentioned above is a good scenario for the requested feature.

[NCarlsonMSFT]

@Ewerton, @Polemus, @eSPiYa, @Snazzie, @Danotsonof
Visual Studio 2022 17.13 Preview 1 released today and includes support for launching a service with replicas / scale set. Please help us by installing the preview and letting us know how it works for you!

[Snazzie]

@Ewerton, @Polemus, @eSPiYa, @Snazzie, @Danotsonof Visual Studio 2022 17.13 Preview 1 released today and includes support for launching a service with replicas / scale set. Please help us by installing the preview and letting us know how it works for you!

Just tried it. and it seems to be working nicely. all instances have debugger attached.

[Polemus]

@Ewerton, @Polemus, @eSPiYa, @Snazzie, @Danotsonof Visual Studio 2022 17.13 Preview 1 released today and includes support for launching a service with replicas / scale set. Please help us by installing the preview and letting us know how it works for you!

Looking forward to trying it out. Internet is a bit slow, so will only get back with feedback tomorrow

[h3ct0rjs]

I test this with my old repo and it is working nicely. Thanks everybody at Microsoft.