我应该使用docker logs命令从.net核心控制台app dockerized(linux image)看到控制台输出(Console.WriteLine)吗?
答案 0 :(得分:1)
想要扩展 @Cale's 答案。
就像他说的:
让我们看看容器,了解发生了什么。
基础知识:docker 日志将从定义的入口点启动的进程的 stdout 和 stderr 中获取。通过 Dockerfile
和/或 docker-compose.yml
定义。
构建镜像(没有 VS)并通过 docker run 启动后,它看起来像这样。
$ docker build -t my-project:dev Dockerfile .
$ docker inspect -f '{{json .Config.Entrypoint}}' my-project:dev
["dotnet","MyProject.dll"]
入口点是我们的应用程序,因此 docker 会读取我们应用程序的 stdout 和 stderr 并创建日志。
简短:
docker-image 入口点是 tail -f /dev/null
-> 没有 docker 日志,从来没有。
在容器运行而您的应用程序运行时,VS-Debug 通过 docker exec MyAppContainer 'sh -c vsdbg ...'
启动应用程序 -> 所有输出(stdout、stderr、debug)都转到 VS
tldr;
这里很有趣;)
VS Debug 将创建一个容器,如下所示:
docker inspect -f '{{json .Config.Entrypoint}}' MyProjectName
["tail","-f","/dev/null"]
前面提到的 tail -f /dev/null
入口点。
Docker 将从这个过程中读取 > 因此什么都没有。
实际上,我们的应用根本不是通过常规 docker 机制启动的!
那么应用程序调试会话是如何开始的呢? 让我们连接到图像并查看。
root@2e65795bcd7e:/app# pstree -p 0 -A -T -a
?,
|-sh,1394 -c...
| `-vsdbg,1401 --interpreter=vscode
| `-dotnet,1414 --additionalProbingPath /root/.nuget/packages --additionalProbingPath /root/.nuget/fallbackpackages /app/bin/Debug/net5.0/MyApp.dll
`-tail,1 -f /dev/null
底部是我们的入口点 tail -f /dev/null
顶部是一个 sh -c vsdbg ... dotnet ... MyApp.dll
。
当您停止并开始调试时,您可以看到此过程如何消失和重新出现。
所以 VS 做了这样的事情:
docker exec MyAppContainer 'sh -c vsdbg --interpreter=vscode'
这反过来又会启动您的应用程序
dotnet --additionalProbingPath /root/.nuget/packages --additionalProbingPath /root/.nuget/fallbackpackages /app/bin/Debug/net5.0/MyApp.dll
答案 1 :(得分:0)
是。如果使用默认的日志记录驱动程序,则可以看到写入stdout和stderr的日志。
默认情况下,docker日志显示命令的STDOUT和STDERR。
答案 2 :(得分:0)
发现在调试模式下,app只会写入调试输出控制台。因此,如果在本地调试容器上运行docker logs
,则什么也没有。如果以发布模式运行容器,则运行docker logs