正式なドキュメントは英語版であり、この日本語訳はAI支援翻訳により作成された参考用のものです。日本語訳の一部の内容は人間によるレビューがまだ行われていないため、翻訳のタイミングにより英語版との間に差異が生じることがあります。最新かつ正確な情報については、英語版をご参照ください。

Zoekt

  • プラン: Premium、Ultimate
  • 提供形態: GitLab.com、GitLab Self-Managed
  • ステータス: 利用制限

この機能は限定的な利用です。詳細については、エピック9404を参照してください。イシュー420920でフィードバックを提供してください。

Zoektは、コード検索に特化して設計されたオープンソースの検索エンジンです。

このインテグレーションを使用すると、GitLabでコードを検索するために、完全一致コードの検索を、高度な検索の代わりに使用できます。グループまたはリポジトリ内でコードを検索するには、完全一致と正規表現モードを使用できます。

Zoektはコード検索のみを処理し、ElasticsearchまたはOpenSearchを置き換えるものではありません。コメント、コミット、エピック、イシュー、マージリクエスト、マイルストーン、プロジェクト、ユーザー、Wikiを含む他のすべての検索スコープでは、ElasticsearchまたはOpenSearchが依然として必要です。

Zoektをインストールする

前提条件:

  • インスタンスの管理者であること。

GitLabで完全一致コードの検索を有効にするには、少なくとも1つのZoektノードがインスタンスに接続されている必要があります。Zoektでは次のインストール方法がサポートされています:

  • Zoektチャート（スタンドアロンチャートとして、またはGitLab Helmチャートのサブチャートとして）
  • GitLab Operator（gitlab-zoekt.install=trueを使用）

次のインストール方法は、テスト用であり、本番環境での使用は推奨されません:

GitLab UIから

前提条件:

GitLab UIから完全一致コードの検索を有効にするには:

  1. 右上隅で、管理者を選択します。
  2. 設定 > 検索を選択します。
  3. 展開する完全一致コードの検索。
  4. インデックス作成を有効にすると検索を有効にするのチェックボックスを選択します。
  5. 変更を保存を選択します。

Rakeタスクを使用する

前提条件:

完全一致コードの検索をRakeタスクで管理できます。

インデックス作成と検索を有効にするには、このタスクを実行します:

gitlab-rake gitlab:zoekt:index

このタスクはzoekt_indexing_enabled、zoekt_search_enabled、およびzoekt_auto_index_root_namespaceを有効にします。RolloutWorkerはすべてのルートネームスペースを自動的にインデックス作成し、インデックスの準備が整うと検索が可能になります。

インデックス作成と検索を無効にするには、このタスクを実行します:

gitlab-rake gitlab:zoekt:disable

このタスクはzoekt_indexing_enabledとzoekt_search_enabledの両方を無効にします。

インデックス作成を一時停止および再開する

インデックス作成を一時停止するには（例えば、メンテナンス中）、このタスクを実行します:

gitlab-rake gitlab:zoekt:pause_indexing

インデックス作成を再開するには、このタスクを実行します:

gitlab-rake gitlab:zoekt:resume_indexing

ストレージ要件を推定する

Zoektノードに必要なストレージを推定するには、このタスクを実行します:

sudo gitlab-rake gitlab:zoekt:estimate_storage

詳細については、ストレージの見積もりを参照してください。

インデックス作成状態を確認する

前提条件:

  • インスタンスへの管理者アクセス権が必要です。

インデックス作成のパフォーマンスは、ZoektインデクサーノードのCPUとメモリ制限に依存します。インデックス作成状態を確認するには、次の手順に従います。

このRakeタスクを実行します:

gitlab-rake gitlab:zoekt:info

データを10秒ごとに自動的に更新するには、代わりにこのタスクを実行します:

gitlab-rake "gitlab:zoekt:info[10]"

Railsコンソールで、次のコマンドを実行します:

Search::Zoekt::Index.group(:state).count
Search::Zoekt::Repository.group(:state).count
Search::Zoekt::Task.group(:state).count

サンプル出力

gitlab:zoekt:info Rakeタスクは、次のような出力を返します:

