发布于 2026-01-06 0 阅读
0

我们用于构建 Rig.dev 的 5 个开源项目 关于 Rig.dev 1. Cobra:我们 CLI 的基石 2. UberFX:简化 Go 中的依赖注入 3. Kubebuilder 4. Go-ContainerRegistry:简化远程镜像仓库操作 5. Vue + Nuxt:为我们的前端开发提供支持 总结

我们用于构建 Rig.dev 的 5 个开源项目

关于 Rig.dev

1. Cobra:我们 CLI 的支柱

2. UberFX:简化 Go 语言中的依赖注入

3. Kubebuilder

4. Go-ContainerRegistry:简化远程注册表操作

5. Vue + Nuxt:助力我们的前端开发

总结

大纲
使 Rig.dev 平台成为今天这样的重要因素之一,是我们对开源社区的热爱。

为什么?我们相信透明度、社群精神,以及只有通过多元化、协作努力才能产生的创新。

本文将详细介绍 Rig.dev 背后的开源项目。从命令行界面 (CLI) 到前端,我们精心挑选了每一款工具,以契合我们的使命,并为开发者和运维团队提供最佳体验。敬请阅读!

关于 Rig.dev

Rig.dev 提供了一个面向 Kubernetes 的开源应用平台。我们使开发人员能够在自己的环境中利用更高的应用抽象层进行开发,同时还能充分利用 Kubernetes 的可靠性、可移植性和可扩展性。

隆重推出 Rig.dev

我们面向开发者的部署引擎简化了应用程序的部署、管理、调试和扩展流程。此外,我们的平台还包含仪表盘、命令行界面 (CLI) 和持续集成/持续交付 (CI/CD) 流水线,可与 GitHub Actions 无缝集成。

我们需要您的帮助

我们仍在开发中,但非常希望您能一路在 GitHub 上支持我们。您的支持将激励我们不断改进 Rig.dev 🙏
我们的 GitHub 项目:https://github.com/rigdev/rig


1. Cobra:我们 CLI 的支柱

Cobra 是构建 Go 语言命令行界面 (CLI) 的首选库(此处双关)。它之所以脱颖而出,是因为它从一开始就非常易于使用(没错,又是这一点)。您只需几行 Go 代码即可创建一个功能齐全的 CLI,而且随着项目规模的扩大,Cobra 也能随之扩展,兼具复杂性和可扩展性。

我们为什么选择 Cobra 作为我们的 CLI 系统

丰富的开箱即用功能
Cobra 内置了大量功能,使 CLI 开发变得轻而易举:

子命令:轻松创建嵌套命令,让您的命令行界面 (CLI) 更清晰、更直观。
全局、本地和持久标志:定义适用于所有命令、特定于单个命令或可被子命令继承的标志。

位置参数:使用验证函数和守卫轻松处理位置参数,使您的 CLI 更加灵活,同时保持控制。

自动帮助命令:Cobra 会自动生成帮助命令,省去了手动编写文档的麻烦——当然,您也可以自定义命令。

可扩展性:与他人良好合作

Cobra 的主要优势之一在于其可扩展性。虽然 Cobra 负责 CLI 的结构和命令行解析,但您可以自由地将其与其他工具集成,以您喜欢的方式完成任务:

使用 PromptKit 实现交互式 CLI:我们使用 PromptKit 为 CLI 添加交互性和样式,从而提升用户体验。

使用 UberFX 进行依赖注入:我们利用 UberFX 将依赖项直接注入到我们的命令中,使代码更简洁、更易于维护。

示例:创建和部署 Redis 胶囊。

  1. 使用 Redis 镜像创建构建。
  2. 胶囊中的实例监听端口 6379,并且使用负载均衡器暴露该端口。
  3. 我们指定,当容器启动时,它会运行命令“redis-server /usr/local/etc/redis/redis.conf”,这是使用特定配置文件启动 Redis 服务器的方法。
  4. 然后,我们将该配置文件从本地 redis.conf 文件挂载到 /usr/local/etc/redis/redis.conf 中。
  5. 最后,我们部署了 3 个实例。

使用 Redis 镜像创建构建


2. UberFX:简化 Go 语言中的依赖注入

UberFX 是 Uber 为 Go 语言打造的一个强大的依赖注入框架。如果没有依赖注入,开发者常常需要手动构建大量的对象,或者更糟糕的是,依赖于不稳定的全局状态。

