Hacktoberfest 2026:メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

[RFC] Support for horizontal scaling Sourcebot

オープン
#439 コメント 3 件 リアクション 6 件 担当者 0 名 GitHub で見る

まだ誰も着手していません。

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
25/100
issue の種類
機能追加
明瞭さ
説明が足りない
活発さ
停滞
技術スタック
docker, docker-compose, helm, nixos, postgresql, redis, terraform, typescript

調査の方向性

Start by mapping the webapp, worker, and zoekt services and reviewing the proposed docker-container.yml and docker-compose.yml deployment entry points. Investigate what each service requires to run multiple replicas, then compare local Compose with the proposed Helm, Terraform, and NixOS production paths. Done requires an agreed design, sensible defaults, and documented deployment configurations.

索引モデルが issue の本文から書いたものです。

説明

RFC

This discussion tracks adding support for horizontal scaling to Sourcebot.

TL;DR

  • I think the existing single, self-contained docker container is great since it's super easy to use and is radically simple.
  • But it's probably not practical in larger deployments, especially ones with thousands of repositories.
  • We've seen instances where when a machine is under heavy indexing load, the webapp can become unresponsive or even OOM errors can occur.
  • I think the first logical step here is to distribute our services as separate images (i.e., ghcr.io/sourcebot-dev/(webapp|worker|zoekt))
  • Upstream dependencies like Postgres, and Redis would be separate.
  • More images = more complexity, so I think the best mechanism to manage this complexity is moving towards declarative configs. We could do the following:
    • For local deployments, we can define a docker-container.yml at the root of the repository. Deploying will now involve 1) Cloning the repo, and 2) running docker compose up.
    • For production deployments, we can use technologies such as Helm, Terraform, Railway, and NixOS
  • I think it will be important to have sensible defaults (s.t., it's very easy to deploy), while having deep configuration options that are well documented (s.t., it fits the user's deployment story).

Open questions / investigations

  • What will we need to do to make each one of our services (webapp, worker, zoekt) to support multiple replicas at the same time?

Is this Overkill?

I'm trying not to go too overboard with the design here. DX should not be sacrificed with this change: ideally it should improve. Sourcebot should be just as easy to deploy as a vertically scaling service, both locally and in production. Deploying it as a horizontally scaling service in production should also be easy, while including configuration depth to support a wide range of deployment scenarios.

Locally, using Docker Compose will streamline deployment since a) it's a single command, docker compose up, and b) it's declarative, so all of the options (w/ sensible defaults, or commented out) can be included inside the docker-compose.yml.

In production, using Helm, Terraform, NixOS, etc. will help get people setup quickly. Again, sensible defaults here are key.

We also should continue supporting the self-contained image since to avoid introducing a breaking change here. We can evaluate if it's still worth shipping whenever we do a v5.

主要言語
TypeScript
スター
3.9k
フォーク
374
平均マージ
21時間 18分
マージ済み PR(30日)
39

コントリビューションガイド

コントリビューションガイドを開く

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

sourcebot-dev/sourcebot のほかの issue

sourcebot-dev/sourcebot の issue をすべて見る

似ている issue

TypeScript の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。