我是 Juju 和 Openstack 的新手，目前正在使用 Juju 手动提供程序部署两节点和三节点 openstack 测试环境。第一次尝试时，我尝试使用 juju deploy 的 --to 键将服务部署到我的主机。
当 Juju 无法在同一主机上部署的 Keystone 和 MySQL 之间建立关系时，我意识到出了问题。为了部署服务，我使用了以下语法：
juju deploy keystone --to 1
juju deploy mysql --to 1
一些谷歌搜索给了我askubuntu 上的这个问题和本指南。
因此，据我了解，在手动环境中部署服务的正确方法是使用 lxc 容器将服务部署到同一主机（当然，如果这些服务可以在容器中工作）。
虽然我看到了 lxc 的优点，比如服务独立性和隔离性，但我仍然不明白为什么 Juju 部署的服务必须在容器中隔离。这是 Juju 的设计缺陷还是临时解决方案？
有没有办法可以在不使用 lxc 的情况下将几个服务部署到同一台主机？
我认为可以通过为每个正在部署的服务指定配置文件来实现，但这会消除几乎所有的 Juju“魔力”和简单性......
答案1
Juju 本身并不关心。这取决于你部署的魔法来处理这种情况，或者不处理。所以这实际上根本不是一个问题；这只是 Juju 支持的内容、魔法通常支持的内容和公认的最佳实践之间的差异。
我认为这个答案并不针对手动提供商。它适用于所有提供商。
大多数 charm 都假设它们“拥有”它们所部署到的机器（或容器），并且在过去这是部署它们的唯一方法。
这种隔离使 charms 更易于开发和测试。它消除了 charm 开发人员担心与其他 charms 共享资源的需要。模块化部署使管理复杂性变得更容易。通过将 charms 之间的交互限制为 Juju 关系，它们可以保持干净和易于理解。Charm 作者不必担心进行可能对其他 charms 产生不利影响的“系统”级更改；这取决于容器化是否正确处理这个问题。这消除了一整类 charm 错误，即一个 charm 对另一个 charm 产生不利影响。
因此，在实践中，除非专门设计用于协同工作，否则 Charm 至少应部署到各自的容器中。如果两个 Charm 部署到同一台机器时没有将它们放入容器中，则发生的冲突通常不会被视为错误。
这应该不会有太大影响。LXC 很轻量。
这些都不会阻止您编写自己的 charm，或修改现有的 charm，以允许它们部署到同一台机器或容器中。Juju 会允许这样做，但 charm 必须确保它们不会发生冲突。
这是 Juju 设计缺陷还是临时解决方案？
不 - 这根本不是 Juju 的事情；这是 charm 作者选择的最佳实践，并且与 charms 应该和不应该支持哪些部署配置的决定有关。
在一些极端情况下，它很有用，并且支持起来并不困难（例如，在引导节点上运行的 Juju GUI），因此 Juju 允许它。我相信 Juju 的支持没有改变的计划。