我完全了解在开发工作站上准确了解生产环境的全部事实：它会删除＆＃34;它可以在我的计算机上运行＆＃34;。
Docker对我而言就像Bruce Lee on steroids fighting Abdul Jabbar：如果你需要使用VM，请使用Docker。
如果在开发时，我使用nuget来控制我的依赖项，在我的构建服务器上，它会在部署之前恢复软件包：然后我确实需要运行该应用程序。
此外，它是我在同一个盒子上一遍又一遍地部署的应用程序。当我必须知道出了什么问题时，为什么我需要重新启动策略？如果应用程序死亡，其他框将承担负担，我需要调查/修复，而不是习惯于＆＃34;没什么大不了的，容器将在一分钟后重新启动＆＃34;。
在云环境中，我明白了一点：AWS，Azure是那些可以从中受益最多的人。就像在客户要求更多电力时能够快速地将webapps从服务器移动到服务器。此外，如果那些webapps不同，那么我需要将它们彼此隔离：Docker的大用途！
但是，在内部/主机托管方面，如果我有一个powershell脚本来为我准备好一个裸机金属服务器，我准备好了IIS：为什么我会引入另一层抽象？
答案 0 :(得分：1)
我想到的前两个答案（还有更多，但我认为这些是最重要的）：
资源利用率 - 如果您是裸机，则您的计量单位可能是整个VM。当您运行多个应用程序或服务实例时，只能通过运行更多VM来实现。在我的世界中，这个典型的例子是IIS网站，我每台机器只能获得一个实例。如果我运行三个实例，我有三个严重未充分利用的虚拟机。 Docker允许您在单个VM中复制应用程序。在水平扩展之前，您可以在单个VM上使用更多资源。
特定于应用程序的依赖关系 - 您可以管理VM映像和操作系统依赖关系，但有时您可能希望针对您的应用程序更专门地调整它。例如，IIS的版本。您可以构建特定于应用程序的容器映像，而不是需要为全局的所有应用程序运行一个依赖项版本，这样可以使您的运行时更具可预测性。
部署独立性 - 如果您依赖于全局依赖关系，那么您将自己锁定一次更新所有应用程序，而不是能够独立部署每个应用程序。您的部署规模更大，风险更大。容器允许您按照自己的节奏更新每个容器，并以递增的方式提供更多价值。