Juju如何与Chef并存,将自动化过程“更进一步”?


15

这篇文章中可以明显看出,Juju与Chef Server位于不同的层次。Juju位于业务流程或服务层,而Chef则更多地位于各个服务器或配置层。

Canonical的Juju主要页面之一上,它指出Juju旨在与Chef和Puppet等工具“共存”,使过程“更进一步”。在过去的几周中,我一直在互联网上搜索有关此主题的内容,但是找不到很好的解释,说明诸如Chef之类的工具将如何与Juju 共存

因此,要分解标题中的总体问题:(特别关注Juju与Chef Server合作)

  • “厨师写”的魅力的例子是什么?仅仅是用bash编写的魅力然后调用chef-solo命令吗?如果是这样,charm可以调用chef-client命令与Chef Server协同工作吗?
  • Juju和Chef之间的重叠部分在哪里?例如,apache2超级按钮有其config-changed钩子,可以在配置世界中进行更改,在厨师世界中,可以通过应用模板文件在配方中进行更改。如果将Juju超级按钮与Chef Cookbook一起使用,以部署apache2服务(集群),则似乎几乎必须编写一个“ apache2-chef”超级按钮,以便您可以分离出任务。在这种情况下,“魅力商店”中的apache2魅力会有所帮助。
  • 如果将Chef角色应用于Juju部署/管理的节点(服务单元),并且sysadmin决定更改特定服务器角色的防火墙规则,并且在Chef角色中执行此操作,Juju是否会覆盖这些更改?
  • 更简单地说,Juju是否可以像Ironfan一样成为Chef Server包装程序?

我认为厨师Server作为如何,而且具可以做的如何,但也带来了什么样的表。这意味着可以查询和采取服务和机器的真实当前状态。您不能在Chef Server中执行此操作。我的目标是将Juju的感知和服务编排功能引入到由Chef Server管理的基础架构中。

几乎必须编写一整套咒语,以保留所有由Chef管理的任务/配置信息。

我很想听听Canonical(例如Jorge Castro)和Opscode(例如A. Jacob或J. Timberman)的帮助。

Answers:


13

很棒的问题!

tl;博士

我想通过几个评论来分解您的问题...首先,这里是整合厨师和枣的几种通用方法:

  • charms hooks可以使用在服务单元上以独奏方式运行的现有厨师食谱(推荐)

  • juju服务单元使用Chef-Node下属服务向现有的Chef-Server注册

这些想法尚未为厨师实施 /测试,但存在与之类似的p。

嗯...不是那么简短的答案

以下是两种整合Chef和juju的方法的细分:

枣作为头号狗

在这里juju主持表演。juju提供的最大价值是分布式配置管理期间的事件协调……因此是“服务编排”的绰号。Juju的魅力包含钩子,juju在协调服务管理时会在“正确的时间”调用这些钩子。这些挂钩的实现几乎是开放的。它们是shell脚本,源代码,木偶清单或...厨师食谱。

Juju将任何服务配置的位分解为:

  • “安装” ..特定于将特定服务安装到节点上的位

  • “关系” ..将服务与其他服务相关所需的配置位

使用厨师食谱作为钩子实现的关键就是这个……您必须确保所使用的食谱尊重这种关注点分离。否则,没有什么可以阻止使用现成的食谱。您可以利用您花费时间/金钱来开发的现有配方。...您只需要确保可以将与关系有关的东西与与安装有关的东西分开调用即可。

我们需要一些例子,但是我认为它将成为流行的b / c厨师,它具有出色的dsl,出色的模板工具,并且在编写复杂配置时比bash更令人愉悦。对于简单的配置,厨师的食谱有点过​​分的imo,因此这种集成方法几乎是两全其美的……并且有很长的路要走。

厨师担任最高职位

这里的想法是将juju服务集成到现有的厨师服务器管理的基础结构中。为此,您需要编写一个Chef-node从属角色。该从属服务将附加到主要juju服务,并将有效地将这些服务注册为Chef服务器的节点(特别是角色)。可以在juju服务启动期间或以后在每个服务的整个生命周期中的任何时间附加订阅。

我认为这与puppet-node子类非常相似。所有必要的键,角色等都可以通过config来指定到Chef-node的从属超级按钮。我从那里开始。更复杂的方法是让Chef-node子节点询问它所附加的主服务和它的Chef-Server以动态确定角色,但这要比仅在子节点的config中指定它们要困难得多。

意见

如果可能的话,我绝对会推荐上面的方法1。从长期来看,将协调层置于配置工具之上可能会很好地工作。不用说,现实的基础架构在一段时间内可能是两种方法的某种组合或变化,尤其是在迁移期间。使用方法2进行计划的共存可能仅在两个工具管理的组件彼此正交的情况下才有效。不知道到底是什么样子。也许枣和厨师分别管理相对分离的服务?我怀疑让juju管理主要服务并让厨师管理更多基础架构方面可能会很好。不知道。不过,这需要更长的讨论时间:)

旁注...您还可以使用juju来管理厨师服务器本身,甚至大型复杂的多层厨师服务器安装。我最近没有看过厨师服务器的魅力,但是如果当前不能处理服务的分层和分离,那么可以肯定地做到了。

我很乐意看到上述提到的两种厨师整合的更多示例...它已经出现在我的愿望/待办事项列表上了一段时间,但是还没有足够优先地冒出来完成工作...请帮助你有兴趣!

好的,那是一个相当不错的杂物:)...让我们从这里开始,然后我们可以在后续注释块中更详细地介绍。


好东西。“我怀疑让juju管理主要服务并让厨师管理更多基础设施方面可能会很好。” 这是我真正感兴趣的,因为我们也有同样的怀疑。就像您说的那样,Chef的DSL和模板非常适合配置。但是,在您的第一种方法中,Chef Server的其他方面(数据包)将很难放手。在服务级别上,Juju应该是头等大事,但是我认为它应该允许Chef在Chef Server模型中做得最好。必须为开发人员和管理员工作。但也许不需要Chef Server。
伊恩·罗西
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.