Exact Code Search
GitLab version:                                      18.9.0
Enable indexing:                                     yes
Enable searching:                                    yes
Pause indexing:                                      no
Index root namespaces automatically:                 yes
Cache search results for five minutes:               yes
Indexing CPU to tasks multiplier:                    1.0
Probability of random force reindexing (percentage): 0.25
Number of parallel processes per indexing task:      1
Number of namespaces per indexing rollout:           32
Offline nodes automatically deleted after:           20m
Indexing timeout per project:                        30m
Maximum number of files per project to be indexed:   500000
Maximum file size for indexing:                      1MB
Maximum trigrams per file:                           20000
Retry interval for failed namespaces:                1d
Number of replicas per namespace:                    1

Nodes
# Number of Zoekt nodes and their status
Node count:                   2 (online: 2, offline: 0)
Last seen at:                 2025-11-21 22:58:09 UTC (less than a minute ago)
Max schema_version:           2531
Storage reserved / usable:    71.1 MiB / 124 GiB (0.06%)
Storage indexed / reserved:   42.7 MiB / 71.1 MiB (60.0%)
Storage used / total:         797 GiB / 921 GiB (86.54%)
Online node watermark levels: 2
  - low: 2

Indexing status
Group count:                      8
# Number of enabled namespaces and their status
EnabledNamespace count:           8 (without indices: 0, rollout blocked: 0, with search disabled: 0)
Replicas count:                   8
  - ready: 8
Indices count:                    8
  - ready: 8
Indices watermark levels:         8
  - healthy: 8
Repositories count:               10
  - ready: 10
Tasks count:                      10
  - done: 10
Tasks pending/processing by type: (none)
Storage buffer factor:            0.831× [static fallback (FF disabled)]

Feature Flags (Default Values)
- zoekt_too_many_replicas_event: disabled

Node Details
Node 1 - test-zoekt-hostname-1:
  Status:                       Online
  Last seen at:                 2025-11-21 22:58:09 UTC (less than a minute ago)
  Disk utilization:             86.54%
  Unclaimed storage:            62 GiB
  # Zoekt build version on the node. Must match GitLab version.
  Zoekt version:                2025.11.20-v1.7.6-28-gb9a0fd8
  Schema version:               2531
Node 2 - test-zoekt-hostname-2:
  Status:                       Online
  Last seen at:                 2025-11-21 22:58:09 UTC (less than a minute ago)
  Disk utilization:             86.54%
  Unclaimed storage:            62 GiB
  Zoekt version:                2025.11.20-v1.7.6-28-gb9a0fd8
  Schema version:               2531

ヘルスチェックを実行する

前提条件:

  • インスタンスへの管理者アクセス権が必要です。

Zoektインフラストラクチャのステータスを理解するためにヘルスチェックを実行します。これには次のものが含まれます:

  • オンラインノードとオフラインノード
  • インデックス作成と検索設定
  • 検索APIエンドポイント
  • JSON Webトークン生成

ヘルスチェックを実行するには、次のタスクを実行します:

gitlab-rake gitlab:zoekt:health

このタスクは以下を提供します:

  • 全体的なステータス: HEALTHY、DEGRADED、またはUNHEALTHY
  • 検出されたイシューを解決するための推奨事項
  • 自動化およびモニタリングインテグレーションの終了コード: 0=healthy、1=degraded、または2=unhealthy

チェックを自動的に実行する

10秒ごとに自動的にヘルスチェックを実行するには、次のタスクを実行します:

gitlab-rake "gitlab:zoekt:health[10]"

出力には、色付きのステータスインジケーターが含まれており、次のものが表示されます:

  • オンラインおよびオフラインノード数、ストレージ使用量の警告、および接続イシュー
  • コア設定検証とネームスペースおよびリポジトリのインデックス作成ステータス
  • 組み合わせたヘルス評価を含む全体的なステータス: HEALTHY、DEGRADED、またはUNHEALTHY
  • イシューを解決するための推奨事項

強制再インデックス作成を実行する

前提条件:

  • インスタンスへの管理者アクセス権が必要です。

プロジェクトの範囲で強制再インデックス作成を実行します。

