Gitalyリファレンス

GitalyはTOML設定ファイルによって設定されます。 ソースからのインストールとは異なり、Omnibus GitLabではこのファイルを直接編集することはありません。

設定ファイルは、gitaly実行ファイルの引数として渡されます。これは通常、Omnibus GitLab またはinitスクリプトによって行われます。

設定ファイルの例はGitalyプロジェクトにあります。

フォーマット

トップレベルでは、config.toml

名称 タイプ 必須 説明
socket_path yes (listen_addr が設定されていない場合) GitalyがUnixソケットを開くパス。
listen_addr yes (socket_path が設定されていない場合) GitalyがリッスンするためのTCPアドレス。
tls_listen_addr いいえ GitalyがリッスンするためのTCP over TLSアドレス。
bin_dir はい Gitalyの実行ファイルがあるコンテナ。
prometheus_listen_addr いいえ Prometheus メトリクスの TCP リスナー・アドレス。 設定されていない場合、Prometheus リスナーは起動しません。

使用例:

socket_path = "/home/git/gitlab/tmp/sockets/private/gitaly.socket"
listen_addr = "localhost:9999"
tls_listen_addr = "localhost:8888"
bin_dir = "/home/git/gitaly"
prometheus_listen_addr = "localhost:9236"

認証

Gitalyは、ヘッダに特定のベアラートークンを含まないリクエストを拒否するように 設定することができます。 これは、TCP上でリクエストを提供するときに使われる セキュリティ対策です:

[auth]
# A non-empty token enables authentication.
token = "the secret token"

config.toml のトークン設定がないか、空文字列の場合、認証は無効になります。

transitioning、一時的に認証を無効にすることができます。これにより、まだ正しく設定されていないクライアントのサービス停止を引き起こすことなく、すべてのクライアントが正しく認証されているかどうかを監視することができます:

[auth]
token = "the secret token"
transitioning = true
警告:トークンの設定を変更し終わったら、** を無効にすることを忘れないでください。

Prometheusでは、すべての認証試行がgitaly_authentications_total のメトリクスでカウントされます。

TLS

GitalyはTLS暗号化をサポートしています。 これは自動的には提供されないので、あなた自身の証明書を持参する必要があります。

名称 タイプ 必須 説明
certificate_path いいえ 証明書へのパス。
key_path いいえ キーへのパス。
tls_listen_addr = "localhost:8888"

[tls]
certificate_path = '/home/git/cert.cert'
key_path = '/home/git/key.pem'

GitalyのTLSについてもっと読む

ストレージ

GitLabリポジトリは、”storages”(例えば、/home/git/repositories)と呼ばれるディレクトリにグループ化され、GitLabが管理するベアリポジトリが名前(例えば、default)で格納されています。

これらの名前とパスは、GitLabのgitlab.yml 設定ファイルでも定義されています。GitalyをGitLabと同じマシン上で実行する場合(これがデフォルトで推奨される設定です)、Gitalyのconfig.tomlで定義されたストレージ・パスは、gitlab.ymlのものと一致しなければなりません。

名称 タイプ 必須 説明
storage アレイ はい ストレージシャードのアレイ。
path はい ストレージ・シャードへのパス。
name はい ストレージ・シャードの名前。

使用例:

[[storage]]
path = "/path/to/storage/repositories"
name = "my_shard"

[[storage]]
path = "/path/to/other/repositories"
name = "other_storage"

Git

コンフィギュレーション・ファイルの[git] セクションでは、以下の値を設定できます。

名称 タイプ 必須 説明
bin_path いいえ git バイナリへのパス。設定されていない場合はPATHを使って解決されます。
catfile_cache_size 整数 いいえ キャッシュされるcat-file プロセスの最大数。デフォルトは100

cat-file キャッシュ

GitalyのRPCの多くは、リポジトリからGitオブジェクトを検索する必要があります。ほとんどの場合、そのためにgit cat-file --batch プロセスを使用します。パフォーマンスを向上させるために、GitalyはRPCコール間でこれらのgit cat-file プロセスを再利用することができます。 以前に使用されたプロセスは、“Git cat-fileキャッシュ “に保持されます。 これが使用するシステムリソースの量を制御するために、私たちはキャッシュに入ることができるcat-fileプロセスの最大数を設定しています。

デフォルトの上限は、git cat-file --batchgit cat-file --batch-check プロセスのペアを構成する 100cat-files です。 「開いているファイルが多すぎる」、または新しいプロセスを作成できない、といったエ ラーが表示される場合は、この上限を下げるとよいでしょう。

理想的には、この数値は通常のトラフィックを処理するのに十分な大きさであるべきです。 制限を上げた場合、その前後でキャッシュのヒット率を測定する必要があります。 ヒット率が向上しない場合、上限を上げても意味がない可能性があります。 ヒット率を確認するための Prometheus クエリの例を示します:

