显然这个帖子Juju 与 Chef Server 位于不同的层。Juju 位于编排或服务而厨师则更多地坐在单独的服务器上或配置层。
在Canonical 的主要 Juju 页面之一，其中指出 Juju 旨在与 Chef 和 Puppet 等工具“共存”，使流程“更进一步”。过去几周，我一直在互联网上搜索有关这个问题的内容，但找不到很好的解释如何不过，Chef 这样的工具可以共存和 Juju 一起。
因此，分解一下标题中的首要问题：（特别关注 Juju 与 Chef Server 的合作）
- “用 Chef 编写”的 Charm 示例是什么？它是否只是用 bash 编写的 Charm，然后调用命令
chef-solo？如果是这样，Charm 可以调用chef-client命令与 Chef 服务器协同工作吗？ - Juju 和 Chef 之间的重叠之处在哪里？例如，apache2 charm 有一个
config-changed钩子，它可以进行配置更改，在 Chef 世界中，这些更改将通过应用模板文件在配方中进行。如果 Juju charm 要与 Chef cookbook 一起部署 apache2 服务（集群），那么几乎似乎必须编写一个“apache2-chef”charm，以便您可以分离任务。在这种情况下，Charm Store 中的 apache2 charm 就没什么用了。 - 如果您将 Chef 角色应用于由 Juju 部署/管理的节点（服务单元），并且您的系统管理员决定更改特定服务器角色的防火墙规则并在 Chef 角色中执行此操作，那么 Juju 会覆盖这些更改吗？
- 更简单地说，Juju 可以是一个 Chef Server 包装器吗？铁扇？
我认为 Chef Server 是如何而 Juju 可以做到如何，还带来了什么到桌面。这意味着可以查询和处理服务和机器的实际当前状态。您无法在 Chef Server 中执行此操作。我的目标是将 Juju 的感知和服务编排功能带入 Chef Server 管理的基础设施中。
看起来似乎必须编写一整套魅力，其中省略了所有 Chef 管理的任务/配置信息。
我很想听听 Canonical 的某些人（比如 Jorge Castro）和 Opscode 的某些人（比如 A. Jacob 或 J. Timberman）的意见。
答案1
很棒的问题！
总结
我想通过几条评论来分解你的问题...首先，这里有一些整合 chef 和 juju 的通用方法：
charms hooks 可以使用在服务单元上以单独方式运行的现有厨师食谱（推荐）
juju 服务单元使用 chef-node 下属服务向现有 chef-server 注册
这些想法尚未实施/已经针对厨师进行了测试，但是存在傀儡等效物。
嗯，不太简短的答案
以下是整合 chef 和 juju 的两种方法的详细分解：
Juju 作为领头羊
在这里，juju 负责运行。juju 提供的最大价值是分布式配置管理期间的事件协调……因此有“服务编排”的绰号。Juju charms 由钩子组成，在协调服务管理时，juju 会在“正确的时间”调用这些钩子。这些钩子的实现几乎是开放的。它们是 shell 脚本、源代码、puppet 清单或……厨师食谱。
Juju 将任何服务配置分解为：
“安装”...特定于将特定服务安装到节点的部分
“关系”.. 将该服务与其他服务关联所需的配置位
使用 chef 食谱作为钩子实现的关键正是这一点……您必须确保您使用的食谱尊重这种关注点分离。否则，没有什么可以阻止使用现成的食谱。您可以利用您花费时间/金钱开发的现有食谱……您只需要确保您可以单独调用特定于关系的内容和特定于安装的内容。
我们需要一些例子，但我认为它会很受欢迎，因为 chef 有一个很好的 dsl，一个很好的模板工具，并且在编写复杂配置时比 bash 更令人愉快。对于简单的配置，chef 配方在我看来有点过头了，所以这种集成方法几乎是两全其美的……并且在未来有很大的发展空间。
厨师是领头羊
这里的想法是将 juju 服务集成到现有的 chef-server 管理的基础设施中。为此，您需要编写 chef-node 下属 charm。此下属服务将附加到主要 juju 服务，并有效地将这些服务注册为 chef 服务器的节点（特定角色）。可以在 juju 服务启动期间或每个服务生命周期的任何时候附加下属服务。
我认为这与 puppet-node 子程序非常相似。所有必要的密钥、角色等都将通过配置指定给 chef-node 下属 charm。我会从那里开始。一种更复杂的方法是 chef-node 子程序询问它所附加的主要服务和它的 chef-server 以动态确定角色，但这比仅在子程序的配置中指定它们要困难得多。
观点
如果可能的话，我绝对推荐上述方法 1。将协调层放在顶部配置工具可能会长期运行良好。不用说，现实世界的基础设施在一段时间内可能是这两种方法的组合或变体……尤其是在迁移期间。使用方法 2 的计划共存可能只有在两种工具管理的组件彼此有点正交时才有效。不确定那会是什么样子。也许 juju 和 chef 管理相对解耦的独立服务？我怀疑让 juju 管理主要服务并让 chef 管理更多基础设施方面可能会很好。不知道。不过，这是一个更长的讨论 :)
附注... 您还可以使用 juju 来管理 chef-server 本身... 甚至是大型复杂的多层 chef-server 安装。我最近没有看过 chef-server charm，但如果它目前无法处理分层和服务分离，那么肯定可以做到。
我很乐意看到上述两种类型的厨师整合的更多例子...它已经在我的愿望/待办事项清单上有一段时间了，但优先级还没有上升到足够高以至于无法完成...如果你有兴趣，请帮忙！
好的，这是一段相当不错的闲聊:)...让我们从那里开始，然后我们可以在后续的评论块中更详细地讨论。