Lyft 宣布开源基础设施工具管理平台 Clutch！

作者：Daniel Hochman & DerekSchaller

推荐：ysyou

译者：时间

今天我们很高兴地宣布，Lyft 的基础设施工具可扩展 UI 和 API 平台clutch已开放源代码，clutch使工程团队能够构建、运行和维护用户友好的工作流，这些工作流还包含特定于域的安全机制和访问控制。clutch兼容多种管理平台功能（如 AWS、Envoy和 Kubernetes），强调可扩展性，因此它可以为堆栈中任何组件提供托管功能。

云计算的动态属性显著地降低了新基础设施的采用成本。CNCF云原生计算基金会全景图跟踪了300多个以上开源项目和1000多个商业产品。尽管各组织们能快速采用这些项目和供应商，但每种新技术都有它自带的一套配置、工具、日志和指标。为了让开发者快速、安全地在整个堆栈中变更，需要在工具方面进行大量前期和持续的投资，而大多数组织都未能考虑到这一点。所以，虽然新基础设施越来越容易采用，但日益扩大的新组件的规模难以管理，特别是随着整个平台的复杂性和工程团队规模的增长。Clutch解决了这一难题，通过让基础设施团队向他们整个工程组织提供直观和安全的基础设施管理接口。

Clutch是一年开发周期的成果，用来解决“Lyft”开发人员经验和工具的短板。Clutch由两个核心部件组成。go后端设计为可扩展的基础设施控制平面，将单个由protobuf驱动的API拼凑成具有通用授权，可观测性和审计日志记录的系统。React前端是一个可插拔并且面向工作流的UI允许用户和开发者在单个窗格后创建新功能，这只需要很少的代码和很少的JavaScript知识及更少的维护工作。

1

设计和架构

在设计和架构方面，比起其他解决方案，clutch提供了与众不同的开发人员工具空间。在项目开始时，我们在构建自己的工具前对现有工具做了深入分析。采用工具的主要目的是：

• 减少平均维修时间。基础设施什么时候响应告警，工程师们待命时花太多时间在阅读runbooks和操作复杂的工具。
• 消除意外中断。当执行维护任务时，当用户在使用runbook时漏掉警告或者删除错误的资源（例如，他们认为没有使用，但占用了很大流量的资源），从而导致严重中断。
• 强化细粒度的权限并以通用格式审计所有活动，一些权限过于宽泛，是因为供应商的访问控制不支持细粒度控件，此外，当我们出于安全目的从各种工具收集审计日志时，很难将那些数据提炼成为如何帮助我们改善工具的可执行见解。
• 提供一个极大简化未来工具开发的平台。以“Lyft”这样的规模，如果不考虑团队外的贡献资源，项目范围很大时很难成功，我们没有足够的资源来构建Lyft需要的每一个特性，更别说支持它了。

一开始我们看到现有供应商UI的不足：由于缺乏专业化，供应商工具很慢 （并且在某些情况下是危险的）。他们需要不必要的步骤来执行常见任务，并提供超出必要的信息集。除了简单的访问控制外，通常很少有防护，结果导致运营人员可能会执行看似无害但实际降低系统性能的操作。另外，他们也许不太熟悉该工具从而延误补救。理想情况下，工程师每四到六周只来一次。人们很容易忘记如何使用这个工具，特别是考虑到没有用特定的交互系统情况下，又去多种执行任务。

由于碎片化和信息杂乱无序，依赖供应商工具的后果是高认知负荷。

相比之下，Clutch这样一个与供应商无关的工具能将不相关的系统一体化为清晰，一致的用户体验，并且提供专用功能来执行常见任务，只需很少的点击和培训。

然后我们转向开源社区，发现开源基础设施管理工具通常仍然局限于单个系统，并不是为广泛的自定义设计的，它并不能解决认知负荷和碎片化的问题。此外，虽然有用于构建控制台的其他前端框架，但没有一个框架包含具有身份验证，授权，审计，可观察性，API模式和丰富插件模型的集成后端框架。有一个很流行的持续交付平台，它解决了与Clutch相同的首要问题（例如，降低MTTR，用户友好的UI）但是，它需要大量的投入来运行微服务和迁移应用到不同于我们自己的架构上。Clutch后端功能开发简化，是通过上面列出的集成核心功能为每个API端点免费。它还开发为单个二进制文件，只需要很少的操作投入。