sum(rate(gitaly_catfile_cache_total{type="hit"}[5m])) / sum(rate(gitaly_catfile_cache_total{type=~"(hit)|(miss)"}[5m]))

gitaly-ruby

Gitalyプロセスは、Goの代わりにRubyで実装されたRPCを実行するために、1つ以上のgitaly-ruby ヘルパー・プロセスを使用します。設定ファイルの[gitaly-ruby]セクションには、これらのヘルパー・プロセスの設定が含まれています。

これらのプロセスは、時折メモリリークに悩まされることが知られています。 Gitalyは、そのメモリがmax_rss の制限を超えた場合、そのgitaly-ruby ヘルパーを再起動します。

名称 タイプ 必須 説明
dir はい gitaly-ruby がインストールされている場所へのパス(プロセスの起動に必要)。
max_rss 整数 いいえ gitaly-ruby の再起動をトリガーする常駐設定サイズ制限。バイト単位。デフォルトは200000000 (200MB)。
graceful_restart_timeout いいえ max_rssを超えたgitaly-ruby プロセスが強制終了されるまでの猶予時間。デフォルトは10m (10 分)。
restart_delay いいえ 再起動前にgitaly-ruby メモリがハイのままでなければならない時間。デフォルトは5m (5分)。
num_workers 整数 いいえ gitaly-ruby ワーカープロセスの数。ResourceExhausted エラーが発生する場合は、この数を増やしてみてください。 デフォルトは2、最小は 2
linguist_languages_path いいえ 動的なlanguages.json 発見のためのオーバーライド。 デフォルトは空文字列です(動的発見の使用)。

使用例:

[gitaly-ruby]
dir = "/home/git/gitaly/ruby"
max_rss = 200000000
graceful_restart_timeout = "10m"
restart_delay = "5m"
num_workers = 2

GitLab シェル

歴史的な理由から、GitLab ShellはGitLabがGitプッシュを検証し反応するためのGitフックを含んでいます。 GitalyはGitプッシュを “所有 “しているため、GitLab ShellはGitalyと一緒にインストールされなければなりません。 これは将来的に簡素化されるでしょう。

名称 タイプ 必須 説明
dir はい GitLab Shellがインストールされているディレクトリ。

使用例:

[gitlab-shell]
dir = "/home/git/gitlab-shell"

Prometheus

オプションで、PrometheusのGRPCメソッド呼び出しのヒストグラム・レイテンシを記録するようにGitalyを設定できます。

名称 タイプ 必須 説明
grpc_latency_buckets アレイ いいえ Prometheusは各オブザベーションをバケットに保存します。 つまり、レイテンシの近似値を得ることができます。 バケットを最適化することで、近似値の精度をよりコントロールすることができます。

使用例:

prometheus_listen_addr = "localhost:9236"

[prometheus]
grpc_latency_buckets = [0.001, 0.005, 0.025, 0.1, 0.5, 1.0, 10.0, 30.0, 60.0, 300.0, 1500.0]

ロギング

以下の値は、[logging] セクションで Gitaly のロギングを設定します。

名称 タイプ 必須 説明
format いいえ ログフォーマット:text またはjson. デフォルト:text.
level いいえ ログレベル:debug,info,warn,error,fatal, またはpanic. デフォルト:info.
sentry_dsn いいえ 例外監視用の Sentry DSN。
sentry_environment いいえ 例外監視のためのSentry環境。
ruby_sentry_dsn いいえ gitaly-ruby 例外監視用の Sentry DSN。

メインのGitalyアプリケーションのログはstdoutに行きますが、GitLab Shellのログのように、設定されたディレクトリに行く余分なログファイルがいくつかあります。GitLab Shellはpanic またはtrace レベルのログをサポートしていません。panicerrorにフォールバックし、tracedebugにフォールバックします。その他の無効なログレベルはデフォルトでinfoになります。

使用例:

[logging]
level = "warn"
dir = "/home/gitaly/logs"
format = "json"
sentry_dsn = "https://<key>:<secret>@sentry.io/<project>"
ruby_sentry_dsn = "https://<key>:<secret>@sentry.io/<project>"

コンカレンシー

各 RPC エンドポイントのconcurrency を調整できます。

名称 タイプ 必須 説明
concurrency アレイ はい RPC エンドポイントの配列。
rpc いいえ RPC エンドポイントの名前 (/gitaly.RepositoryService/GarbageCollect)。
max_per_repo 整数 いいえ リポジトリごとのRPCごとの同時実行数。

使用例:

[[concurrency]]
rpc = "/gitaly.RepositoryService/GarbageCollect"
max_per_repo = 1