Juju和Openstack配置

Question

我是Juju和Openstack的新手，目前正在使用Juju手动提供程序部署两个和三个节点的openstack测试环境。在我的第一次尝试中，我尝试使用--to来部署服务到我的主机。

当Juju未能创建部署在同一主机上的Keystone和MySQL之间的关系时，我意识到出了问题。要部署服务，我使用了以下语法：

juju deploy keystone --to 1   
juju deploy mysql --to 1

谷歌给了我关于askubuntu的这个问题和本指南。

因此，据我了解，在手动环境中部署服务的正确方法是使用lxc容器将服务部署到同一个主机(当然，如果这些服务可以在容器中工作)。

虽然我看到了lxc的优势，比如服务无关性和隔离性，但我仍然不明白为什么由Juju部署的服务必须在容器中隔离。这是一个设计缺陷还是暂时的解决方案？

有没有办法在没有lxc的情况下将几个服务部署到同一个主机上？

我认为可以通过为正在部署的每个服务指定配置文件来实现，但这将消除几乎所有Juju“魔术”和简单性.

Answer 1

朱菊自己也不在乎。这取决于你为处理这种情况而部署的魅力，或者不是。因此，这并不是一个真正的问题；这仅仅是Juju支持的东西、魅力通常支持的东西和接受的最佳实践之间的区别。

我不认为这个答案是特定于手册提供者。它适用于所有提供者。

大多数魅力假设它们“拥有”部署到的机器(或容器)，而在过去，这是部署它们的唯一方法。

这种隔离使得魅力更容易开发和测试。它消除了魅力开发人员担心与其他魅力共享资源的需要。模块化部署使管理复杂性变得更容易。通过将魅力之间的相互作用限制在朱菊关系上，它们可以保持干净，并得到充分的理解。魅力作者不必担心做出可能会对其他魅力产生不利影响的"system"-level更改；应该由容器化来正确处理这一问题。这就消除了一种魅力对另一种魅力产生负面影响的一整类符咒缺陷。

因此，在实践中，魅力至少应该部署到自己的容器中，除非它们是专门设计来协同工作的。如果没有将两个符咒部署到同一台机器上，而没有将它们放入容器中，就会产生冲突，通常不会将它们视为bug。

这不会有太大影响。LXC是轻型的。

所有这些都不能阻止您编写自己的魅力，或修改现有的魅力，以允许将它们部署到同一台机器或容器中。朱菊会允许这样做，但这取决于他们的魅力，以确保他们不会发生冲突。

这是一个设计缺陷还是暂时的解决方案？

不--这根本不是一件事；它是魅力作者们选择的最佳实践，它涉及到关于部署配置魅力应该支持和不应该支持的决定。

有一些边缘情况下，它是有用的，并不难支持(例如。在引导节点上运行的Juju )，所以Juju允许它。我相信没有任何计划来支持Juju改变。