假设我想在docker容器中运行某些第三方.net核心应用程序我不完全信任 .
- 为了简化，我们假设应用程序是
dotnet new生成的简单Hello World控制台应用程序 . 这只是2个文件 Program.cs 和 project.json .
现在我尝试了以下方法：
-
将该应用程序复制到我的主机的某个文件夹中
-
使用microsoft/dotnet图像创建一个新容器，将该文件夹作为卷安装，运行用于构建和运行应用程序的特定命令：
$ docker run --rm -it --name dotnet \
-v /some/temp/folder/app:/app \
microsoft/dotnet:latest \
/bin/sh -c 'cd /app && dotnet restore && dotnet run'
我还在考虑将带有microsoft / dotnet的预定义dockerfile作为基本映像的想法 . 它基本上将嵌入应用程序代码，将其设置为工作目录并运行还原，构建和运行命令 .
FROM microsoft/dotnet:latest
COPY . /app
WORKDIR /app
RUN ["dotnet", "restore"]
RUN ["dotnet", "build"]
ENTRYPOINT ["dotnet", "run"]
然后，我可以将预定义的dockerfile复制到temp文件夹中，为该特定应用程序构建一个新映像，最后使用该映像运行一个新容器 .
Is the dockerfile approach overkill for simple command line apps? What would be the best practice for running those untrusted applications? （这可能是我完全忽略的一个）
EDIT
由于我将在运行后丢弃容器并且某个应用程序将生成docker命令，因此我可能会继续使用仅安装卷的第一个选项 .
我也找到了this blog post，他们在那里构建了一个类似的sanbox环境并最终跟随相同的mounted volume approach
1 回答
据我所知，码头工作者会发生什么，留在码头 Worker .
将卷（-v）链接到图像时，该过程可以更改您挂载的文件夹中的文件 . 但只有那里 . 该进程无法遵循任何符号链接或步出已装入的文件夹，因为出于明显的安全原因，它是禁止的 .
当你没有链接任何东西并将应用程序代码复制到图像中时，它肯定是孤立的 .
tcp / udp端口说明由您和内存/ CPU消耗决定，您甚至可以将该进程与Internet隔离e.g. like that
因此，我不认为使用dockerfile是一种矫枉过正，我会这样总结：
如果你想运行它一次，试一试并忘记它 - 如果你输入讨厌的命令就可以使用命令行 . 如果您打算更多地使用它 - 创建一个Dockerfile . 考虑到这是个人喜好的问题，我认为在这里宣布“最佳实践”的空间不大 .