2

I am new to Docker and trying to understand but I have noticed the Visual Studio does a lot of 'magic' behind the scenes. I have managed to figure out all my questions about the docker run command VS uses when you debug an ASP.NET Core app with Docker support except one.

docker run 
-dt 
-v "C:\Users\jnhaf\vsdbg\vs2017u5:/remote_debugger:rw" 
-v "D:\ProtoTypes\WebAppDockerOrNot\WebAppDockerOrNot:/app" 
-v "C:\Users\jnhaf\AppData\Roaming\ASP.NET\Https:/root/.aspnet/https:ro" 
-v "C:\Users\jnhaf\AppData\Roaming\Microsoft\UserSecrets:/root/.microsoft/usersecrets:ro" 
-v "C:\Users\jnhaf\.nuget\packages\:/root/.nuget/fallbackpackages2" 
-v "C:\Program Files\dotnet\sdk\NuGetFallbackFolder:/root/.nuget/fallbackpackages" 
-e "DOTNET_USE_POLLING_FILE_WATCHER=1" 
-e "ASPNETCORE_ENVIRONMENT=Development" 
-e "ASPNETCORE_URLS=https://+:443;http://+:80" 
-e "ASPNETCORE_HTTPS_PORT=44328" 
-e "NUGET_PACKAGES=/root/.nuget/fallbackpackages2" 
-e "NUGET_FALLBACK_PACKAGES=/root/.nuget/fallbackpackages;/root/.nuget/fallbackpackages2" 
-p 4800:80 
-p 44328:443 
--entrypoint tail webappdockerornot:dev -f /dev/null

The final argument --entrypoint tail webappdockerornot:dev -f /dev/null is the one that confuses me. I get that VS is overriding the entry point setup in the Dockerfile but what I do not understand nor can find online is what tail webappdockerornot:dev and the -f /dev/null. I figured out that webappdockerornot:dev is the docker image but can someone explain how this argument works or provide a link to something that explains it.

Jason H
  • 4,996
  • 6
  • 27
  • 49

1 Answers1

2

We can break down that command line a little differently as

docker run \
  ... some other arguments ... \
  --entrypoint tail \
  webappdockerornot:dev \
  -f /dev/null

and match this against a general form

docker run [OPTIONS] [IMAGENAME:TAG] [CMD]

So the --entrypoint tail option sets the entry point to tail, and the "command" part is -f /dev/null. When Docker actually launches the container, it passes the command as additional arguments to the entrypoint. In the end, the net effect of this is

Ignore what the Dockerfile said to do; after setting up the container runtime environment, run tail -f /dev/null instead.

which in turn is a common way to launch a container that doesn't do anything but also stays running. Then you can use docker exec and similar debugging-oriented tools to do things inside the container.

David Maze
  • 130,717
  • 29
  • 175
  • 215
  • Thank you for the information but I am still lost on what `tail` is and what the command argument -f (for tail) does. Can you provide insight into that? – Jason H Sep 09 '18 at 19:25
  • It's [the standard Unix *tail*(1) command](http://pubs.opengroup.org/onlinepubs/9699919799/utilities/tail.html#tag_20_125). – David Maze Sep 09 '18 at 19:31
  • Leave it to Microsoft to make this more confusing that it needs to be but if I am reading this correctly, it is copying the last parts of the docker image (presuming this is the entry point from the Dockerfile itself) and then putting that into the newly created docker run command. – Jason H Sep 09 '18 at 19:34
  • Something I don't understand about this: "common way to launch a container that doesn't do anything". Why isn't this container doing anything? Surely it's running a dotnet application? So if the container's `dotnet` CLI entrypoint is being replaced with `tail`, what is actually starting the dotnet application? – Tom Troughton Jun 20 '19 at 10:10
  • It reads all of the content from `/dev/null` printing it to stdout. `/dev/null` is never ready to read, so the container's main process is literally "sit and do nothing". There is no .net application, you've replaced it with the `tail -f` invocation. – David Maze Jun 20 '19 at 10:15