Kaltura如何通过AWS CodeBuild托管Runner加速CI/CD流水线

如何借助AWS CodeBuild托管的Runner加速CI/CD

本文由Kaltura高级平台工程师Adi Ziv撰写，并得到了AWS的协作。

作为领先的AI视频体验云和企业通信技术提供商，Kaltura通过将GitHub Actions runner迁移到AWS CodeBuild托管服务，彻底改造了其CI/CD基础设施。这次迁移使DevOps运维开销降低了90%，构建队列时间加快了66%，基础设施成本削减了60%。最重要的是，这次迁移在支持Kaltura庞大规模的同时取得了这些成果：覆盖1000多个代码仓库、100多种不同类型的工作流，以及跨多个开发团队每日1300多次构建。

随着企业工程规模的扩大，维持高效的CI/CD基础设施变得越来越关键。虽然像GitHub Actions这样的工具简化了流水线的创建，但管理底层基础设施可能成为工程团队的沉重负担，尤其是在处理安全需求和私有网络访问需求时。对于Kaltura而言，随着公司工程团队的快速扩张和每周都有新的微服务加入，这一挑战变得尤为严峻。

在本文中，您将看到Kaltura如何通过从自管理的Amazon Elastic Kubernetes Service (Amazon EKS) runner迁移到CodeBuild托管的runner，实现了CI/CD基础设施的现代化，在显著提升性能和降低运维开销的同时，实施了更强大的安全功能。

挑战与解决方案概述

理解自托管Runner

GitHub托管的runner提供了零运维开销、自动扩展以及每个作业的干净环境，对于许多开发团队来说是绝佳选择。然而，对于像Kaltura这样有特定安全和运维需求的企业而言，自托管runner是更好的选择。GitHub托管的runner运行在共享环境中，虽然安全，但无法提供企业敏感工作负载所需的精细控制级别。通过迁移到AWS上的自托管runner，Kaltura获得了强大的安全控制能力，例如Amazon Virtual Private Cloud (Amazon VPC)隔离、AWS Identity and Access Management (IAM)策略和细粒度的访问管理。此外，自托管runner还允许Kaltura为其特殊需求定制硬件配置，根据其特定的使用模式优化成本，并保持对运营至关重要的私有网络资源的直接访问。

最初实施的自托管runner提供了Kaltura所需的控制力。通过在Amazon VPC内部署runner，Kaltura获得了企业级运营所需的关键能力。该实现使得在实施通过IAM角色的细粒度权限的同时，能够直接访问内部资源。使用Amazon端点让Kaltura避免了公共API请求，确保了所有流量都保留在组织安全的私有网络内。

基于Amazon EKS的初始方案

Kaltura最初的方案是在Amazon EKS上部署自托管的GitHub Actions runner，并使用Karpenter进行节点自动扩展。Kaltura实现了一个自定义控制器，该控制器会轮询GitHub API以获取排队的工作流并启动必要的runner。虽然这个方案提供了Kaltura所需的安全性和控制力，但也带来了巨大的运维挑战。

问题的核心在于Kaltura的轮询机制。随着解决方案规模的扩大，Kaltura经常触及GitHub的API速率限制，被迫将轮询频率降低到两分钟一次。这种情况导致了一系列运营问题。DevOps团队花费了大量时间来维护runner镜像、基础设施和扩展机制。每个新仓库都需要手动更新配置，这在开发过程中造成了瓶颈。为了满足性能SLA，Kaltura维持着温热的runner池，这显著增加了基础设施成本。

图1：初始方案基于Amazon EKS和Karpenter来启动GitHub Runner。

这对开发团队的影响是巨大的。每个工作流执行都面临着从排队到执行至少两分钟的延迟。这些延迟在一天中不断累积，严重影响了开发人员的生产力。DevOps团队发现自己经常被从其他重要任务中拉出来处理基础设施维护工作。随着Kaltura规模的持续扩大，这种情况变得越来越难以维持。

Kaltura的解决方案——AWS CodeBuild托管Runner

在评估了多种选项后，Kaltura选择了CodeBuild托管runner，以在保持自托管方案的安全性和控制力优势的同时，解决基础设施的挑战。这种新架构从根本上改变了CI/CD解决方案的运行方式，从基于轮询的系统转向了基于Webhook的系统。

图2：基于AWS CodeBuild的解决方案是完全托管的，并且基于Webhook。

新架构通过一个简单而强大的流程运作。当开发人员向GitHub推送代码时，GitHub会立即发送Webhook通知到AWS CodeConnections。这会触发CodeBuild，在Kaltura的Amazon VPC内配置一个runner。然后，GitHub Actions工作流在这个CodeBuild runner上执行，利用遵循最小权限原则的细粒度IAM角色来访问AWS服务。

关键架构组件

基于Webhook的架构彻底消除了之前轮询的挑战。工作流不再等待定期检查，而是在触发时立即开始执行。CodeBuild和CodeConnections使用一个带有Webhook的GitHub App，可在仓库、组织或企业级别进行配置。这种集成实现了真正的CI/CD自动发现，相比之前的手动配置需求是一大进步。

