它们都解决的是同一个问题吗？还是说它们针对的是两组不同的问题？如果是这样，那么为什么我建议使用 vagrant，为什么我建议使用 juju？
答案1
快速版本：
vagrant 是一个用于处理 virtualbox 实例的工具。它通常在开发期间（在 Mac 上）用于将您的应用测试部署到更像最终生产环境（即 Linux）的虚拟机中。它有一个可自定义的（ruby）处理程序堆栈，可以按照您喜欢的任何方式创建这样的虚拟环境。Vagrant 是一个强大的工具，可以以编程方式管理虚拟环境，并提供各种“本地”持续集成式开发技术变体。它最常用于在 Mac 上运行 Ubuntu VM，但可以在各种平台上运行并部署各种目标操作系统。据我所知，它只与 virtualbox 作为底层“提供程序”一起使用。
juju 是一种使用各种不同的底层提供商来编排服务的工具：ec2 云、openstack 云、lxc VM 和 MaaS 服务器。它与 vagrant 共享一个“本地开发”故事（使用 lxc 容器而不是 virtualbox VM），但这实际上是唯一的重叠。事实上，我希望看到为 juju 编写的 vagrant 提供程序，这样 juju 就可以在本地环境中驱动 virtualbox 容器，就像驱动云和 lxc 映像一样容易。那将是一个绝佳的选择！此外，juju 的价值确实很大程度上来自于可以直接开箱即用的 charms/services 集，而 vagrant 本质上是一个较低级别的本地容器提供程序。
事实上，我们提供了一个带有 Juju 的 Vagrant 盒子，以便用户可以在 VM 内部测试本地提供程序：
请注意有一直在努力“统一” vagrant 周围的部署脚本，以便可以使用相同的脚本部署到云实例以及 vagrant 框。这些似乎大多是 vagrant 本身之外的一次性功能，坦率地说，只是强调了对 juju 等工具的需求。
答案2
关于“统一围绕 vagrant 的部署脚本”，Vagrant 与 Puppet 和 Chef 具有出色的集成性，可用于跨环境（从 Vagrant 盒到本地硬件再到云）自动化系统配置。事实上，许多人在将 Puppet/Chef 脚本用于生产之前，都会使用 Vagrant 来测试它们。
将 Juju 添加到与 Vagrant 配合使用的自动化工具列表中肯定会很好。