このRakeタスクを実行します:

gitlab-rake gitlab:zoekt:reindex_projects ID_FROM=10 ID_TO=20

ID_FROMとID_TOの環境変数を使用すると、限られた数のプロジェクトを強制的に再インデックス作成できます。1つのプロジェクトだけを再インデックス作成するには、ID_FROMとID_TOを再インデックス作成するプロジェクトIDと同じ値にしてください。すべてのプロジェクトを再インデックス作成するには、環境変数を省略します。

インデックス作成の一時停止

前提条件:

  • インスタンスへの管理者アクセス権が必要です。

完全一致コードの検索のインデックス作成を一時停止するには:

  1. 右上隅で、管理者を選択します。
  2. 設定 > 検索を選択します。
  3. 展開する完全一致コードの検索。
  4. インデックス作成を一時停止のチェックボックスを選択します。
  5. 変更を保存を選択します。

完全一致コードの検索のインデックス作成を一時停止すると、リポジトリ内のすべての変更がキューに追加されます。インデックス作成を再開するには、Pause indexing for exact code searchチェックボックスをオフにします。

ルートネームスペースを自動的にインデックス作成する

前提条件:

  • インスタンスへの管理者アクセス権が必要です。

既存および新規のルートネームスペースの両方を自動的にインデックス作成できます。すべてのルートネームスペースを自動的にインデックス作成するには:

  1. 右上隅で、管理者を選択します。
  2. 設定 > 検索を選択します。
  3. 展開する完全一致コードの検索。
  4. ルートネームスペースを自動的にインデックス化するのチェックボックスを選択します。
  5. 変更を保存を選択します。

この設定を有効にすると、GitLabは次のすべてのプロジェクトのインデックス作成タスクを作成します:

  • すべてのグループとサブグループ
  • 新しいルートネームスペース

プロジェクトがインデックス作成されると、GitLabはリポジトリの変更が検出された場合にのみ増分インデックス作成を作成します。

この設定を無効にすると:

  • 既存のルートネームスペースはインデックス作成されたままです。
  • 新しいルートネームスペースはインデックス作成されなくなります。

検索結果をキャッシュする

前提条件:

  • インスタンスへの管理者アクセス権が必要です。

パフォーマンス向上のため、検索結果をキャッシュできます。この機能はデフォルトで有効になっており、結果を5分間キャッシュします。

検索結果をキャッシュするには:

  1. 右上隅で、管理者を選択します。
  2. 設定 > 検索を選択します。
  3. 展開する完全一致コードの検索。
  4. Cache search results for five minutesチェックボックスを選択します。
  5. 変更を保存を選択します。

同時インデックス作成タスクを設定する

前提条件:

  • インスタンスへの管理者アクセス権が必要です。

ZoektノードのCPU容量に対して、同時インデックス作成タスクの数を設定できます。

乗算が高いほど、より多くのタスクを同時に実行でき、CPU使用量が増加する代償としてインデックス作成スループットが向上します。デフォルト値は1.0（CPUコアあたり1タスク）です。

ノードのパフォーマンスとワークロードに基づいて、この値を調整できます。同時インデックス作成タスクの数を設定するには:

  1. 右上隅で、管理者を選択します。

  2. 設定 > 検索を選択します。

  3. 展開する完全一致コードの検索。

  4. CPUをタスク乗算にインデックスするテキストボックスに値を入力します。

    例えば、Zoektノードに4個のCPUコアがあり、乗算が1.5の場合、そのノードの同時タスク数は6になります。

  5. 変更を保存を選択します。

ランダムな強制再インデックス作成の確率を定義する

前提条件:

  • インスタンスへの管理者アクセス権が必要です。

プロジェクトが段階的にインデックス作成されるのではなく、強制的に再インデックス作成される確率を定義できます。デフォルト値は0.25（0.25%）です。

強制再インデックス作成は、インデックスを定期的にゼロから再構築することで、メモリマップ（mmap）ハンドラーが枯渇するのを防ぐのに役立ちます。割合が高いほど、特に非常に大規模なリポジトリでは、インデックス作成の負荷が増加します。