我们为什么使用 UberFX

我们选择 UberFX 是因为我们亲眼见证了它高效的扩展能力,从小型应用程序到大型代码库都能轻松应对。我们团队的部分成员曾在 Uber 亲身经历过 UberFX 的成功部署,因此我们相信它能够随着 Rig.dev 的发展而扩展。

实际案例:我们在 Rig.dev 中使用 UberFX 的方式

在 Rig.dev 中,所有组件都遵循类似的初始化模式。我们在每个组件的构造
函数中指定其依赖项,UberFX 会负责按正确的顺序构建所有组件。以下是一个简化的示例:

type service struct {
    logger         *zap.Logger
    userRepo       repository.User
    secretRepo     repository.Secret
    projectService project_service.Service
}

type newParams struct {
    fx.In
    Logger         *zap.Logger
    UserRepo       repository.User
    SecretRepo     repository.Secret
    ProjectService project_service.Service
}

func NewService(p newParams) Service {
    return &service{
        logger:         p.Logger,
        userRepo:       p.UserRepo,
        secretRepo:     p.SecretRepo,
        projectService: p.ProjectService,
    }
}
Enter fullscreen mode Exit fullscreen mode

然后我们将相关组件的构造函数分组到 Fx 模块中:

var Module = fx.Module(
    "service",
    fx.Provide(
        capsule.NewService,
        user.NewService,
        auth.NewService,
        project.NewService,
        group.NewService,
    ),
)
Enter fullscreen mode Exit fullscreen mode

接下来,构建整个 Rig 服务器就非常简单了。我们还使用 FX 来执行设置服务器所需的非构造函数:

// Slightly simplified Rig Server construction 
rigServer := fx.New(
    service.Module,
    repository.Module,
    gateway.Module,
    telemetry.Module,
    fx.Supply(config),
    // Non-constructor function needed to setup the server 
    fx.Invoke(
        func(cfg config.Config, s *pkg_service.Server) {
            s.EmbeddedFileServer()
            s.Init()
        },
    ),
)
Enter fullscreen mode Exit fullscreen mode

Fx 还负责处理 Rig 服务器执行过程中的各种生命周期,例如

// Simplified execution of Fx's lifecycles which power the Rig server
func run(ctx context.Context, rigServer *fx.App) error {
    if err := rigServer.Start(ctx); err != nil {
        return err
    }

    sig := <-rigServer.Wait()
    var err error
    if sig.ExitCode != 0 {
        err = fmt.Errorf("aborted: signal %v", sig.Signal.String())
    }

    if err := rigServer.Stop(ctx); err != nil {
        return err
    }

    return nil
}
Enter fullscreen mode Exit fullscreen mode

UberFX 大大简化了我们构建和运行 Rig.dev 的方式。它使我们能够使用可重用的组件构建应用程序,从而简化开发流程,并确保随着代码库的增长,我们能够高效地扩展。


3. Kubebuilder

Kubebuilder 已成为创建 Kubernetes API 扩展的首选工具。当然,也可以使用原生的 Kubernetes API 客户端来创建控制器,而且从技术上讲,任何编程语言都可以做到这一点。

Kubebuilder

但问题在于:Kubernetes 是用 Go 语言编写的,其生态系统中很大一部分也是用 Go 语言构建的。为了确保无缝集成并减少工具兼容性方面的潜在问题,坚持使用生态系统中应用最广泛的工具是明智之举。

关于我们即将与 Kubebuilder 集成的一些见解

随着 Rig.dev 的发展,我们一直在寻找增强平台功能的方法。我们计划的一项重大变革是将部分 API 从 Rig.dev 内部迁移到与 Kubernetes 更深度集成。我们的愿景是引入自定义资源定义 (CRD),以封装我们的“胶囊”概念(此处双关,意在强调“胶囊”)。

此次整合将为我们的用户带来的潜在好处

通过此举,我们实际上是在使 Rig.dev 与更广泛的 Kubernetes 生态系统更加兼容。这具有以下几个主要优势:

生态系统兼容性:随着我们将 API 更深入地集成到 Kubernetes 中,Rig.dev 与更广泛的 Kubernetes 生态系统的兼容性也越来越好。这意味着它能与 Kubernetes 专业人员日常使用的其他工具和平台实现更好的互操作性。

熟悉度:对于已经熟悉 Kubernetes API 的开发人员来说,我们的 API 更加直观易用。这降低了学习难度,使他们能够立即上手并高效工作。

