Juju 和 Openstack 配置

Juju 和 Openstack 配置

我是 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 的支持没有改变的计划。

相关内容