Dockertools: Run multiple instances of container

[dferretti]

I have a console app that I've added Docker Support to - so it was added to my docker-compose.yml file as expected:

some.console.app:
  image: some.console.app
  build:
    context: ./Some.Console.App
    dockerfile: Dockerfile

I would like to run this console app twice with an environment variable flag which would change its behavior. So I attempted to change the docker-compose.yml file (and made similar changes to the .vs.debug.yml file along with it etc)

some.console.app.A:
  image: some.console.app
  build:
    context: ./Some.Console.App
    dockerfile: Dockerfile
  environment:
    - Flag=A
some.console.app.B:
  image: some.console.app
  build:
    context: ./Some.Console.App
    dockerfile: Dockerfile
  environment:
    - Flag=B

I've tried several different things, such as changing the image name so that each are different, but still come from the same Dockerfile, just to see if maybe VS2017 was differentiating by image name or something. But no matter what I do, I am unable to see the output of the second instance in the Output window. I made sure to copy the relevant section in the docker-compose.vs.debug.yml file to get the tail -f /dev/null entry point for this container as well. And when I run docker ps -a I am able to see that the container is actually running (just the tail command though), but VS has not actually called the dotnet command.

When I read the output from the Build Output, I see the build process look for and kill the dotnet process in both container instances

1>docker  ps --filter "status=running" --filter "name=dockercompose1323906375_some.console.app.A_" --format {{.ID}} -n 1
1>9a6c371e39c5
1>docker  exec -i 9a6c371e39c5 /bin/bash -c "if PID=$(pidof -x dotnet); then kill $PID; fi"
...and same for some.console.app.B

and when Build runs docker-compose -f .... up -d I see both containers running (or saying they are up-to-date).

However, in the Docker Output window, the process only execs the dotnet process on the first instance of the container:

docker  ps --filter "status=running" --filter "name=dockercompose1323906375_some.console.app.A_" --format {{.ID}} -n 1
9a6c371e39c5
docker  exec -i 9a6c371e39c5 dotnet --additionalprobingpath /root/.nuget/packages bin/Debug/netcoreapp1.1/Some.Console.App.dll
but NOT for some.console.app.B

How can I get VS to run my container twice?

[dferretti]

just taking a guess here, but based on this comment from @dazhao-msft on https://github.com/Microsoft/DockerTools/issues/22#issuecomment-306681531
maybe VS Docker Tools looks at which csproj file is associated with a Dockerfile, and then uses that to pair to the first instance in the docker-compose.yml file to determine which container to run the dotnet command in?

[dazhao-msft]

@dferretti-fig that's correct. Alternatively, you can run 'docker-compose up -p {project name}' from command line with different project names to run multiple containers with the same image.

[dferretti]

gotcha - thanks for the response!

[lechuckcaptain]

I'm experiencing the same issue, I'm trying to use the same VS project (_basemicroservice_) in different containers:

version: '3'

services:
  static_web:
    image: static.web
    build:
      context: ./Web/Static.Web
      dockerfile: Dockerfile

  ms_1:
    environment:
      - MODEL=DEF1
    image: basemicroservice
    build:
      context: ./Microservices/BaseMicroservice
      dockerfile: Dockerfile

  ms_2:
    environment:
      - MODEL=DEF2
    image: basemicroservice
    build:
      context: ./Microservices/BaseMicroservice
      dockerfile: Dockerfile

  ms_3:
    environment:
      - MODEL=DEF3
    image: basemicroservice
    build:
      context: ./Microservices/BaseMicroservice
      dockerfile: Dockerfile

With this configuration I got the following error starting the debug with docker-compose:

1>yaml.scanner.ScannerError: while scanning a simple key
1>  in "C:\Docker\obj\Docker\docker-compose.vs.debug.g.yml", line 16, column 1
1>could not find expected ':'
1>  in "C:\Docker\obj\Docker\docker-compose.vs.debug.g.yml", line 17, column 15
1>C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\Sdks\Microsoft.Docker.Sdk\build\Microsoft.VisualStudio.Docker.Compose.targets(349,5): error : yaml.scanner.ScannerError: while scanning a simple key
1>C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\Sdks\Microsoft.Docker.Sdk\build\Microsoft.VisualStudio.Docker.Compose.targets(349,5): error :   in "C:\Docker\obj\Docker\docker-compose.vs.debug.g.yml", line 16, column 1
1>C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\Sdks\Microsoft.Docker.Sdk\build\Microsoft.VisualStudio.Docker.Compose.targets(349,5): error : could not find expected ':'
1>C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\Sdks\Microsoft.Docker.Sdk\build\Microsoft.VisualStudio.Docker.Compose.targets(349,5): error :   in "C:\Docker\obj\Docker\docker-compose.vs.debug.g.yml", line 17, column 15.
1>C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\Sdks\Microsoft.Docker.Sdk\build\Microsoft.VisualStudio.Docker.Compose.targets(349,5): error : 
1>C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\Sdks\Microsoft.Docker.Sdk\build\Microsoft.VisualStudio.Docker.Compose.targets(349,5): error : For more troubleshooting information, go to http://aka.ms/DockerToolsTroubleshooting

The problem seems related to VS is not able to resolve some variables:

• $container_paths_to_fallback_packages_ms_1$
• $nuget_user_folder_ms_1$
• $nuget_fallback_packages_volume_mapping_ms_1$
• $debuggee_arguments_probing_paths_ms_1$