ランダムな強制再インデックス作成の確率を定義するには:

  1. 右上隅で、管理者を選択します。
  2. 設定 > 検索を選択します。
  3. 展開する完全一致コードの検索。
  4. ランダムな強制再インデックスの確率(パーセンテージ) テキストボックスに、0から100までの数値を入力します。
  5. 変更を保存を選択します。

インデックス作成タスクあたりの並列プロセス数を設定する

前提条件:

  • インスタンスへの管理者アクセス権が必要です。

インデックス作成タスクあたりの並列プロセス数を設定できます。

数値が高いほど、CPUとメモリ使用量が増加する代償として、インデックス作成時間が短縮されます。デフォルト値は1（インデックス作成タスクあたり1プロセス）です。

ノードのパフォーマンスとワークロードに基づいて、この値を調整できます。インデックス作成タスクあたりの並列プロセス数を設定するには:

  1. 右上隅で、管理者を選択します。
  2. 設定 > 検索を選択します。
  3. 展開する完全一致コードの検索。
  4. インデックスタスクごとの並列プロセス数テキストボックスに値を入力します。
  5. 変更を保存を選択します。

インデックス作成ロールアウトあたりのネームスペース数を設定する

前提条件:

  • インスタンスへの管理者アクセス権が必要です。

最初のインデックス作成のために、RolloutWorkerジョブあたりのネームスペース数を設定できます。デフォルト値は32です。ノードのパフォーマンスとワークロードに基づいて、この値を調整できます。

インデックス作成ロールアウトあたりのネームスペース数を設定するには:

  1. 右上隅で、管理者を選択します。
  2. 設定 > 検索を選択します。
  3. 展開する完全一致コードの検索。
  4. インデックスロールアウトごとのネームスペースの数テキストボックスに、ゼロより大きい数値を入力します。
  5. 変更を保存を選択します。

オフラインノードが自動的に削除されるタイミングを定義する

前提条件:

  • インスタンスへの管理者アクセス権が必要です。

オフラインのZoektノードは、関連するインデックス、リポジトリ、およびタスクとともに、特定の期間後に自動的に削除できます。デフォルト値は12h（12時間）です。

この設定を使用して、Zoektインフラストラクチャを管理し、孤立したリソースを防ぎます。オフラインノードが自動的に削除されるタイミングを定義するには:

  1. 右上隅で、管理者を選択します。
  2. 設定 > 検索を選択します。
  3. 展開する完全一致コードの検索。
  4. オフラインノードを削除するまでの時間テキストボックスに値を入力します（例: 30m（30分）、2h（2時間）、または1d（1日））。自動削除を無効にするには、0に設定します。
  5. 変更を保存を選択します。

プロジェクトのインデックス作成タイムアウトを定義する

前提条件:

  • インスタンスへの管理者アクセス権が必要です。

プロジェクトのインデックス作成タイムアウトを定義できます。デフォルト値は30m（30分）です。

プロジェクトのインデックス作成タイムアウトを定義するには:

  1. 右上隅で、管理者を選択します。
  2. 設定 > 検索を選択します。
  3. 展開する完全一致コードの検索。
  4. プロジェクトごとのインデックス作成タイムアウトテキストボックスに値を入力します（例: 30m（30分）、2h（2時間）、または1d（1日））。
  5. 変更を保存を選択します。

プロジェクトでインデックス作成するファイルの最大数を設定する

前提条件:

  • インスタンスへの管理者アクセス権が必要です。

プロジェクトでインデックス作成できるファイルの最大数を設定できます。デフォルトブランチでこの制限を超えるファイルを持つプロジェクトは、インデックス作成されません。

デフォルト値は500,000です。

ノードのパフォーマンスとワークロードに基づいて、この値を調整できます。プロジェクトでインデックス作成するファイルの最大数を設定するには:

  1. 右上隅で、管理者を選択します。
  2. 設定 > 検索を選択します。
  3. 展開する完全一致コードの検索。
  4. プロジェクトごとにインデックス化されるファイルの最大数テキストボックスに、ゼロより大きい数値を入力します。
  5. 変更を保存を選択します。

インデックス作成の最大ファイルサイズを設定する