最后，我们想要一个平台，可以对它进行投资，对其他内部团队来说它需要更容易理解和构建。Clutch提供一个集成的和引导式开发模型，使其功能开发成为简明直接的过程。除了一流的后端功能外，Clutch 的前端还为状态管理和多步表单提供了独特的抽象，没有大量JavaScript 经验的基础架构团队更容易实现前端开发。

2

特性

"控制平面"模型

Envoy 代理是Lyft创建的。如今，它是最受欢迎的代理之一，部署在许多大型互联网公司，并不断推进云网络标准。我们的团队从与大社区一起维护Envoy中学到了很多东西。Envoy用户讨论的最热门主题之一是控制平面的开发进展，特别是如何系统地集成各种不同的组件，以便Envoy能够有效地路由和报告网络流量。Envoy类似于 Clutch，它集成不同的基础设施系统于统一的API。

Clutch采用了许多envoy代理的核心模式，这些模式是在网络控制平面多年的工作中脱颖而出的。

像Envoy 一样，Clutch 是配置驱动、模式驱动的，并利用基于模块化扩展的架构，使其适用于各种用例，同时不影响可维护性。扩展Clutch不需要分支或重写，自定义代码可以很容易地从自定义公共或私有外部存储库编译到应用程序中。这些相同模式使具有独特技术堆栈的大小组织能够聚集在单个代理解决方案上，有望使相似的独特组织聚焦在Clutch这样的基础设施控制平面上。

3

安全和保障

此外，Clutch附带身份验证和授权组件。OpenID Connect （OIDC） 身份验证流用于单点登录、RBAC，以及对所有操作的自动审核，并能够运行附加的输出接收器，例如Slackbot。

Clutch 还具有降低事故风险的功能。通常记录在 Runbook 中的护栏和启发式方法可以以编程方式实现。例如，我们绝不允许用户一次将群集缩减 50% 以上，因为这种操作曾经导致过正常维护时的意外中断。不久以后，我们计划获取CPU 和其他使用数据，以便与群集信息一起显示，甚至在确定可能导致停机的情况下，限制缩小规模的下限。通过将护栏和启发式方法直接实施到工具中，避免了仅仅依靠于培训和运行手册来防止事故的发生。

4

部署和用户引导

Clutch作为包含前端和后端的单个二进制文件进行传输，使部署工作变得很简单。许多更改可以通过配置实现，而不是重新编译新的二进制文件。

提供基础设施生命周期工具的其他系统，则需要一组复杂的微服务或迁移到一种固有的方式管理和部署应用程序。Clutch旨在完善现有系统，而不是更换它们。

5

框架和组件

Clutch由Go后端和React前端驱动。它为后端和前端开发提供了功能齐全的框架。Clutch的所有组件都是可组合的，允许使用部分框架功能或完全自定义功能。

这样的组件和工作流体系结构让前端经验有限的开发人员在不到一个小时的开发时间内，就能使用清晰且易于使用的分步 UI 替换笨重的工具或命令行脚本。

Clutch的前端封装提供的组件，可轻松构建一致且连续用户体验的分步工作流程，包括：

• DataLayout：是一个工作流-本地状态管理控件，用于处理来自 API 调用的用户输入和数据。
• Wizard：用于向用户显示分步表单，自定义元素的 UI 插件，用于在以最少的代码以一致的方式显示丰富的信息。
• Clutch的后端重度依赖从ProtobufAPI 定义生成的代码。

Protobuf 工具还生成前端客户端，随着 API 的发展，该客户端保持后端和前端的同步。后端的组件包括：

• 模块：代码生成的 API 存根的实现
• 服务：用于与外部数据源交互
• 中间件：用于检查请求和响应数据以及应用审核、授权等。
• 解析器：一种基于自由格式文本搜索或结构化查询查找资源的通用接口