inserted into docker-compose.vs.debug.g.yml generated file. An extract of the file here:

version: '3'

services:
  ms_1:
    image: basemicroservice:dev
    build:
      args:
        source: obj/Docker/empty/
    environment:
      - DOTNET_USE_POLLING_FILE_WATCHER=1
      - NUGET_FALLBACK_PACKAGES=$container_paths_to_fallback_packages_ms_1$
    volumes:
      - C:\Docker\Microservices\BaseMicroservice:/app
      - C:\Users\name\vsdbg:/remote_debugger:ro
      - $nuget_user_folder_ms_1$:/root/.nuget/packages:ro
$nuget_fallback_packages_volume_mapping_ms_1$
    entrypoint: tail -f /dev/null
    labels:
      com.microsoft.visualstudio.debuggee.program: "dotnet"
      com.microsoft.visualstudio.debuggee.arguments: " $debuggee_arguments_probing_paths_ms_1$ bin/Debug/netcoreapp2.0/BaseMicroservice.dll"
      com.microsoft.visualstudio.debuggee.workingdirectory: "/app"
      com.microsoft.visualstudio.debuggee.killprogram: "/bin/bash -c \"if PID=$$(pidof -x dotnet); then kill $$PID; fi\""

  ms_2:
    image: basemicroservice:dev
    build:
      args:
        source: obj/Docker/empty/
    environment:
      - DOTNET_USE_POLLING_FILE_WATCHER=1
      - NUGET_FALLBACK_PACKAGES=$container_paths_to_fallback_packages_ms_2$
    volumes:
      - C:\Docker\Microservices\BaseMicroservice:/app
      - C:\Users\name\vsdbg:/remote_debugger:ro
      - $nuget_user_folder_ms_2$:/root/.nuget/packages:ro
$nuget_fallback_packages_volume_mapping_ms_2$
    entrypoint: tail -f /dev/null
    labels:
      com.microsoft.visualstudio.debuggee.program: "dotnet"
      com.microsoft.visualstudio.debuggee.arguments: " $debuggee_arguments_probing_paths_ms_2$ bin/Debug/netcoreapp2.0/BaseMicroservice.dll"
      com.microsoft.visualstudio.debuggee.workingdirectory: "/app"
      com.microsoft.visualstudio.debuggee.killprogram: "/bin/bash -c \"if PID=$$(pidof -x dotnet); then kill $$PID; fi\""

  ms_3:
    image: basemicroservice:dev
    build:
      args:
        source: obj/Docker/empty/
    environment:
      - DOTNET_USE_POLLING_FILE_WATCHER=1
      - NUGET_FALLBACK_PACKAGES=/root/.nuget/fallbackpackages
    volumes:
      - C:\Docker\Microservices\BaseMicroservice:/app
      - C:\Users\name\vsdbg:/remote_debugger:ro
      - C:\Users\name\.nuget\packages\:/root/.nuget/packages:ro
      - C:\Program Files\dotnet\sdk\NuGetFallbackFolder:/root/.nuget/fallbackpackages:ro

    entrypoint: tail -f /dev/null
    labels:
      com.microsoft.visualstudio.debuggee.program: "dotnet"
      com.microsoft.visualstudio.debuggee.arguments: " --additionalProbingPath /root/.nuget/packages --additionalProbingPath /root/.nuget/fallbackpackages  bin/Debug/netcoreapp2.0/BaseMicroservice.dll"
      com.microsoft.visualstudio.debuggee.workingdirectory: "/app"
      com.microsoft.visualstudio.debuggee.killprogram: "/bin/bash -c \"if PID=$$(pidof -x dotnet); then kill $$PID; fi\""

Based on above information, in my opinion the issue is linked to #52 #13

[lilasquared]

@lechuckcaptain I'm having the same issue, did you figure out what was wrong? My first two instances are not able to resolve the user folder or the nuget fallback folder but the third instance does resolve them

[lechuckcaptain]

@lilasquared I'm still blocked on this side. Hoping it will be fixed on next release

[tkoestler]

I've hit the same issue. Since this bug was opened 6 months ago and there's been no movement I'm not going to hold my breath.

[smalgin]

Just run into this issue. I will attend MS Build in May and ask about this in person.

[whitestrannik]

The same here (

[bwateratmsft]

This issue is being closed as an inactive issue. If you wish to keep it active, please let us know, we are happy to take a look!

[tkoestler]

It does seem that whatever the cuase of this was it has been fixed. I just happened to try it again yesterday and it worked. Of course the same breakpoints hit on all the instances so it’s a little hard to debug this way. I recommend running containers outside VS and using DebugHostAdapter.Launch from multiple instances of VS for a better experience.

[smalgin]

Nice! I will try.

On Wed, Jan 23, 2019, 3:42 PM tkoestler <[email protected] wrote:

It does seem that whatever the cuase of this was it has been fixed. I just
happened to try. It again yesterday and it worked. Of course the same
breakpoints hit on all the instances so it’s a little hard to debug this
way. I recommend running containers outside VS and using
DebugHostAdapter.Launch from multiple instances of VS for a better
experience.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/Microsoft/DockerTools/issues/33#issuecomment-457010240,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AH-uuGe8cxWKG9LphToIAsTBQNsACBBSks5vGPNegaJpZM4OnFIq
.