前提条件:

  • インスタンスへの管理者アクセス権が必要です。

インデックス作成するファイルの最大サイズを設定できます。デフォルト値は1MBです。

指定されたサイズを超えるファイルでは、ファイル名のみがインデックス作成されます。これらのファイルはファイル名でのみ検索できます。インデックス作成の最大ファイルサイズを設定するには:

  1. 右上隅で、管理者を選択します。
  2. 設定 > 検索を選択します。
  3. 展開する完全一致コードの検索。
  4. インデックス化のための最大ファイルサイズテキストボックスに値を入力します（例: 512B、50KB、2MB、または1GB）。値は小文字でも指定できます。
  5. 変更を保存を選択します。

インデックス作成の最大トライグラム数を設定する

前提条件:

  • インスタンスへの管理者アクセス権が必要です。

インデックス作成するファイルの最大トライグラム数を設定できます。デフォルト値は20,000です。

トライグラムは、Zoektが効率的なコード検索に使用する3文字のシーケンスです。このトライグラム制限を超えるファイルの場合、ファイル名のみがインデックス作成されます。制限が高いほど、インデックス作成と検索のパフォーマンスの両方に影響します。

インデックス作成の最大トライグラム数を設定するには:

  1. 右上隅で、管理者を選択します。
  2. 設定 > 検索を選択します。
  3. 展開する完全一致コードの検索。
  4. ファイルあたりの最大トライグラム数テキストボックスに、ゼロより大きい数値を入力します。
  5. 変更を保存を選択します。

失敗したネームスペースの再試行間隔を定義する

前提条件:

  • インスタンスへの管理者アクセス権が必要です。

以前に失敗したネームスペースの再試行間隔を定義できます。デフォルト値は1d（1日）です。0の値は、失敗したネームスペースは決して再試行されないことを意味します。

失敗したネームスペースの再試行間隔を定義するには:

  1. 右上隅で、管理者を選択します。
  2. 設定 > 検索を選択します。
  3. 展開する完全一致コードの検索。
  4. 失敗したネームスペースを再試行する間隔テキストボックスに値を入力します（例: 30m（30分）、2h（2時間）、または1d（1日））。
  5. 変更を保存を選択します。

ネームスペースあたりのレプリカ数を設定する

前提条件:

  • インスタンスへの管理者アクセス権が必要です。

ネームスペースあたりのレプリカ数を設定できます。デフォルト値は1（ネームスペースあたり1レプリカ）です。

ネームスペースあたりのレプリカ数を増やすと、複数のZoektノードに負荷が分散され、検索の可用性が向上します。レプリカが増えると、ストレージ要件が増加します。

ネームスペースあたりのレプリカ数を設定するには:

  1. 右上隅で、管理者を選択します。
  2. 設定 > 検索を選択します。
  3. 展開する完全一致コードの検索。
  4. ネームスペースごとのレプリカの数テキストボックスに、ゼロより大きい数値を入力します。
  5. 変更を保存を選択します。

Zoektを別のサーバーで実行する

前提条件:

  • インスタンスの管理者であること。

GitLabとは異なるサーバーでZoektを実行するには:

  1. Gitalyリスニングインターフェースを変更します。
  2. Zoektをインストールします。

サイジングに関する推奨事項

以下の推奨事項は、一部のデプロイでは過剰なプロビジョニングとなる可能性があります。デプロイを監視して、次のことを確認する必要があります:

  • メモリ不足イベントが発生しないこと。
  • CPUスロットリングが過度ではないこと。
  • インデックス作成パフォーマンスが要件を満たしていること。

リソースは、以下を含む特定のワークロード特性に基づいて調整します:

  • リポジトリのサイズと複雑さ
  • アクティブなデベロッパーの数
  • コード変更の頻度
  • インデックス作成パターン

メモリアーキテクチャ

ウェブサーバーとインデクサーは異なるメモリ使用量パターンを持っています。