安全性仍然是新架构的主要组成部分之一。每个runner都在Amazon VPC内运行，保持了严格的网络安全要求。Kaltura通过IAM角色实施了细粒度的访问控制，确保runner只能访问它们所需的特定AWS服务，例如AWS Systems Manager Parameter Store、Amazon CloudWatch和AWS Secrets Manager。这既维护了安全态势，又简化了访问管理。

基础设施管理

CodeBuild的无服务器特性改变了基础设施管理方式。Kaltura不再需要维护一个带有自定义控制器和扩展逻辑的复杂Amazon EKS集群，而是利用了AWS的托管服务。这一转变消除了修补runner镜像、维护基础设施或优化扩展机制的需要。

该系统的灵活性对于多样化的流水线需求尤其有价值。CodeBuild支持多种计算配置，从标准实例到多架构构建，再到专门的ARM和GPU runner。Kaltura可以通过简单的标签配置轻松地将计算资源与工作流需求匹配，无需管理不同的runner池或维护单独的基础设施堆栈。

Docker工作流改进

一个意想不到的好处出现在Docker构建过程中。之前基于Amazon EKS的解决方案需要复杂的Docker-in-Docker (DinD)配置或像Kaniko这样的替代工具来进行容器构建。CodeBuild的原生Docker支持消除了这些复杂性。该服务提供了可以安全、直接运行Docker的隔离构建环境，并具有内置的层缓存功能，显著提升了构建性能。

自动发现与自助服务

新架构的一个关键优势是其自助服务能力。当开发团队创建新仓库或修改现有仓库时，不再需要DevOps手动干预。系统会根据预定义配置和工作流的runs-on标签自动配置合适的runner。这种自助服务方法极大地减少了Kaltura的运维开销，同时提高了开发人员的生产力。

以下是一个典型的工作流配置，展示了新方法：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


name: Hello World
on: [push]
jobs:
  Hello-World-Job:
    runs-on:
      - codebuild-myProject-${{ github.run_id }}-${{ github.run_attempt }}
      - image:${{ matrix.os }}
      - instance-size:${{ matrix.size }}
      - fleet:myFleet
      - buildspec-override:true
    strategy:
      matrix:
        include:
          - os: arm-3.0
            size: small
          - os: linux-5.0
            size: large
    steps:
      - run: echo "Hello World!"

此配置展示了Kaltura如何利用CodeBuild的灵活性，同时保持简单、声明式的工作流定义。团队可以通过标签指定他们的计算需求，系统会处理所有底层的配置和管理工作。

迁移方法

向CodeBuild runner的迁移过程顺利，对工作流的改动极小。成功迁移的关键在于其简单性——大多数工作流只需要修改runs-on标签：

1

runs-on: codebuild-myProject-${{ github.run_id }}-${{ github.run_attempt }}

由于具有一对一的兼容性，这意味着现有的工作流无需进一步修改即可继续运行。

成果

新架构成功地处理了来自1000多个仓库、100多种工作流类型的每日1300多次构建，同时服务于具有不同安全需求的多支开发团队。迁移到CodeBuild托管runner在各项关键指标上都带来了显著的改进：

运营影响：

DevOps运维开销减少90%
构建队列时间缩短66%
基础设施成本降低60%
每位开发人员每日节省30分钟时间

最重要的是，由于构建速度更快、摩擦更少、性能更稳定，开发人员的满意度得到了提升。系统的自助服务性质消除了上线的瓶颈，并加速了开发生命周期。

结论

Kaltura通过CodeBuild托管runner对其CI/CD基础设施进行的改造，展示了现代云服务如何解决复杂的企业级开发挑战。从在Amazon EKS上管理自托管runner到利用AWS托管服务的旅程，带来了运维开销减少90%、构建队列加快66%、成本节约60%的成果，同时满足了企业级的安全要求。

对于考虑类似路径的组织，我们建议从使用非关键仓库的试点项目开始。专注于了解您的工作流需求、安全需求和性能瓶颈，以制定有效的迁移策略。尽早实施成本分配标签和监控，以确保迁移影响的可见性，并向利益相关者展示投资回报率。

关于作者

Adi Ziv 是Kaltura的高级平台工程师，拥有超过十年的设计和构建可扩展、弹性、优化的云原生应用程序和基础设施的经验。他专注于无服务器、容器化和事件驱动架构。

Michael Shapira 是AWS的高级解决方案架构师，专注于机器学习和生成式AI解决方案。拥有19年软件开发经验，他热衷于利用前沿AI技术帮助客户实现业务转型并加速其云采用之旅。Michael也是AWS机器学习社区的活跃成员，在帮助客户扩展其企业和云基础设施的同时，为创新和知识共享做出贡献。当不忙于设计云解决方案时，Michael喜欢作为一名摄影爱好者通过镜头捕捉世界。

Maya Morav Freiman 是AWS的技术客户经理，帮助客户最大化AWS服务的价值并实现其运营和业务目标。她是AWS无服务器社区的一员，并拥有十年DevOps工程师经验。

本文内容及观点由第三方作者提供，AWS不对本文内容或准确性负责。