不完全是。
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(或 puppet)来配置环境:
生产、阶段和开发(或任何需要的),然后厨师将在“应用程序”服务器上安装 docker,在 postgres 服务器上安装“postgres”,应用安全设置等。这样所有相关的服务器都是相同的。如果我需要更新服务器或添加补丁,配置管理将是微不足道的。
在所有情况下都将使用 Docker,以便环境之间没有应用程序差异,包括开发人员工作站。
这将确保您不会听到“嗯,它在我的本地机器上工作!”的借口。常常。此外,如果有一个糟糕的部署,使用 Docker 回滚应用程序将非常容易。
我希望这能提供更多关于如何使用它们的见解。