灵活性:由于我们的 API 更贴近 Kubernetes 原生特性,开发人员在 Rig.dev 上部署、管理和扩展其应用程序时获得了更大的灵活性。

我们即将与 Kubebuilder 集成,旨在减少开发人员和 DevOps 团队在 Kubernetes 上投入大量精力时遇到的阻力,让他们的工作更加轻松。我们对此次集成带来的兼容性以及由此带来的更集成、更高效的运维流程感到非常兴奋。


4. Go-ContainerRegistry:简化远程注册表操作

Go-ContainerRegistry 是一个 Go 库,它提供了一种与容器镜像仓库交互的简便方法。如果您曾经需要浏览远程仓库、拉取镜像或操作镜像元数据,那么这很可能就是您需要的工具。

Go-ContainerRegistry

我们为什么要使用 Go-ContainerRegistry?

我们在 Rig.dev 中使用 Go-ContainerRegistry 的主要原因是它对容器镜像的处理方式非常统一。无论您是处理各种远程镜像仓库、本地守护进程,甚至是本地镜像文件,Go-ContainerRegistry 都为所有这些操作提供了一致的接口。这对我们至关重要,原因如下:

统一接口:处理镜像时无需切换不同的工具或库。Go-ContainerRegistry 提供了一个统一的 API,满足您的所有需求。

跨注册表支持:无论您是从 Docker Hub、Google Container Registry 还是任何其他注册表拉取镜像,您都可以通过相同的 API 调用来完成所有操作。

本地和远程:该库不仅适用于远程操作;您还可以使用它与本地 Docker 守护程序交互或操作本地镜像文件。


5. Vue + Nuxt:助力我们的前端开发

我们为什么选择 Vue 和 Nuxt

在前端开发中,产品上市时间往往至关重要。Vue 以其简洁性著称,结合 Nuxt,让我们得以在创纪录的时间内推出 MVP(最小可行产品)。但不要被它们的简洁性所迷惑;Vue 和 Nuxt 是前端开发中最强大的框架之一。

使用 Vue 和 Nuxt 的好处

简洁易上手,快速入门:如果您熟悉 HTML、CSS 和 JavaScript,您会发现 Vue 非常容易上手。与其他流行的框架(例如 React 和 Angular)相比,Vue 的学习曲线更为平缓,这使得新开发者更容易快速入门。

性能与轻量级:Vue 非常轻量级,这意味着更好的性能。与其他流行的框架(如 React 和 Angular)相比,Vue 的性能始终优于它们(基准测试:https ://krausest.github.io/js-framework-benchmark/current.html ),尤其是在初始加载时间和运行时效率方面。

开发效率:Nuxt 在 Vue 的简洁性基础上进行了大幅增强,使构建复杂应用程序变得更加轻松。它处理了大量样板代码和配置,让开发者能够更专注于应用程序逻辑,而无需过多关注底层基础设施。

完善的文档:Vue 和 Nuxt 都拥有详尽的文档,方便新老开发者快速上手。这在团队扩展或引入新功能时尤为重要。

为什么我们在 Rig.dev 中使用 Vue 和 Nuxt?

Vue 和 Nuxt 提供的统一方法与 Rig.dev 的理念非常契合。正如我们致力于在后端以统一的方式处理跨镜像仓库、守护进程和本地文件的图像一样,Vue 和 Nuxt 也为构建和管理前端提供了一种高效且连贯的方式。


总结

我们参与这些开源项目不仅仅是为了利用它们的功能,更是为了成为一个更大社区的一份子。这个社区以协作、创新和共同的目标为驱动,致力于让技术更易于使用、更高效。

随着 Rig.dev 的不断发展和完善,我们始终对这些项目背后的开发者和社区充满感激。他们的奉献和专业知识将对我们未来的发展起到至关重要的作用。我们对未来充满期待,并致力于回馈开源世界,为其发展做出贡献,同时确保 Rig.dev 始终处于 Kubernetes 应用平台的前沿地位。


加入我们的社区

此外,请加入我们的 Slack 社区 ,分享反馈、报告错误、提出功能建议,并关注未来的更新。

Team Rig.devRig.dev 团队感谢您 🙏

文章来源:https://dev.to/rigdev/5-open-source-projects-were-using-to-build-our-application-platform-for-kubernetes-489e