在Docker容器中运行不可信的.net核心应用程序的最佳实践

比方说，我想运行一个docker集装箱内的一些第三方.net核心应用程序，我不完全信任。

为了简化，假设应用程序是由dotnet new生成的简单的Hello World控制台应用程序。这只是2个文件Program.cs和project.json 。

现在我已经尝试了以下方法：

使用microsoft / dotnet映像创build一个新的容器，将该文件夹挂载为一个卷，运行特定命令来构build和运行该应用程序：

 $ docker run --rm -it --name dotnet \ -v /some/temp/folder/app:/app \ microsoft/dotnet:latest \ /bin/sh -c 'cd /app && dotnet restore && dotnet run'

我也在考虑将预定义的dockerfile与microsoft / dotnet作为基本映像。它将基本embedded应用程序代码，将其设置为工作目录并运行恢复，构build和运行命令。

 FROM microsoft/dotnet:latest COPY . /app WORKDIR /app RUN ["dotnet", "restore"] RUN ["dotnet", "build"] ENTRYPOINT ["dotnet", "run"]

然后，我可以将预定义的dockerfile复制到临时文件夹中，为特定的应用程序构build一个新的映像，最后使用该映像运行一个新的容器。

dockerfile方法矫枉过正简单的命令行应用程序？ 运行这些不受信任的应用程序的最佳做法是什么？ （这可能是我完全忽略的一个）

编辑

由于我将在运行后丢弃容器，并且由某个应用程序生成docker命令，所以我可能只需要安装一个卷的第一个选项。

我也发现了这个博客文章，他们build立了一个类似的sanbox环境，并最终遵循相同的挂载量方法

据我所知，在docker工人会发生什么事，留在docker工人。

将卷（-v）链接到映像时，该过程可以更改装入的文件夹中的文件。但只有在那里。该进程无法遵循任何符号链接或从安装文件夹中跳出，因为出于明显的安全原因而被禁止。

当你不链接任何东西，并将应用程序代码复制到图像中时，它绝对是孤立的。

tcp / udp端口展览取决于你以及内存/ CPU的消耗，你甚至可以隔离从互联网的进程，例如那样

因此，我不认为使用dockerfile是一个矫枉过正，我会这样总结：

当你想运行一次，尝试它，并忘记它 – 如果你可以input令人讨厌的命令使用命令行。如果您打算更多地使用它 – 创build一个Dockerfile。考虑到个人喜好的问题，我认为在这里宣布“最佳做法”的空间不大。