Fabric: v2 兼容的“角色”或类似的

概要

在撰写本文时，v2 分支有一个Group类，该类应该能够作为以前称为“角色”的单位，也就是“一群主机来做事”。

但是，目前还没有组织或标记Group对象的特定方法； 对于想要推出自己的特定创建方式的高级用户的纯 API 用例来说，它已经“完成”了，但对于面向 CLI 的用户或想要构建框架的中级用户来说，它缺乏任何东西。

换句话说，除非您纯粹使用 API，否则如果 CLI 或任务调用位无法找到 Group 对象，那么将 Group 对象放在某处是没有用的！

背景

在 v1 中，角色实际上是一个单一的平面命名空间，将简单的字符串标签映射到 v2 中的组，并且可以在运行时在 CLI 上选择它们 ( fab --roles=web,db ) 和/或注册为任务的默认目标 ( @task('db') \n def migrate(): ），很像主机。

用户在env.roledefs定义了它们，一个简单的字典； 任何中级到高级功能都围绕着修改它，通常是在运行时（通过任务前或子程序），有时是在模块加载时。

特定用例/需求/子功能

• 用于系统中其他任何地方的使用/引用的基本、幼稚的映射：输入名称，取回Group s 和/或Connection s 的一些可迭代对象。
  
  
  
  • 别名通常希望与之相伴，例如Lexicon而不是dict 。
  
  
  • 甚至更深层次的构造，例如“捆绑”，例如，您有名为db 、 web 、 lb直接映射，然后是名为prod的第二层名称Lexicon 。 可能还有其他地图子类也已经这样做了。
  
  
  • 另外/或者，像通配符或其他字符串语法之类的东西，尽管我个人更喜欢利用 Python 不是“字符串类型”的事实......
  
  
• 有用的“反向映射”，以便您可以识别给定连接所属的组。
  
  
  
  • 有问题：因为目前没有全局共享状态，所以对这个问题的天真答案 - 使用身份 - 失败了，因为您可以在技术上创建多个相同的 Connection 对象。
  
  
  • 特别是因为如果您只给它速记主机字符串，Group 可以代表您隐式创建它们，尽管这只是一个方便的选择。
  
  
  • 然而，鉴于没有全局状态的约束，我看不到使用相等测试的明显问题，所以这应该是可行的，例如，即使cxn是一个不同的对象， if cxn in group也会起作用来自group内的相等成员。
  
  
  • 唯一想到的是，是否存在从 Connection 到 Group（必须是组，复数）的强大的、有状态的链接持有它，而不是反之亦然，但我看不出有什么好的理由。
  
  
• 与前一个密切相关：能够检查/显示“当前正在运行的角色”是什么（人们在 v1 中长期以来一直想要的东西，由于其设计而并非微不足道）
  
  
  
  • 主要问题是，这实际上是两个半不同的问题：“一般来说，当前的主机部分是什么角色”（基本上，反向查找的先前用例）以及“什么角色是专门要求对抗的执行机器”。
  
  
  • 换句话说，给定属于角色 A、B 和 C 的主机“foo”：在上下文为“foo”的给定任务中，但由于“对角色 A 执行”的请求而运行，是正在寻找的用户答案是“A、B 和 C”（角色 'foo' 在整体中​​）还是只是“A”（当前正在执行的角色）？
  
  
  • 这真的感觉像是两个不同的 API 调用，即使我记得的功能请求将两者混为一谈。
  
  
• CLI 上的目标选择，全局和/或每个任务
  
  
  
  • Invoke 的 CLI 系统的扩展以解释“所有任务都在其定义之上的标志”可能对此有用或需要。 事实上，它牢牢地落入了 pyinvoke/invoke#205 领域，所以它的优先级比现在更高（相当高。）
  
  
• 同上任务级别的默认值
  
  
  
  • 尽管任务级目标默认值确实希望是以下任何一个：连接、连接、组 obj、组 obj 或评估 _to_ 组 obj 的名称（最后一个是与此票证直接相关的唯一内容，可以说）
  
  
• 同上集合级别的默认值（v2 中的新功能！）
  
  
  
  • 即“$submodule 中的所有任务默认针对db角色运行”
  
  
  • 与前一点相同的交易 - 此默认值希望允许多个不同的值，而不仅仅是字符串键。
  
  
• 通过 OO 方法实现的任何其他新的和令人兴奋的东西真的想与它一起使用吗？ 请记住，重点应该放在构建块和支持高级用户上，而不是像 Chef 或 Ansible 那样完全重新发明系统。

实施思路/关注点

• 如果我们使用配置系统作为主要的存储向量，值“希望”成为原语，以便它们可以存储在 yaml、json 等中，但这是一堆以“将所有组/连接 kwargs 存储在一个大的 ol”中结尾的蠕虫list-o-dicts”等。
• 如果我们期望定义主要在 Python 中，我们可以简单地说“实例化组对象”，然后我们可以选择将该数据合并到配置系统中或以某种方式使其独立。
  
  
  
  • 我想我更喜欢后者，因为把所有东西都塞进嵌套的配置 dicts 感觉就像它会导致坏消息。
  
  
• 像别名和捆绑这样的更深层次的结构增加了复杂性和排序问题（即想象一个简单的别名设置，其中 key1 的值是一个组，但 key2 的值​​是 key1；现在你必须爬行两次结构来解决或检查 key2）
  
  
  
  • 但是，如果我们主要采用“在 Python 中执行”的方法，它就会变得很像配置系统的 API，您可以从声明性结构开始，但在初始设置之后通过方法调用启用更多功能。 我不觉得这很可怕吗？ 编辑：我认为这正是 Lexicon 的工作方式。
  
  
• 无论格式如何，我们都必须弄清楚高级用户希望如何从外部来源或类似来源即时生成它； 这加上别名等问题，意味着我们可能不希望将其存储在“存储”在某处的幼稚结构中，而是作为某个对象或被调用以生成它的对象上的 API。
  
  
  
  • 我怀疑我们可能希望从角色/组的选择“向下”工作，达到最高级别的 API 是“将用户提供的内容转换为可操作的目标单元”，因为最高级的用户必然想要完全控制该 API 调用的实现。 然后我们可以像往常一样提供一个有用的常见案例，但明确标记为“只是一种方法”。
  
  
  • @RedKrieg有一个很好的想法，我们有@group就像@task ，这些函数不是可执行的工作单元，而是产生 Group 对象。
  
  
  • 这种方法本身重用了任务层次结构（集合），这是实用的（为什么要重新发明轮子）和优雅的（因为在现实世界中，角色/组定义经常与使用它们的任务非常紧密地映射！）
    
    
    
    
    
    • 即使您的组不映射到您的任务，它也能很好地工作，因为您可以简单地在根集合级别编写定义。 十分简单。
    
    
    
  
  
  • 我不清楚这是否最好从每个函数返回一个组，或者我们是否希望能够产生多个组（或连接），或者最好不要将它作为装饰函数而只是作为 API 调用集合（例如集合级配置的存储方式）。
  
  
  • 例如，组/角色数据是动态的并且在 Fabric 之外的用例仍然需要在这里解决（这就是为什么我之前指出我们必须首先确定这个空间的最高级别的 API；然后我们需要看看它是如何网格化的有了这个中级想法。）