不完全是。

Chef /
Puppet是“相同的”，它们是配置管理。尽管您可以使用它们来管理虚拟机或公共/私有云，但是大多数人并不倾向于那样使用它们。它们是配置管理。它们通常在启动虚拟机以使其处于所需状态后起作用。也就是说，虚拟机上需要什么软件，需要添加哪些用户，需要什么配置等。因此，它倾向于用于扩展基础架构。

Vagrant虽然还可以用于管理虚拟机和公共/私有云，但通常仅用于一个关闭的环境。它提供了用于创建虚拟机的内聚文件。这种方式与厨师/木偶相似，但并不倾向于大规模使用。

Docker是一个独立的野兽。它具有多个组件，但主要用于“捆绑”（注意：它的功能远不止于此，但这是ELI5答案）软件，并且需要运行主机系统（或基础结构）。它为应用程序增加了一点安全性，但主要为运行应用程序提供了一致的“操作系统”。

实际上，所有这些都可以在环境中使用。这是一个例子：

假设您有应用程序FunTime。您有八名开发人员对此做出了贡献，并且FunTime旨在在AWS的可扩展基础架构上运行。它被设计为具有前端（FunTime-
Front）和后端（FunTime-API），并且需要postgres。前端有4个开发人员，后端有4个开发人员。

我将执行以下操作（有很多方法可以使这只猫皮肤化，但这是一个示例）：

我将Docker用于FunTime-Front和FunTime-
API。我将使用Vagrant为开发人员设置开发环境（以便他们可以调整各种组件）。Vagrant将：在本​​地（或根据需要在云上）启动VM，安装docker，为FunTime-
Front和FunTime-API下拉docker映像，安装postgres，并使用虚拟数据填充postgres，将网络端口配置为各种组件。

现在，开发人员可以在其本地计算机上拥有完整的FunTime堆栈，而不必自己动手配置任何东西：他们只需键入“ vagrant up”即可。

在基础架构方面，我将使用Chef（或木偶）配置环境：生产，阶段和开发（或所需的任何东西），然后Chef将docker安装在“应用程序”服务器上，将“
postgres”安装在postgres服务器上，应用安全设置等。这样，所有相关服务器都是相同的。如果我需要更新服务器或添加补丁，那么使用配置管理将是微不足道的。

在所有情况下，都将使用Docker，以便环境之间（包括开发人员工作站）的应用程序之间没有差异。

这样可以确保您不会听到“它在我的本地计算机上正常工作”的借口！常常。此外，如果部署不合理，则使用Docker非常容易回滚应用程序。

我希望能对如何使用它们提供更多的见解。