TL;DR: 开放讨论的焦点是GraphOps团队为Launchpad（一个Kubernetes索引工具包）开发的Firehose图表。GraphOps团队的Carlos介绍了Kubernetes基础知识、Helm图表以及Firehose-Ethereum图表，展示了其部署的灵活性。团队邀请索引器尝试Launchpad并向他们发送任何反馈。
大家好，欢迎阅览 Indexer Office Hours 会议纪要，第 178 场！
观看 GRTiQ 播客，Hyung-Kyu Choi也被称为“HQ”，他是韩国知名区块链基础设施提供商 DSRV 的联合创始人兼首席运营官。
DSRV 以提供一系列 web3 基础设施解决方案而闻名，包括其验证器服务，为 50 多种协议提供服务、区块链 RPC 服务和开发支持工具，如 Welldone Studio。
重要存储库的最新更新
- Erigon新版本 v3.0.0-alpha.4 ：
- 添加新默认值的重大更改版本：-pporf.port=6060 –metrics.port=6061 –diagnostics.addr=localhost：6062，它们的端口在 Erigon2 中发生冲突。
- Nethermind：新版本 v1.29.0 ：
- 此版本引入了一项突破性变化，将 Discovery.Discv5Enabled 标志替换为更通用的 Discovery.DiscoveryVersion 标志，默认为 V4，但允许 V5 发现，以及新的启发式事务审查检测、区块验证的性能改进以及 Windows 和其他平台的内存优化。
- Heimdall：新版本 v1.0.9 ：
- 此版本包括一些改进和错误修复，例如处理 bridge 中的账户序列、从 Tendermint 添加状态端点、增加列表跨度 API 的最大限制、bridge 自我修复功能的错误修复，以及版本更新和新贡献者的贡献。
- Teku：新版本 v24.10.0 ：
- 此版本引入了 blob 处理和网络改进，包括对 Ephemery Testnet 和 engine_getBlobsV1 的支持，以加快区块导入速度，同时重命名关键指标以与当前版本的 Prometheus 保持一致，以及错误修复，例如删除已弃用的方法和解决 CVE-2024-7254。
- 值得注意的变化包括更新了 Holesky 和 LUKSO 网络的配置，并对某些 Prometheus 指标的命名进行了重大更改。
- 索引器服务和代理 （TS）：新版本 v0.21.4-4 ：
- 这适用于索引器服务和代理的 TypeScript 版本。
- 版本命名已更改。
- 性能修复版本，该版本删除了一种解决方法，即我们必须在图形节点中查询 indexingStatus 两次以确定部署的状态，并将 flushOutstanding （收据） 移动到READ_COMMITTED隔离级别。
- 有关争议 #GDR-17 的信息请求
- 确认它将关闭，一个争议导致罚没，另一个导致平局。
- 督察 POI 发布：交易刚刚完成，谢谢。
- 有关拉取请求列表，请参阅议程。
GraphOps 团队的 Carlos 介绍了他们一直在研究的 Firehose Launchpad 图表。
演示幻灯片：Launchpad：用于索引器的 Kubernetes 工具包
Carlos 首先做了一个简短的介绍，向那些不熟悉 Kubernetes 和 Launchpad 图表的索引者发表讲话。他提到，该演示假设大多数听众都对 Docker 容器有一定的经验。
- Kubernetes 和 Helm 图表
- Firehose 和 Launchpad 图表
- Firehose 图表演示
- Launchpad
- Q&A
- 为大规模生产环境构建的containers编排器。
- 如果您一直在运行containers，则可能会使用 Docker Compose。
- 如果您想启动大量containers，使用它们的配置，即使它们崩溃也保持运行，或者将它们扩展为作为后端运行，并在顶部有负载均衡器，请使用 Kubernetes。
- 帮助您扩展containers作为工作负载交付机制的使用。
- 抽象化了大部分底层基础设施。
- 数据存储位置、如何连接到外部世界或接受来自外部世界的连接等项目。
- 具有许多受 YAML 规范控制的资源类型。
- 适用于对帐循环。
- 按指定的内容驱动系统的状态。如果某些内容崩溃，它将努力使其按原样运行。
- 由 API 驱动。
- 您可以指定工作负载将要运行的内容以及它们的运行方式。
观看 12：25 处的资源示例，其中显示了配置图、服务、部件和部署。
- 与包管理器一样，Helm 将 Kubernetes 资源捆绑到称为 “charts” 的包中。
- 提供生命周期管理（部署、升级）。
- 提供用于更改资源和工作负载配置管理的 go 模板。
一组资源表示您希望在 Kubernetes 集群上运行的应用程序。应用程序将具有container，其中包含表示存储、配置映射或服务的工作负载和资源。对于给定的工作负载部署，您将拥有大量资源，而 Helm 是一种捆绑这些资源类型并打包它们的工具。您可以将 Helm 视为软件包管理器，因为它主要负责部署软件包（称为 chart）的生命周期管理。
另一个功能是模板化正在部署的资源，以便您可以根据部署架构的形状或实际配置工作负载来灵活地更改它们。例如，您可以对要在container上执行的参数进行模板化。
观看 16：14 的 Helm 图表示例。
由于索引器对 Firehose 了解很多，因此 Carlos 重点介绍了它目前的打包和交付方式，以及为 Firehose 制作图表所面临的挑战。
- Firehose 专为可扩展性而设计，并遵循微服务架构。定义接口和协议。
- 它通过对链的节点进行工具化来从区块链中提取数据。
- 摄取节点数据（读取器节点）并生成标准化块文件的组件是最特定于链的 “连接器”。不同的二进制文件：用于基于 EVM 的链的 firehose-ethereum、firehose-near、firehose-gear、firehose-solana、firehose-starknet 等。
- Firehose-Ethereum 与所有基于 EVM 的链（如 Arbitrum、Polygon 等）有很多共同点。
- 我们制作的第一张图表针对 Firehose-Ethereum，因此它将专注于所有基于 EVM 的链，而不是任何其他链。
- 该组件还负责启动链的节点并设置其配置。
- 不同链的 releases 捆绑了不同的节点，因此有不同的镜像。
如果我们希望 chart 支持多个链，我们将不得不运行不同的镜像，这有点反模式和复杂，因为 Helm Chart 的主要目标之一是进行生命周期管理，为此，它应该与特定镜像相关联。
有很多链，作为起点，我们希望为广泛的链提供支持，我们希望支持非常灵活。
- 旨在用于所有使用 'fireeth' 连接器和二进制文件的链。
- 旨在使部署架构非常灵活。
- 用户可以选择加入和退出特定组件。
挑战
- 不同的链需要不同的container镜像。
- 工作负载配置参数各不相同，尤其是关于链的节点。
- 在部署架构方面，没有适合所有人的一刀切或不同的链条。
- Firehose 架构涉及相当多的组件，并且可以通过不同的方式部署它们以服务于不同的使用案例。
- 'firehoseComponents' 部分允许您指定部署架构（例如，支持 Firehose 的区块链节点、读取器、合并器、中继器、Firehose gRPC 服务器）。
- 这是您最灵活地塑造图表部署架构的地方。
- “firehoseServiceDefaults”允许您为每个正在运行的 Firehose 服务设置默认值。
- Firehose 服务是上述 Firehose 组件之一。
- 'firehoseComponentDefaults' 允许你设置所有组件继承的默认值。
- 支持对值进行模板化，从而启用与 source-of-truth 参数绑定的配置管理。
- 实际上，您可以使用模板来指向另一个参数或创建条件，而不必重复参数。
- 覆盖任何内容、任何位置和配置接口，以实现常见用途和其他增值功能。
在 26：12 观看图表使用演示，从初始部署开始，一直到整个过程。
Vince |Nodeify：将共识客户端图表添加为依赖项是否也有好处，或者该过程会是什么样子？我目前假设只是部署并将其指向共识节点服务。
calinah |GraphOps：是的，在 Helm 图表层添加共识层作为依赖项有点复杂，但我们可以在命名空间层默认添加它。我想 Carlos 很快就会有一些关于这方面的内容。
calinah |GraphOps：例如，我们的 Ethereum 命名空间默认捆绑了 Erigon、Nimbus 和 proxyd。
Vince |Nodeify：是的，这很有道理！只是想知道那些只使用图表抽象的人。
calinah |GraphOps：也许我们可以在文档中为那些只依赖 launchpad 图表的用户明确提及这种工作负载依赖。
Carlos 补充道：我们确实有共识层图表，您可以使用我们的图表集 （Launchpad charts） 来部署共识层。除此之外，我可以为共识层图表创建一个值文件，并将其与同一命名空间上的值文件一起安装。Helm 在 chart 级别工作，部署时需要以一致的方式配置共识层工作流，这在独立的 chart 中很难做到。这迫使您将 chart 添加为依赖项并构建这些 Helm chart，这些 Chart 有很多依赖项，并且有缺点。
借助 Launchpad，我们希望在配置图表方面提供很大的灵活性。我们希望将所有配置管理保持在该图表的范围内。例如，为了将图表分组在一起，如果它们在功能上相关或逻辑上连接，我们有 Launchpad 命名空间。命名空间的唯一目的是将 Helm 图表捆绑在一起。它尚未发布，但我们将为 Firehose 提供一个命名空间，它将带来共识层，并专注于跨图表进行配置管理。
观看演示在 38：09 继续，Carlos 卸载部署并稍微更改以展示部署灵活性。
然后 Carlos 展示了如何为 Arbitrum 链部署相同的 chart [44：31]。
- 每条链维护一个 chart 根本无法扩展到 100 条链，并且资源模板逻辑中有很多重复。
- 最大的灵活性和透明度。灵活性在配置管理方面扩展性不佳。这种方法将 Kubernetes 资源生成与工作负载配置管理分离。
- 适用于以实用的方式将 logic parts 降级到库结构图中，从而在图表中实现同质性和标准化。
更多关于命名空间的信息，如上所述。
- 基于 helmfile 构建，helmfile 是一个上层，将不同的逻辑相关 chart 捆绑在一个声明性单元中。
- 专注于提供图表间配置管理。
- 在范围内具有 HA [高可用性] 体系结构部署。
- 以简单的方式提供复杂的堆栈，并预先配置为开箱即用，从而增加了很多价值。
- 任务文件
- 为常见任务或操作准备的工作流。
- 起动机
- 用于使用 Launchpad 堆栈的 Skeleton 存储库。
与此同时，在聊天室......
Vince |Nodeify：图表在存储桶存储方面会有多固执己见？我知道。。。我知道我们绝对应该使用 S3。但对于想要使用本地存储的索引器。
chris.eth |GraphOps：Minio Pod 在本地存储上公开 S3？
Vince |Nodeify：不错！
- 扩展了 Firehose 对 Substreams、sink 和更多链的支持。
- 在库图表中标准化这种方法，并重新设置我们现有图表的基数。
Carlos 感谢 Pinax 团队的支持和协作。
- 加入我们的 Discord：#kubernetes-launchpad。
- 获取 Kubernetes 集群。
- 克隆 Launchpad Starter，使用它并享受复杂软件堆栈的非常快速部署。
- 如有任何问题/错误，请与我们联系，让我们听取您的意见！
- Launchpad 文档简介
- Launchpad 启动器
- Launchpad 图表
- Launchpad 命名空间
- Launchpad 任务文件
chris.eth |GraphOps：今日涵盖的图表：Firehose-Ethereum Helm 图表
Ana |GraphOps：我只是想知道 InfraDAO 是否计划在不久的将来运行 Firehose，这是否有用。
Slimchance：是的，这非常有用。我们将为所有需要 Firehose 的非 EVM 链运行 Firehose，但将来我们还将为所有链运行 Firehose，因此绝对非常有帮助。
Vince 将成为我们在非 CIP [链集成过程] 链（EVM 链）上的主要联系人。我会听他讲确切的时间。
Vince：我们肯定会在非 EVM 链的生产中使用它，然后如果它成为自己的东西并横向扩展或其他任何可能出现的东西，我们也会将其用于 Substreams，但这绝对是扩展的方式，并且在更大规模的情况下让事情变得容易得多，所以当我们有很多链通过 CIP 时， 这将非常有帮助。
Ana：太棒了，所以听起来很快就会有更多的用户，而不仅仅是我们。对其进行测试会很好。
Vince：是的，我没有时间表，但很快我们处理图表后，Pinax 也将运行和测试，我也将运行和测试其他图表，特别是 RPC 图表和随之而来的其他所有内容。
（相关专业名词、注释、代码库、超链接等请关注博客或公众号查找）
All Comments