Visual Studio Dockerfile EntryPoint Override Explained? - docker

Question

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.

Answer 1

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.