Docker是在一个操作环境地址空间中的分区能力。通过允许分区直接使用宿主的操作系统，即使操作系统位于分区之外（分区在这里称为容器），启动时间得以缩短，管理容器所需要的资源同样得以缩减（如果你熟悉z/OS，你会发现这个概念有点熟悉） 。
财务人士会喜欢这点，因为获取操作环境licenses的花费会实质性的减少，理论上，每一个非应用部分的组件都能驻留在容器以外。这意味着只需要购买一个Windows licenses，而不是每一个虚拟机上都要购买一个（如果不使用Docker，这是必要的过程）。
本质上，一个特殊的文件（称为一个Docker文件），包含一条或多条关于如何创立一个容器的指令。这个Docker文件作为程序的部分，在文件系统中产生容器，其包含一个单独的应用以及相关联的二进制代码。这个容器（文件系统中的一个子目录）作为任意的文件集会被传送到目标环境并在目标环境中利用Docker的运行时库开始运行，运行时库可以通过命令行接口或者一个API（典型的基于REST，但是还有其他的实现）。
系统管理员会很喜欢这点，因为容器易于部署（通过XCOPY命令就可以？）和维护（REST接口会很容易地集成到任何现代基础架构管理平台中）。
很不幸，当人们试图使用它作为真正的应用发布管理的替代品时，这个概念又不行了。我们能够使用每个人在高中学会的六个词中的五个词还描述应用发布管理：
Who
：并不是组织中的任何人都可以将某一个应用部署到某个环境中。实际上，即使对于那些专职从事这个工作的人，也需要其他人的许可才能进行部署工作。
What
：对于那些想真正引入敏捷业务概念的组织， 每一次都部署一个完整的应用也是不可接受的。那些被认为是低风险的工件（artifacts）（如内容更新）可以及时部署，而高风险的工件则需要在进行大量的测试和其他验证工作后，排队等待进行发布。Docker就属于后者，但是还有一些限制，这会在后面提到。
Where
：一个应用从开发到生产所经历的环境经常与部署的目标环境是不同的。这些差异会在应用进行部署以后，通过更改应用的配置来解决。
When
：发布窗口不是一个新概念。甚至在非生产环境中，也需要各自建立发布窗口，因为环境经常被同一个功能或者夸功能的多个团队所共享（例如：测试和开发可能会使用相同的环境）。
How
：作为很可能是最难以完全集成到一个组织运行能力中的环节，部署一个应用的过程远不是简单的理解如何安装或者配置它。例如，与一个IT服务管理（ITSM）应用集成，以确保所有的需求改变都已输入并且处于正确的状态，这些被吸纳进部署过程以便操作环境的状态一直被明确的理解。这个会在下面进行详细的讨论。
对于上面的5个疑问词，Docker 只解决了其中的一个，而且是并没有采用最有效的方式。以一个欧洲著名银行为例，他们现在每个月发布的产品已经过千，这也只有在所有发布的产品都不是高风险的才能实现，在这个例子里，这意味着这些工件都是低风险类型。因此，这些类型工件的发布会很迅速，这有助于确保这个银行的客户的资产满足他们的需要。
然而，如果他们在使用Docker，无论这些类型的工件是否获得生产许可，整个应用都需要重建。对于大部分公司来说，直接将未获许可的二进制文件发布到产品中而带来的风险是不可接受的。这只是对于上面5项之一——Docker对于解决其他4项无能为力。