ウェブサーバーは、ディスクから仮想メモリにインデックスシャードをメモリマップします。オペレーティングシステムは、検索が処理される際に、シャードデータを物理メモリにページインおよびページアウトします。常駐メモリ使用量は、アクティブなワーキングセットとともに増加します。より大きなインデックスまたはより高いクエリボリュームを持つノードは、ページスラッシングやメモリ不足状態を回避するためにより多くのウェブサーバーメモリを必要とします。

インデクサーは、インデックスを構築または再構築する際に、Gitオブジェクトデータをメモリ内で処理します。大規模なリポジトリをインデックス作成しているときや、複数のタスクが並行して実行されているときに、メモリ使用量が急増します。インデックス作成タスクあたりの並列プロセス数とインデックス作成CPU-タスク乗算を調整することで、インデクサーのピークメモリを制御できます。

VMおよびベアメタルデプロイでは、ウェブサーバーとインデクサーが同じシステムメモリを共有します。

ノード

最適なパフォーマンスのためには、Zoektノードの適切なサイジングが重要です。KubernetesとVMのデプロイでは、リソースの割り当てと管理方法が異なるため、サイジングに関する推奨事項も異なります。

Kubernetesデプロイ

以下の表は、インデックスストレージ要件に基づいたKubernetesデプロイにおけるノード（StatefulSetポッドあたり）ごとの推奨リソースを示しています。StatefulSet内の各ポッドは、独立したリソース割り当てと、インデックスストレージ用の独自の永続ボリュームを持つ独自のウェブサーバーとインデクサーコンテナを実行します。複数のノードを実行している場合、これらのリソースをノードの数で乗算して、合計クラスターリソースを計算します。

ディスクウェブサーバーCPUウェブサーバーメモリインデクサーCPUインデクサーメモリ
128 GB116 GiB16 GiB
256 GB1.532 GiB18 GiB
512 GB264 GiB112 GiB
1 TB3128 GiB1.524 GiB
2 TB4256 GiB232 GiB

リソースをより細かく管理するために、CPUとメモリを異なるコンテナに個別に割り当てることができます。

Kubernetesデプロイの場合:

  • ZoektコンテナのCPU制限を設定しないでください。CPU制限は、インデックス作成のバースト中に不要なスロットリングを引き起こし、パフォーマンスに重大な影響を与える可能性があります。代わりに、リソースリクエストに依存して、最小限のCPU可用性を保証し、利用可能で必要な場合にコンテナが追加のCPUを使用するようにしてください。
  • リソース競合やメモリ不足の状態を防ぐために、適切なメモリ制限を設定してください。
  • より良いインデックス作成パフォーマンスのために、高性能ストレージクラスを使用してください。GitLab.comではGCPでpd-balancedを使用しており、パフォーマンスとコストのバランスが取れています。同等のオプションには、AWSのgp3とAzureのPremium_LRSが含まれます。

VMとベアメタルデプロイ

以下の表は、インデックスストレージ要件に基づいたVMおよびベアメタルデプロイにおけるノードごとの推奨リソースを示しています。複数のノードを実行している場合、これらのリソースをノードの数で乗算して、合計クラスターリソースを計算します。

ディスクVMサイズ合計CPU合計メモリAWSGCPAzure
128 GBS2コア16 GBr5.largen1-highmem-2Standard_E2s_v3
256 GB中程度4コア32 GBr5.xlargen1-highmem-4Standard_E4s_v3
512 GBL4コア64 GBr5.2xlargen1-highmem-8Standard_E8s_v3
1 TBXラージ8コア128 GBr5.4xlargen1-highmem-16Standard_E16s_v3
2 TB2Xラージ16コア256 GBr5.8xlargen1-highmem-32Standard_E32s_v3

これらのリソースは、ノード全体にのみ割り当てることができます。

VMおよびベアメタルデプロイの場合:

  • CPU、メモリ、ディスク使用量を監視してボトルネックを特定してください。
  • より良いインデックス作成パフォーマンスのために、SSDストレージの使用を検討してください。
  • GitLabとZoektノード間のデータ転送に十分なネットワーク帯域幅があることを確認してください。

ストレージ

Zoektのストレージ要件は、Gitリポジトリのサイズとレプリカ設定によって異なります。ZoektはGitオブジェクトデータ（ソースコードとコミット履歴）のみをインデックスします。LFSオブジェクト、Wiki、アーティファクト、パッケージ、またはその他のストレージコンポーネントはインデックスしません。