解析器是一个Clutch抽象，我们希望会对将功能抽象到多个组织的方式产生重大影响。解析器使用自定义资源位置代码可轻松扩展，允许操作员通过组织习惯的通用名称（而不是普通的规范标识符）定位资源（如 K8s pod 或 EC2 实例）。例如，如果开发人员称其应用程序为"myService-staging"，则很容易添加一种将此类查询解释为结构化元素的代码"

前端有一行代码：

<Resolver type="clutch.aws.ec2.v1.Instance" />

渲染的表单如下：

在后端配置额外的搜索维度，将会自动映射在前端渲染表单。

6

Clutch在Lyft公司

在 Clutch 之前，Lyft 工程师依靠一系列大杂烩式命令行工具、Web 接口和 Runbook 来执行简单的任务。Lyft 最常见的警报需要解决多达六个不同的信息源：警报、其他服务仪表板、Runbook、其他文档源、供应商控制台或脚本以及配置设置。随着 Lyft 在团队、产品和堆栈方面进行扩张，我们意识到这些工具没有跟上步伐。我们用现有的框架解决这些问题没有出路，这导致了Clutch的第一个迭代开发。

在过去的一年里，Clutch 在使用和开发方面拥有令人难以置信的内部采用率。Clutch经受住了数千个与基础设施管理相关的风险操作，每一个操作都有带来意外或延迟的可能，导致用户失去对我们的信任。

在撰写本文时，七个内部工程团队已经计划到 2020 年底添加新功能，其中至少一半面向开源。工程师（包括我们出色的实习生）在有限的指导下能够开发出有意义的功能。最重要的是，我们终于能够看到一条路线，通过单一虚拟管理平台交付我们的内部平台，使 Lyft 基础设施成为满足客户需求的一个产品，而不是拼凑的系统和工具集合。

我们在内部收到了很多积极的反馈，例如：

"我很满意它的存在， 否则我将仍然在等待选项卡加载到云提供商的控制台中。

有关 Lyft Clutch的更多细节，可以在 Lyft 案例研究文章中找到。

7

路线图

在整个构建Clutch的过程中，产品不断发展，我们的内外部路线图目前包含了 Lyft 的全体开发人员经验。我们的长期愿景是构建一个情景感知开发者门户，不仅向开发者提供一套工具，而且在用户登录门户时提供最有价值的工具和信息。

即将推出的功能包括：

Envoy UI，为用户提供一个实时仪表盘，以监视其分布式应用程序的网络性能和配置。 混沌测试，与Envoy集成来允许预定的故障注入和挤压测试与自动停机条件。自动修正，通过适当的Clutch操作自动响应警报。 安全增强，包括性能升级、考察模态和两阶段审批。 附加的基础设施生命周期管理功能，查看群集的状态以查找异常值，执行长时间运行的维护任务。 服务健康状况仪表板，使用可配置的报告机制向开发者提供有关其服务状态的反馈（例如代码覆盖率、成本、活跃的突发事件）。 通用配置管理，允许用户通过引导式 UI 管理复杂配置，或以其他方式将基础结构中的变更反映为代码声明。 拓扑图，将用户与其拥有的服务关联，并在登陆页上向他们显示相关的数据和工具。

有关即将进行项目的更多详细信息，请浏览我们的路线图。

8

社区

Clutch对 Lyft 的开发人员体验产生了重大影响，允许基础设施和其他工程团队将工具交付为精美的产品而不是事后的想法。团队对内部新功能贡献感到非常兴奋，Lyft 的工程师喜欢使用该平台：

"可用性非常高，提高了Lyft 工程师的整体生活质量。”

加入我们吧！Clutch 对于其他大型和小型工程团队具有同样出色的潜力。我们期待与社区合作开发其他插件和核心功能，以构建丰富的生态系统。我们的目标是让每个团队和技术堆栈访问一流的云原生工具，并减少认知负载。欢迎所有的贡献，从想法到实施，我们很乐意帮助您开发第一个功能。

了解更多有关Clutch的消息：

访问网站和文档：https://clutch.sh。 查看代码：https://github.com/lyft/clutch。 Twitter：@clugdotsh。

我们迫不及待想看到开源社区将会把项目带向何处。一路向前！

原文链接：

https://eng.lyft.com/announcing-clutch-the-open-source-platform-for-infrastructure-tooling-143d00de9713