ストレージを見積もる

ストレージ要件を見積もるには、Rakeタスクを実行します:

sudo gitlab-rake gitlab:zoekt:estimate_storage

このタスクはGitLabデータベースをクエリし、現在のリポジトリサイズとレプリカ設定に基づいたストレージ見積もりを出力します。

手動で計算したい場合は、以下を使用します:

storage_per_replica = sum(repository_git_size) × buffer_factor
total_cluster_storage = storage_per_replica × number_of_replicas

ここでrepository_git_sizeは、各リポジトリのGitオブジェクトサイズです。この値には、LFSオブジェクト、Wiki、アーティファクト、またはパッケージは含まれません。またbuffer_factorは、最初のインデックス作成中のヘッドルームです。これはSearch::Zoekt::Index.global_buffer_factorとして計算できますが、デフォルトではほとんど3です。

repository_git_sizeを表示するには:

  1. 右上隅で、管理者を選択します。
  2. 概要 > プロジェクトを選択します。
  3. リポジトリ列で、Gitオブジェクトサイズを表示します。

最初のプロビジョニングターゲットでは、合計repository_git_sizeの3倍にレプリカ数を乗じた値から開始します。例:

  • 100 GBのGitリポジトリデータと1つのレプリカ: 300 GBのZoektストレージ。
  • 100 GBのGitリポジトリデータと2つのレプリカ: 600 GBのZoektストレージ。

GitLabは、インデックス作成中にZoektがヘッドルームを持つことを保証するために、このバッファを内部的に予約します。最初のインデックス作成が完了すると、実際のディスク使用量は、観察されたGitLab.comのデータに基づいて、repository_git_sizeの半分に近くなります。必要な場合にのみ、垂直または水平にスケールする。

実行することで、現在使用中のバッファ係数を表示できます:

sudo gitlab-rake gitlab:zoekt:info

出力には、Storage buffer factor行が含まれており、プランナーが現在使用している値と、それが動的であるか静的フォールバックであるかが示されます。

Zoektノードのストレージを監視するには、インデックス作成ステータスの確認を参照してください。ディスク容量不足のためネームスペースがインデックス作成されない場合は、ノードを追加するか、ディスク容量を増やしてください。

セキュリティと認証

Zoektは、GitLab、Zoektインデクサー、Zoektウェブサーバーコンポーネント間の通信を保護するために、多層認証システムを実装しています。すべての通信チャンネルで認証が強制されます。

すべての認証方法は、GitLab Shellシークレットを使用します。失敗した認証試行は401 Unauthorized応答を返します。

ZoektインデクサーからGitLabへ

Zoektインデクサーは、GitLabにJSON Webトークン（JWT）で認証することで、インデックス作成タスクを取得するし、完了コールバックを送信します。

このメソッドは、署名と検証に.gitlab_shell_secretを使用します。トークンはGitlab-Shell-Api-Requestヘッダーで送信されます。エンドポイントには以下が含まれます:

  • タスクの取得のためのGET /internal/search/zoekt/:uuid/heartbeat
  • ステータス更新のためのPOST /internal/search/zoekt/:uuid/callback

このメソッドは、ZoektインデクサーノードとGitLab間のタスク配布とステータスレポートのための安全なポーリングを保証します。

GitLabからZoektウェブサーバーへ

JWT認証

GitLabは、JSON Webトークン（JWT）を使用してZoektウェブサーバーに認証することで、検索クエリを実行します。JWTトークンは、他のGitLab認証パターンと一貫した、時間制限付きの暗号学的署名付き認証を提供します。

このメソッドはGitlab::Shell.secret_tokenとHS256アルゴリズム（HMAC with SHA-256）を使用します。トークンはAuthorization: Bearer <jwt_token>ヘッダーで送信され、露出を制限するために5分で有効期限が切れます。

エンドポイントには/webserver/api/searchと/webserver/api/v2/searchが含まれます。JWTクレームは、発行者（gitlab）と対象（gitlab-zoekt）です。